RE: [wsbpel] Issue - 11 - Ambiguous insertion points

["Edwin Khodabakchian" <edwink@collaxa.com>]

---- Start SpamAssassin results
7.00 points, 7 required;
* -0.5 -- Has a In-Reply-To header
*  1.2 -- BODY: Message is 0% to 10% HTML
*  1.0 -- BODY: HTML included in message
* -0.5 -- BODY: Contains what looks like a quoted email text
*  0.7 -- 'Message-Id' was added by a relay (3)
*  4.5 -- Forged mail pretending to be from MS Outlook
*  0.6 -- Message looks like Outlook, but isn't

---- End of SpamAssassin results

---

• From: "Edwin Khodabakchian" <edwink@collaxa.com>
• To: <chris.keller@active-endpoints.com>, <wsbpel@lists.oasis-open.org>
• Date: Wed, 6 Aug 2003 13:15:03 -0700

Chris,

Invocation to an external service is not always required to initiatialize a
variable. Assignment from XML literal can be used as an alternative.

Edwin



> -----Original Message-----
> From: Chris Keller [mailto:chris.keller@active-endpoints.com] 
> Sent: Wednesday, August 06, 2003 1:04 PM
> To: 'Glenn Mi'; ygoland@bea.com; wsbpel@lists.oasis-open.org
> Cc: 'Muruga Chinnananchi'
> 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:gmi@collaxa.com]
> Sent: Wednesday, August 06, 2003 2:45 PM
> To: ygoland@bea.com; wsbpel@lists.oasis-open.org
> 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: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
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 

---