i'd like to table the validation question for now. probably re-raise it as
a separate issue pointing back to this one later. since most of it depends
on <to> being able to insert nodes, i'd like to go back to this issue.
i agree with yaron, that my previous proposal allowing <to> to select 0
nodees was in error. i also agree with chris that this is an important
"feature" to have, if it's not a bug that it's not there.
there is half of a spec languishing out there that deals with these things.
it is called XUpdate
(http://www.xmldb.org/xupdate/xupdate-wd.html). i can't see any IP notice
about it, so i am unclear as to those issues.
not taking the complete XUpdate as a language, but looking at the ideas
behind its primitives, i can see use for derivatives of the following as
alternatives for the <to> element when the target is a variable:
<xupdate:insert-before select="XPath expression">
<xupdate:insert-after select="XPath expression">
<xupdate:append select="XPath expression" child="integer
expression"?>
<xupdate:update select="XPath expression"> (the same as BPEL's
current <to> element)
<xupdate:remove select="XPath expression"> (no <from> element
would be required for this one...)
<xupdate:rename select="XPath expression" newName="ncname"> (or
this one (which i slightly changed from XUpdate))
i think the semantics for these are pretty self-evident, but if not, go to
the XUpdate spec. it's short. again, i think it would be pretty
straightforward to nail down precise semantics, error cases, faults, etc.
but before i do that (with help?) i wanted to get a feeling of whether
1) people think that addressing this issue is as important as i do, and
2) whether people think that this is the right approach to take.
is there a way to quickly poll people on this without asking them to expound
in detail? just ask for +1/-1 mail? any other ideas?
danny
----- Original Message -----
From: "Chris Keller" <>
To: "'Glenn Mi'" <>; <>;
<>
Cc: "'Muruga Chinnananchi'" <>
Sent: Wednesday, August 06, 2003 1:04 PM
Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> I think that the <to> specification must handle the insert case. If a
> bpws:selectionFailure is thrown when using a <to> into a new complex
> part then this is a bad mistake. How would someone create a new input
> document to pass to an invoke operation or reply to an operation if this
> were the case? Would they have to invoke a specialized operation just
> to create a base document for the assignment copies to proceed? The
> wsbpel specification must address this case whether the 1.1
> specification addresses it or not.
>
> Chris Keller
>
> -----Original Message-----
> From: Glenn Mi [mailto:]
> Sent: Wednesday, August 06, 2003 2:45 PM
> To: ;
> Cc: Muruga Chinnananchi
> Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
>
> Yaron:
>
> My understanding of the to query is close to "find and replace"
> than "insert". Your example, according to my understanding of the spec,
> will end up throwing a bpws:selectionFailure fault. Because in page 33,
> the spec states that:
>
> "If the location path selects zero nodes or more than one node, then
> the standard fault bpws:selectionFailure MUST be thrown by a compliant
> implementation".
>
> And the spec doesn't make distincion between the query string in <from>
> element or <to> element.
>
> Glenn Mi
> 650-801-6297
> Collaxa, Inc.
> 1600 Bridge Parkway
> Redwood Shores, CA 94065
>
>
> -----Original Message-----
> From: Yaron Goland [mailto:]
> Sent: Wednesday, August 06, 2003 10:56 AM
> To:
> Subject: [wsbpel] Issue - 11 - Ambiguous insertion points
>
>
> Imagine two variables.
>
> Variable Name: Yippy
> Part Name: P1
> Value: <yippy/>
>
> Variable Name: Foo
> Part Name: P1
> Value: <foo><bar/></foo>
>
> The imagine executing:
>
> <copy>
> <from variable="Yippy" part="P1" query="/"/>
> <to variable="Foo" part="P1" query="/foo/blah"/>
> </copy>
>
> Where does <blah> end up?
>
> The situation is ambiguous because the query string in the to could
> legally
> resolve to either:
>
> <foo>
> <blah><yippy/></blah>
> <bar/>
> </foo>
>
> or
>
> <foo>
> <bar/>
> <blah><yippy/></blah>
> </foo>
>
> ?
>
> In other words the XPATH in the query string (having resolved to 0 nodes
> and
> thus, according to the proposed language being treated as an insert) is
> ambiguous.
>
> The problem, near as I can tell, is that XPATH is only designed to point
> at
> values that do exist in the infoset where what we really want to do is
> to
> point at locations that don't have a value in them.
>
> This means that in order to support insert behavior we will need to add
> information that is not already in XPATH. One possible way around this
> would
> be to explicitly identify the location where the value is to be
> inserted. We
> could, for example, add the beforeinsertionPoint attribute which would
> specify that the location identified in the query, if it resolves to
> null,
> should be created as the sibling before the point identified in
> beforeinsertionPoint. One would also imagine an afterinsertionPoint
> attribute.
>
> For example,
> <copy>
> <from variable="Yippy" part="P1" query="/"/>
> <to variable="Foo" part="P1" query="/foo/blah"
> afterinsertionPoint="/foo/bar"/>
> </copy>
>
> Would result in P1 of Foo containing:
> <foo>
> <bar/>
> <blah><yippy/></blah>
> </foo>
>
> There are edge cases that have to be addressed. For example, using the
> values of Foo and Yippy as defined at the start of this e-mail, what
> happens
> in this case?
> <copy>
> <from variable="Foo" part="P1" query="/"/>
> <to variable="Yippy" part="P1" query="/yippy/"
> beforeinsertionPoint="/yippy/"/>
> </copy>
>
> In this case beforeinsertionPoint would resolve to 0 nodes as well. I
> suspect that should just be an error and we would need a fault to
> identify
> it.
>
> This whole thing feels really ugly to me so I'm guessing I've made some
> huge
> mistake someplace.
>
> Yaron
>
> P.S. What we really need is a proper XPATH update language but my
> understanding is that the W3C is only now starting to work on that.
>
> -----Original Message-----
> From: Danny van der Rijn [mailto:]
> Sent: Wednesday, August 06, 2003 10:08 AM
> To:
> Subject: [wsbpel] Issue - 11 Query in <to> close should allow assigning
> to new locations
>
>
> I would like to open discussion on this issue (and volunteer to champion
> it).
>
> The issue is that in section 14.3 dealing with assignment, there is the
> following verbiage:
>
> "For XPath 1.0, the value of the query attribute MUST be an absolute
> locationPath (with '/' meaning the root of the document fragment
> representing the entire part). It is used to identify the root of a
> subtree
> within the document fragment representing the part. <b>The location path
> MUST select exactly one node. If the location path selects zero nodes or
> more than one node during execution, then the standard fault
> bpws:selectionFailure MUST be thrown by a compliant implementation.</b>"
> (emphasis added)
>
> This means that the only way to get an initialized value into a variable
> is
> to receive a message from elsewhere. This is, I believe, far too
> restrictive. I propose that the wording be changed to
>
> "For XPath 1.0, the value of the query attribute MUST be an absolute
> locationPath (with '/' meaning the root of the document fragment
> representing the entire part). It is used to identify the root of a
> subtree
> within the document fragment representing the part. <b>When the
> expression
> is used inside a <from> element, the location path MUST select exactly
> one
> node. If the location path selects zero nodes or more than one node
> during
> execution, then the standard fault bpws:selectionFailure MUST be thrown
> by a
> compliant implementation. When the expression is used inside a <to>
> element, and it selects 0 nodes, then the expression should be treated
> as
> the location that the value will have after it is inserted.</b>"
>
> This probably isn't the best wording, and I'd love someone to clean it
> up a
> bit, but I think you get the general idea.
>
> Danny van der Rijn
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
>
