[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]