[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 11 - Call for Discussion
Yaron, I hear you. I'm still seeing that a declarative approach to allowing linkage section area to be used as a staging area makes most sense. That way you avoid the mechanics of small-language information manipulation creeping into BPEL - and then this makes sense to provide the link out to the small language module (acting as a web service - retreive / reply action). Before anyone asks me to provide some XML syntax - best if someone else who knows the BPEL much better do this - at this point I'm programming BPEL in PPT - so anything lower than that and I'm dangerous. But I suspect you do need this feature - and ability to receive a reply and iterate within the linkage section so you have mulitiple entries of that specific line item as the replies come in. Trivial notion to understand and implement as an attribute allow_multiple="Yes". DW. ----- Original Message ----- From: "Yaron Y. Goland" <ygoland@bea.com> To: "Alex Yiu" <alex.yiu@oracle.com> Cc: "Danny van der Rijn" <dannyv@tibco.com>; "Wsbpel@Lists. Oasis-Open. Org (E-mail)" <wsbpel@lists.oasis-open.org> Sent: Thursday, February 26, 2004 2:44 PM Subject: Re: [wsbpel] Issue 11 - Call for Discussion > There are many basic things BPEL can't do and that is just fine. As was > said at the first presentation on the first day of the first > face-to-face of the BPEL TC, BPEL's design presumes the existence of a > companion language that will handle, to use IBM's terminology, > "Programming In the Small." > > BPEL's job is to specify "Programming in the Large" and leave details of > how to bind specific companion languages to BPEL to the owners of those > languages. > > XML manipulation is an example of "Programming in the Small" and > therefore I believe it is generally out of scope for BPEL. Even worse, > any proposal we do come up with will just become instant legacy as > efforts like XUPDATE and standards for companion languages to BPEL are > released. > > Personally, I think we should close Issue 11 as - take no action. > > Just My Two Euros, > > Yaron > > P.S. I find the whole argument about XQUERY being side effect free > confusing. It would be trivial to create an assign where the source is > the output of a XQUERY. At that point the XQUERY itself would be side > effect free but the output wouldn't be. > > > Alex Yiu wrote: > > > Hi, Danny and all others, > > > > > > Here is our take on issue 11 so far (after consulting with some internal and > > external people). > > I hope you would find the points below make senses. > > (In short, I am for Danny's changes with some minor modification and clarification) > > > > > > Thanks! > > > > Regards, > > Alex Yiu > > > > > > =========================== > > > > > > BPEL Issue 11 > > > > Whether to add: > > > > We feel comfortable of adding some extra basic XML manipulation operations to > > BPEL, as long as we do not run into a slippery slope business and BPEL TC > > members understand and agree that BPEL is NOT targeted as a full blown XML > > manipulation and / or transformation language. The reasons that we feel it is OK > > to add those basic operations: > > > > * XQuery and XPath are side-effect-free languages. XQuery does NOT modify > > existing XML data. It will only construct a new piece of document. > > * The new W3C XUpdate WG is kind of in its bootstrapping mode now. It will > > take at least a year or two for it to become stable for BPEL vendors to use. > > * Without any BPEL side-effect-ful assign-like constructs, we cannot even do > > some the simplest XML data modification. For simple XML data modification, > > it may be an overkill to ask BPEL developers to cross the language > > boundary to use another programming language. > > > > > > We can and should restraint ourselves by emulating structure modification > > semantics supported by W3C DOM API. There are ONLY 4 API: > > > > * replaceChild (already done in assign/copy), > > * appendChild > > * insertBefore > > * removeChild > > > > insertAfter functionality can be done by appendChild and insertBefore. E.g.: > > insertAfter into "/po/item[$index]" can be done by insertBefore into > > "/po/item[$index+1]" or appendChild. > > > > How to add: > > > > We agree Danny's proposal in general. We would suggest to add some minor > > modification and some clarification it. > > > > (1) appendChild: > > > > <assign> > > <appendChild> > > <from variable="..." part="..."? query="..."? /> > > <!-- restricted version of from-spec --> > > <to variable="..." part="..."? query="..."? /> > > <!-- restricted version of to-spec --> > > <!-- no child integer index supported --> > > </appendChild> > > </assign> > > > > (Question: With child integer index, will appendChild make look like > > insertAfter? So, do we want to drop it?) > > > > (2) insertBefore: > > > > <assign> > > <insertBefore> > > <from variable="..." part="..."? query="..."? /> > > <!-- restricted version of from-spec --> > > <to variable="..." part="..."? query="..."? /> > > <!-- restricted version of to-spec --> > > </insertBefore> > > </assign> > > > > > > (3) remove: > > > > <remove> > > <from variable="..." part="..."? query="..."? /> > > <!-- restricted version of from-spec --> > > </remove> > > > > (Question: do we want to support remove a message part? I guess not. ) > > > > Note: > > > > * We may want to reuse the syntax of from-spec and to-spec by restricting > > it. Then, it is easier for BPEL users to learn and for BPEL vendor to do > > code reuse. > > * For from-spec, we would use variable version of from-spec only (as Danny > > suggested in the email) > > * For to-spec used in appendChild and insertBefore, we would use variable > > version of to-spec only. > > * We can also have altenative syntax for merging insertBefore and > > appendChild to <copy>. e.g.: > > o <copy operation="replace"> > > o <copy operation="insertBefore"> > > o <copy operation="appendChild"> > > > > =========================== > > > > > > > > Danny van der Rijn wrote: > > > >>select is the same as query. it should probably be renamed query, but was > >>left over from the last round of discussions. > >> > >>danny > >> > >>----- Original Message ----- > >>From: "Edwin Khodabakchian" <edwink@collaxa.com> > >>To: "'Danny van der Rijn'" <dannyv@tibco.com>; "'Wsbpel@Lists. Oasis-Open. > >>Org (E-mail)'" <wsbpel@lists.oasis-open.org> > >>Sent: Monday, February 23, 2004 3:29 PM > >>Subject: RE: [wsbpel] Issue 11 - Call for Discussion > >> > >> > >> > >> > >>>Hi Danny, > >>> > >>>Could you please clarify how the select attribute would work when the to > >>>variable is a message? Is this intentional or do you use select as a > >>>placeholder for part/query? > >>> > >>>Thank you for the clarification, > >>> > >>>Edwin > >>> > >>>-----Original Message----- > >>>From: Danny van der Rijn [mailto:dannyv@tibco.com] > >>>Sent: Monday, February 23, 2004 10:29 AM > >>>To: 'Wsbpel@Lists. Oasis-Open. Org (E-mail)' > >>>Subject: [wsbpel] Issue 11 - Call for Discussion > >>> > >>>maybe people are as tired of discussing issue 11 as I am, but if it stays > >>>this quiet, I may just have to put up a proposal for vote. Here's the > >>>current proposal, which includes additions inspired by Glenn Mi. > >>> > >>> > >>>under the <assign> element, there will be 6 possible > >>>elements, where now there is only 1. > >>> > >>><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 > >>> > >>>----- Original Message ----- > >>>From: "Danny van der Rijn" <dannyv@tibco.com> > >>>To: "'Wsbpel@Lists. Oasis-Open. Org (E-mail)'" > >>> > >>> > >><wsbpel@lists.oasis-open.org> > >> > >> > >>>Sent: Wednesday, February 18, 2004 5:10 PM > >>>Subject: Re: [wsbpel] Issue 11 - It's Baaaack > >>> > >>> > >>> > >>> > >>>>----- Original Message ----- > >>>>From: "Glenn Mi" <gmi@collaxa.com> > >>>>To: "Danny van der Rijn" <dannyv@tibco.com>; "'Wsbpel@Lists. Oasis-Open. > >>>> > >>>> > >>>Org > >>> > >>> > >>>>(E-mail)'" <wsbpel@lists.oasis-open.org> > >>>>Sent: Wednesday, February 18, 2004 4:54 PM > >>>>Subject: RE: [wsbpel] Issue 11 - It's Baaaack > >>>> > >>>> > >>>> > >>>> > >>>>>Danny: > >>>>> > >>>>>I start to like your proposal more now. Two points I want to add: > >>>>> > >>>>>1) In your <to> construct, it seems that we can just use > >>>>>one of > >>>>> > >>>>><to variable="ncname" property="qname"/> and > >>>>><to variable="ncname" part="ncname"? query="queryString"?/> > >>>>> > >>>>>Or does your select="XPath Expression evaluates to one node" > >>>>>actually mean the normal to-spec construct ? > >>>>> > >>>>> > >>>>yes. the normal to-spec, but restricted to variables, and their parts. > >>>>i.e. not partnerlinks, etc. in the spec, this is the "first" form of > >>>> > >>>> > >>the > >> > >> > >>>>to-spec referred to in 9.3, and extended for executable processes in > >>>> > >>>> > >>14.3 > >> > >> > >>>>>2) And there are cases to insert and remove part of a message variable > >>>>>(varable defined as <variable name="abc" messageType="ns:xyz"/>). In > >>>>> > >>>>> > >>>those > >>> > >>> > >>>>>cases you don't need query string and you don't care about the order. > >>>>>So it make sense to have something like: > >>>>> > >>>>><insert> > >>>>><from .../> > >>>>><to variable="abc" part="def"/> > >>>>></insert> > >>>>> > >>>>> > >>>>unless i'm mistaken, <copy> can be used here. > >>>> > >>>> > >>>> > >>>>>and > >>>>> > >>>>><remove variable="abc" part="def"/>. > >>>>> > >>>>> > >>>>you are correct. this should be added. i believe that this is the only > >>>> > >>>> > >>>one > >>> > >>> > >>>>of the new 4, though, that should have "select" be optional. > >>>> > >>>> > >>>> > >>>> > >>>>>Glenn > >>>>> > >>>>>-----Original Message----- > >>>>>From: Danny van der Rijn [mailto:dannyv@tibco.com] > >>>>>Sent: Wednesday, February 18, 2004 3:19 PM > >>>>>To: 'Wsbpel@Lists. Oasis-Open. Org (E-mail)' > >>>>>Subject: Re: [wsbpel] Issue 11 - It's Baaaack > >>>>> > >>>>> > >>>>>to preempt the pedantic among us, there's a copy/paste error in the > >>>>>proposal. it should read: > >>>>>"under the <assign> element, there will be 5 possible elements, where > >>>>> > >>>>> > >>>now > >>> > >>> > >>>>>there is only 1." > >>>>> > >>>>>----- Original Message ----- > >>>>>From: "Danny van der Rijn" <dannyv@tibco.com> > >>>>>To: "'Wsbpel@Lists. Oasis-Open. Org (E-mail)'" > >>>>> > >>>>> > >>>><wsbpel@lists.oasis-open.org> > >>>> > >>>> > >>>>>Sent: Wednesday, February 18, 2004 3:16 PM > >>>>>Subject: [wsbpel] Issue 11 - It's Baaaack > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>during today's conference call, we took a straw poll, where > >>>>>> > >>>>>> > >>>>approximately > >>>> > >>>> > >>>>>>2/3 voted to attempt to resolve issue 11. (i'll leave the exact > >>>>>> > >>>>>> > >>count > >> > >> > >>>>to > >>>> > >>>> > >>>>>>the minutes). i would like to resurrect a large part of my previous > >>>>>>proposal (i'll drop "rename"). to me, this is a viable proposal, > >>>>>> > >>>>>> > >>and > >> > >> > >>>i > >>> > >>> > >>>>>>would be satisifed if it ended up being adopted into the spec. > >>>>>> > >>>>>> > >>>however, > >>> > >>> > >>>>>>maybe in the months since we last thought about it, someone else has > >>>>>> > >>>>>> > >>a > >> > >> > >>>>>>reasonable alternative. > >>>>>> > >>>>>>danny > >>>>>> > >>>>>>My proposal: under the <assign> element, there will be 6 possible > >>>>>>elements, where now there is only 1. > >>>>>> > >>>>>><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 > >>>>>> > >>>>>> > >>>>>>To unsubscribe from this mailing list (and be removed from the > >>>>>> > >>>>>> > >>roster > >> > >> > >>>of > >>> > >>> > >>>>>the OASIS TC), go to > >>>>> > >>>>> > >>>>> > >>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgrou p. > >> > >> > >>>>>php. > >>>>> > >>>>> > >>>>>To unsubscribe from this mailing list (and be removed from the roster > >>>>> > >>>>> > >>of > >> > >> > >>>>the > >>>> > >>>> > >>>>>OASIS TC), go to > >>>>> > >>>>> > >>>>> > >>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgrou p. > >> > >> > >>>>>php. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>To unsubscribe from this mailing list (and be removed from the roster > >>>>> > >>>>> > >>of > >> > >> > >>>>the OASIS TC), go to > >>>> > >>>> > >>>> > >>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgrou p. > >> > >> > >>>php. > >>> > >>> > >>>>To unsubscribe from this mailing list (and be removed from the roster of > >>>> > >>>> > >>>the OASIS TC), go to > >>> > >>> > >>> > >>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgrou p. > >> > >> > >>>php. > >>> > >>> > >>>To unsubscribe from this mailing list (and be removed from the roster of > >>> > >>> > >>the > >> > >> > >>>OASIS TC), go to > >>> > >>> > >>> > >>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgrou p. > >> > >> > >>>php. > >>> > >>> > >>> > >>> > >> > >> > >>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > >> > >> > >> > > To unsubscribe from this mailing list (and be removed from the roster of the > > OASIS TC), go to > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]