[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
not to discourage a bit of active involvement, but i'd really like to wrap this conversation before we delve into the other issues. i truly believe that they are other issues to be dealt with separately. i apologize, of course, for ignoring my own desire. that being said, my comments are inline with <DV> ----- Original Message ----- From: "Harvey Reed" <hreed@sonicsoftware.com> To: <chris.keller@active-endpoints.com>; "'Danny van der Rijn'" <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org> Sent: Wednesday, August 13, 2003 2:29 PM Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > Ok, I'll chime in again :-) > > In addition to the syntax being discussed below, what do we say about the > state of the node when the 'copy' is complete? > > 1. Is it valid when copy is done? Yes, no , maybe? <DV> my current thinking is that the *smallest* validation boundary is the <assign> operation itself, and not any individual <copy> </DV> > 2. What does it mean to be valid? (schema association?) <DV> validates without error against the schema which defines it </DV> > 2. Do we say anything about 'copy' relative to operational semantics of > durability? That is, if a process takes a while, and if state is durable, > can we always assume it is ok to persist after a 'copy'? and if so what > about #1,2 above? > <DV> i don't think anything is currently said on this topic </DV> > ++Harvey > > > > -----Original Message----- > From: Chris Keller [mailto:chris.keller@active-endpoints.com] > Sent: Wednesday, August 13, 2003 5:18 PM > To: 'Danny van der Rijn'; wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > Danny, > > I agree that we need to develop one of these into a reasonable proposal. > Perhaps if some of the other active discussers of this issue could chime > in then we can decide on how to move forward. > > In response to your last set of questions/clarifications: > > <DV> no, it's due to the fact that the function inserts a node (empty i > assume. validation?) whose sole purpose is to be <copy>d over. so the > node > needs to be created, and then immediately it's garbage. </DV> > > Perhaps, but in my thinking it is the empty content being replaced not > the node itself. And I assume validation is at the end of the activity > and during the execution of any activity the content is more volatile. > > <DV> i think i understand. is it right that if you want to cause this > to do > "my" append, you leave off the child expression? if so, how do you > choose > which child of the parent the new expression will become? </DV> > > You are right. The child is specified by the childQName (the third > parameter). Also we have some mistakes in the document fragments > resulting from the examples (the blah text was not shown): > > <copy> > <from expression="'blah'"/> > <to expression="bpws:insertVariableNode('variable', 'part', 'bar, > '/foo', blah')/> > </copy> > > It would create the following fragment: > > <foo> > <bar>blah</bar> > <blah/> > </foo> > > The same goes for the other fragments. > > Chris > > -----Original Message----- > From: Danny van der Rijn [mailto:dannyv@tibco.com] > Sent: Wednesday, August 13, 2003 4:33 PM > To: wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points > > i'm starting to understand your syntax some more. my question is where > do > we go from here? we're going to have to develop one of these into a > reasonable proposal. i'd prefer not to do both. > > additional comments inline with <DV>. > > ----- Original Message ----- > From: "Chris Keller" <chris.keller@active-endpoints.com> > To: "'Danny van der Rijn'" <dannyv@tibco.com>; > <wsbpel@lists.oasis-open.org> > Sent: Wednesday, August 13, 2003 12:27 PM > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > Danny - > > > > See clarifications below (marked with CK>>>) > > > > Also got your note on remove and rename, agreed still an open issue > > using my syntax. > > > > Chris > > > > -----Original Message----- > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > Sent: Wednesday, August 13, 2003 3:10 PM > > To: wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > ahh. i got confused by the 'bar' in the to expression from before. > > > > > <copy> > > > <from .../> > > > <to expression="bpws:insertVariableNode('variable', 'part', > > > 'bar','/foo', 'blah')/> > > > </copy> > > > > in your latest clarification it goes to the <from> element if i'm not > > mistaken. > > > > so now we're down to the nitty gritty details. thank goodness ;-) > i'm > > perfectly happy with the overall format of your suggestion. however, > i > > have > > some objections to parts of it. > > > > objection #1: i don't like the idea of a function creating a node that > > is > > about to be changed by the <copy> element. that's extra overhead. > > > > CK>>> Unsure if there is much overhead, this could be caused by > > CK>>> the confusion that the child path(s) is relative to the > > CK>>> parent path which I point out more below. > > > > <DV> no, it's due to the fact that the function inserts a node (empty i > assume. validation?) whose sole purpose is to be <copy>d over. so the > node > needs to be created, and then immediately it's garbage. </DV> > > > objection #2: you still don't differentiate between inserting before > and > > after. when operating on yaron's now canonical > > > > <foo> > > <blah/> > > </foo> > > > > and the function is > > <copy> > > <from expression="'blah'"/> > > <to expression="bpws:insertVariableNode('variable', 'part', > '/foo/bar, > > '/foo', /foo/blah')/> > > </copy> > > > > do you get > > <foo> > > <bar> > > <blah> > > </foo> > > (insert before) > > > > or > > > > <foo> > > <blah> > > <bar> > > </foo> > > (insert after) > > > > just to be clear, my proposed append operation would yield > > <foo> > > <blah> > > <bar/> > > </blah> > > </foo> > > with the optional parameter determining between which siblings bar > would > > get > > placed. in this case, there were no siblings, so the parameter was > > moot. > > > > CK>>> I believe the confusion is caused by the fact that my childPath > > CK>>> is relative to the parent path so it should read: > > CK>>> <copy> > > CK>>> <from expression="'blah'"/> > > CK>>> <to expression="bpws:insertVariableNode('variable', 'part', > > 'bar', > > CK>>> '/foo', blah')/> > > CK>> </copy> > > CK>>> > > CK>>> which would produce: > > CK>>> <foo> > > CK>>> <bar> > > CK>>> <blah> > > CK>>> </foo> > > CK>>> > > CK>>> and the flip side would be > > CK>>> <copy> > > CK>>> <from expression="'blah'"/> > > CK>>> <to expression="bpws:appendVariableNode('variable', 'part', > > 'bar', > > CK>>> '/foo', blah')/> > > CK>> </copy> > > CK>>> > > CK>>> which would produce: > > CK>>> <foo> > > CK>>> <blah> > > CK>>> <bar> > > CK>>> </foo> > > CK>>> > > > > <DV> i think i understand. is it right that if you want to cause this > to do > "my" append, you leave off the child expression? if so, how do you > choose > which child of the parent the new expression will become? </DV> > > > objection #3: i'm not thrilled with the overloading (optional > parameter > > changes function from append to insert). > > > > CK>>> ok, but there is precedent in the specification with the > > CK>>> bpws:getVariableData function. > > > > <DV> it's not overloading in general that i'm opposed to. i think that > the > current overloading is a bit more clear. </DV> > > > > > objection #4: might not be an objection, but it looks to me like some > of > > the > > parameters are redundant. > > > > CK>>> I think this is caused by the misunderstanding on the relative > > nature > > CK>>> of the child paths and nodes. > > > > <DV> got it. </DV> > > > feeling like a lot of progress is being made (even if it's just the 2 > of > > us > > reading...) > > > > CK>>> Agreed > > > > danny > > > > ----- Original Message ----- > > From: "Chris Keller" <chris.keller@active-endpoints.com> > > To: "'Danny van der Rijn'" <dannyv@tibco.com>; > > <wsbpel@lists.oasis-open.org> > > Sent: Wednesday, August 13, 2003 11:39 AM > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > Understood, the xupdate usage was functionality not syntax. Thanks > > for > > > clarifying. In that case I think we are in heated agreement. We > only > > > deviate in the style in which it should be implemented. In the > style > > of > > > copy I suggested the <from> contains the data to be copied to the > > newly > > > created node which the function created and placed (as dictated by > the > > > parameters) in the XML fragment. Here is a proposed syntax for your > > use > > > cases. > > > > > > Case 1: > > > <insertBefore> > > > <from/> > > > <to select="XPath Expression evaluates to one node"/> > > > </insertBefore> > > > creates a sibling before the select expression > > > > > > becomes: > > > <copy> > > > <from/> > > > <to expression="bpws:insertVariableNode('variable', 'part', 'qname > > of > > > new element, 'parentPath part of your xpath expression evaluates to > > one > > > node', 'path of sibling to insert before evaluate to one node')/> > > > </copy> > > > > > > The reason for splitting the parent and sibling paths in my function > > is > > > that the sibling path is optional, which is a reasonable use case. > > > > > > Case 2 > > > <insertAfter> > > > <from/> > > > <to select="XPath Expression evaluates to one node"/> > > > </insertAfter> > > > creates a sibling after the select expression > > > > > > Becomes: > > > <copy> > > > <from/> > > > <to expression="bpws:appendVariableNode('variable', 'part', 'qname > > of > > > new element, 'parentPath part of your xpath expression evaluates to > > one > > > node', 'path of sibling to append after evaluates to one node')/> > > > </copy> > > > > > > Case 3: > > > <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(). > > > > > > Becomes: > > > <copy> > > > <from/> > > > <to expression="bpws:appendVariableNode('variable', 'part', 'qname > > of > > > new element, 'parentPath xpath expression evaluates to one node')/> > > > </copy> > > > Just remove optional sibling path and it defaults to last(). > > > > > > Case 4: > > > <remove select="XPath expression evaluates to one node"> > > > removes a node > > > > > > Becomes: > > > Sorry didn't introduce a remove, but I agree this could have some > > value. > > > > > > Case 5: > > > <rename select="XPath expression evaluates to one node" > > > newName="ncname"/> > > > for completeness, don't have strong feelings about its inclusion > > > > > > Becomes: > > > Sorry didn't introduce a rename. > > > > > > > > > > > > I hope this helps clarify the proposal. > > > > > > Chris > > > > > > > > > -----Original Message----- > > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > > Sent: Wednesday, August 13, 2003 2:10 PM > > > To: wsbpel@lists.oasis-open.org > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > The main reason for the XPath route was in response to Yaron's > > comment > > > > on finishing the standard on time. And this seemed like an > > acceptable > > > > compromise since it deviates very little from the current > > > specification. > > > > Introducing the xupdate syntax seemed like a bigger nut to crack > and > > > it > > > > also introduces a dependency on another specification, which > people > > > > would need to digest. > > > > > > i'm not suggesting a dependency on XUpdate, just the concepts from > it, > > > which > > > we're already bandying around. i'm simply using XUpdate as > shorthand > > > for > > > the functionality that we're talking about, in whatever syntactic > form > > > it > > > comes in. > > > > > > > <copy> > > > > <from .../> > > > > <to expression="bpws:insertVariableNode('variable', 'part', > > > > 'bar','/foo', > 'blah')/> > > > > </copy> > > > > > > so what's the point of the <from> clause here? > > > > > > i'm not sure why changing BPEL syntax is different from adding XPath > > > functions, but i realize that i haven't been too explicit either. > > what > > > i'm > > > looking at is the following possible elements under <assign>: > > > > > > <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"/> > > > for completeness, don't have strong feelings about its inclusion > > > > > > end result: nice clean syntax; nothing too major added; hopefully > > > doesn't > > > require a lot more work, spec can go forward. > > > > > > ----- Original Message ----- > > > From: "Chris Keller" <chris.keller@active-endpoints.com> > > > To: "'Danny van der Rijn'" <dannyv@tibco.com>; > > > <wsbpel@lists.oasis-open.org> > > > Sent: Wednesday, August 13, 2003 10:37 AM > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > > > Danny - > > > > > > > > Sorry, I should have been more explicit with the example. Let's > > take > > > > the case Yaron had brought up of /foo/blah and we would like to > > insert > > > > bar as a child of foo before blah. > > > > > > > > So before the copy the document fragment looks like: > > > > <foo> > > > > <blah/> > > > > </foo> > > > > > > > > We execute the following copy: > > > > > > > > <copy> > > > > <from .../> > > > > <to expression="bpws:insertVariableNode('variable', 'part', > > > > 'bar','/foo', > 'blah')/> > > > > </copy> > > > > > > > > The result would be: > > > > > > > > <foo> > > > > <bar>...</bar> > > > > <blah/> > > > > </foo> > > > > > > > > If instead we had executed the following copy: > > > > > > > > <copy> > > > > <from .../> > > > > <to expression="bpws:appendVariableNode('variable', 'part', > > > > 'bar','/foo', > 'blah')/> > > > > </copy> > > > > > > > > The result would be: > > > > > > > > <foo> > > > > <blah/> > > > > <bar>...</bar> > > > > </foo> > > > > > > > > The "append" versus "insert" would be used to decide whether you > are > > > > appending the new child or inserting the new child. If the > sibling > > > name > > > > is not specified then this results in putting the new child at the > > end > > > > of the list or beginning of the list of children respectively. > > > > > > > > I don't know if we need more than these two for positioning, but I > > > could > > > > be wrong. If we want rename and remove functionality (although > > rename > > > > is less of an issue it is hard to make a case for when that is > > needed) > > > > we could do that by adding the functions that you mentioned. Also > I > > > > think we can leave the <copy><to...> as an update and let the > > > functions > > > > handle the node creation and return of the new single node list. > > > > > > > > The main reason for the XPath route was in response to Yaron's > > comment > > > > on finishing the standard on time. And this seemed like an > > acceptable > > > > compromise since it deviates very little from the current > > > specification. > > > > Introducing the xupdate syntax seemed like a bigger nut to crack > and > > > it > > > > also introduces a dependency on another specification, which > people > > > > would need to digest. > > > > > > > > Chris > > > > > > > > -----Original Message----- > > > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > > > Sent: Wednesday, August 13, 2003 1:07 PM > > > > To: wsbpel@lists.oasis-open.org > > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > chris - > > > > > > > > i'm not sure i see how the new functions would be used. could you > > > give > > > > an > > > > example? also, the insertVariableNode is ambiguous, as yaron has > > > > pointed > > > > out - you'd need an insertVariableNodeBefore, and an > > > > insertVariableNodeAfter. > > > > > > > > after you do that, you could include a removeVariableNode and a > > > > renameVariableNode. if you do that, you've got all the > > functionality > > > of > > > > my > > > > previous suggestion. > > > > > > > > i don't have particularly strong feelings about the syntax for the > > > > provided > > > > functionality, although i have a mild bias against XPath > functions. > > > > > > > > one thing i would like to do, however, is reconcile whatever > syntax > > we > > > > come > > > > up with with the <copy><to> syntax, as it's really just an > > > > updateVariableNode XPath function, and i think that it would be > ugly > > > to > > > > have > > > > different syntax for update than the others. > > > > > > > > danny > > > > > > > > ----- Original Message ----- > > > > From: "Chris Keller" <chris.keller@active-endpoints.com> > > > > To: <wsbpel@lists.oasis-open.org> > > > > Cc: "'Danny van der Rijn'" <dannyv@tibco.com>; <ygoland@bea.com>; > > > > <Gnosis_@compuserve.com> > > > > Sent: Wednesday, August 13, 2003 6:34 AM > > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > > > > > > Here is another idea for solving this issue. > > > > > > > > > > Allow the <to> element to contain an expression with the > following > > > > > restrictions. > > > > > - It must evaluate to exactly one node like the query > > > > > restriction. > > > > > - It must not be in an abstract process (same rationale as > > > > > query). > > > > > > > > > > Then we introduce new XPath functions which are mandatory for > BPEL > > > > > implementations. > > > > > bpws:appendVariableNode('variable', 'part', 'childQname', > > > > > 'parentPath'[, 'siblingQname']) > > > > > bpws:insertVariableNode('variable', 'part', 'childQname', > > > > > 'parentPath'[, 'siblingQname']) > > > > > > > > > > These methods could be used to create specific children at the > > right > > > > > levels. We may need to have a few more functions. But anyone > > > > > implementing a BPEL engine must already make new functions > > available > > > > to > > > > > the XPath processor. And this seems like the least deviation > from > > > the > > > > > current specification and allows some great flexibility. > Although > > > we > > > > > may need a few more functions (TBD). > > > > > > > > > > The user could theoretically use the current copy <to > > > variable='...'> > > > > > for example: > > > > > <to variable='varname' part='partname' query='querypath'/> > > > > > > > > > > Or an equivalent: > > > > > <to expression="bpws:getVariableData('varname', 'part', > > > > 'querypath')"/> > > > > > > > > > > This particular case is a little redundant, but we have that > > > somewhat > > > > > already with literal and expression, since an expression can be > > just > > > a > > > > > quoted string. > > > > > > > > > > Thoughts? > > > > > > > > > > - Chris > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > > > > Sent: Tuesday, August 12, 2003 2:05 PM > > > > > To: wsbpel@lists.oasis-open.org > > > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > > > david- > > > > > > > > > > without allowing XSLT multiple inputs, you have the choice of > > either > > > > > creating some new data, or rebuilding some variable based only > on > > > > > itself. i > > > > > submit that if we don't want to deal with multiple inputs for > XSLT > > > > (and > > > > > i > > > > > don't say that we do), then we absolutely need something like > > > XUpdate, > > > > > since > > > > > the current spec doesn't have enough data manipulation > > capabilities. > > > > > > > > > > even if we do want to deal with XSLT with multiple inputs, i > still > > > > think > > > > > we > > > > > need an XUpdate analog, since simple updates are far too > > heavyweight > > > > in > > > > > XSLT. > > > > > > > > > > i'm interested to know if satish thinks the ocean is getting > warm > > > ;-) > > > > > > > > > > ----- Original Message ----- > > > > > From: "David RR Webber - XML ebusiness" <Gnosis_@compuserve.com> > > > > > To: <ygoland@bea.com> > > > > > Cc: <wsbpel@lists.oasis-open.org> > > > > > Sent: Monday, August 11, 2003 6:55 PM > > > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points > > > > > > > > > > > > > > > Yaron, > > > > > > > > > > I'm glad you are filing this issue. > > > > > > > > > > Once you cross-over into the territory of multiple inputs, > > > > > and merging, sorting, filtering - you get beyond XSLT and > > > > > into the land of traditional data mappers. > > > > > > > > > > Why are you thinking the W3C will care about this?!? > > > > > > > > > > My 0.2cents on this - take a linear approach - > > > > > > > > > > 1) Simple transactions - a la current spec'. > > > > > > > > > > 2) More complex needs - but still relatively light - XSLT > > > > > > > > > > 3) Heavy lifting - provide a call-out mechanism and let > > > > > people choose their own toolset. > > > > > > > > > > Implementers needing this will agree amongst themselves > > > > > on what to use - we certainly do not need to start re-inventing > > > > > wheels here within BPEL - we've enough other work to > > > > > look at. > > > > > > > > > > Pass the baton - and move on. > > > > > > > > > > DW. > > > > > ================================================== > > > > > Message text written by INTERNET:ygoland@bea.com > > > > > > > > > > > Actually Chris nailed the missing feature for the XSLT proposal, > > the > > > > > ability > > > > > to submit multiple inputs. Once one can specify multiple input > > > > documents > > > > > into the transform then there is no limit to what the output can > > > look > > > > > like. > > > > > For example XSLT(foo, bar) = bar. In other words, bar is both an > > > input > > > > > and > > > > > an output of the transform. > > > > > > > > > > In any case I think there are two separate issues here. One > issue > > is > > > - > > > > > we > > > > > need support for transforms. This is true regardless of any work > > we > > > do > > > > > with > > > > > XUPDATE. I will file the issue with Peter. > > > > > > > > > > The second issue is - what is the best programming model to > solve > > > the > > > > > insert > > > > > problem? Clearly something like XUPDATE is going to be a lot > > easier > > > to > > > > > deal > > > > > with than XSLT. But I'm concerned that there is no way we can > > finish > > > a > > > > > fully > > > > > spec'd XUPDATE standard in time and it isn't even clear that > this > > is > > > > > something the BPEL TC should work on. XUPDATE sounds like a job > > for > > > > the > > > > > W3C. > > > > > < > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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 > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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]