RE: [wsbpel] Issue - 11 Summary So Far

["Tony Andrews" <tandrews@microsoft.com>]

I prefer Danny's proposal as it will be easier to support new query
languages over time if we try to minimize our use of extension functions
(provided the additions to the BPEL schema are reasonably limited in
number and functionality).

Tony 

> -----Original Message-----
> From: Danny van der Rijn [mailto:dannyv@tibco.com] 
> Sent: Monday, August 18, 2003 4:16 PM
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Issue - 11 Summary So Far
> 
> Diane has asked me, as champion of issue #11, to summarize a 
> long thread of email that has occurred on this issue so far.  
> Apologies if the lateness of the summary forces postponement 
> of this issue to a future meeting.
> 
> The issue is related to language in section 14.3 which states 
> that if there is a query in a <to> element of an 
> <assign><copy> element, that "[it] MUST select exactly one 
> node. If [it] selects zero nodes or more than one node during 
> execution, then the standard fault bpws:selectionFailure MUST 
> be thrown by a compliant implementation."
> 
> The issue is that while the restriction is necessary to avoid 
> ambiguity, more powerful semantics are needed in order to 
> manipulate data in useful ways.  Two alternative proposals 
> are currently under discussion, one put forward by Chris 
> Keller, and one by myself.  Chris' alternative involves the 
> introduction of a few XPath functions to remedy the 
> situation.  My alternative introduces new elements to the 
> <assign> element.  I will present my own alternative, and 
> leave it to Chris to present his, as I'm afraid that I won't 
> do it justice.
> 
> Also note that several other topics came up during this email 
> thread.  My personal feeling is that they should be treated 
> as separate issues, and in fact, some of them have been 
> raised as such.  Since their very existence is dependent on 
> this issue being addressed, my preference is to defer their 
> discussion until we have agreed to move forward on this issue.
> 
> My proposal:  under the <assign> element, there will be 6 
> possible elements, where now there is only 1.
> 
> <copy>
>   <from/>
>   <to/>
> </copy>
> as current.
> 
> <insertBefore>
>   <from/>
>   <to select="XPath Expression evaluates to one node"/> 
> </insertBefore> creates a sibling before the select expression
> 
> <insertAfter>
>   <from/>
>   <to select="XPath Expression evaluates to one node"/> 
> </insertAfter> creates a sibling after the select expression
> 
> <append>
>   <from/>
>   <to select="XPath Expression evaluates to one node" 
> child="integer XPath expression"? /> <append> creates a child 
> of select expression at the child-th position.  child 
> defaults to last().
> 
> <remove select="XPath expression evaluates to one node"> 
> removes a node
> 
> <rename select="XPath expression evaluates to one node" 
> newName="ncname"/> renames a node
> 
> 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
> 
>