[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:ygoland@bea.com] Sent: Wednesday, August 06, 2003 10:56 AM To: wsbpel@lists.oasis-open.org 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:dannyv@tibco.com] Sent: Wednesday, August 06, 2003 10:08 AM To: wsbpel@lists.oasis-open.org 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: wsbpel-unsubscribe@lists.oasis-open.org For additional commands, e-mail: wsbpel-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]