[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
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" <chris.keller@active-endpoints.com> To: "'Glenn Mi'" <gmi@collaxa.com>; <ygoland@bea.com>; <wsbpel@lists.oasis-open.org> Cc: "'Muruga Chinnananchi'" <muruga@collaxa.com> 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: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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]