[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. 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. objection #3: i'm not thrilled with the overloading (optional parameter changes function from append to insert). objection #4: might not be an objection, but it looks to me like some of the parameters are redundant. feeling like a lot of progress is being made (even if it's just the 2 of us reading...) 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]