[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 11 - Proposal For Vote
I conclude that you prefer lack of portability and the establishing of various proprietary legacies to a single standard-based legacy. Well, we are all entitled to our choices, and that is the beauty of the voting process ;-). Ugo > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Tuesday, April 26, 2005 3:43 PM > To: ygoland@bea.com; Ugo Corda > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue 11 - Proposal For Vote > > > And much good has been attributed, without cause :-) > > But to come back to 11, I happen to agree completely with > Yaron that solving the XML data handling problem in any real > sense is out of scope for BPEL, and solving it in some very > limited way within BPEL to address scenario X that some > subset of people cares deeply about would be doing major > disservice to the XML web services architecture by creating > marginally useful legacy that becomes a significant long term > support cost for the entire industry. > > I certainly would vote against the proposal in its present form. > > Satish > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Monday, April 11, 2005 11:54 AM > To: Ugo Corda > Cc: wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue 11 - Proposal For Vote > > Alas, any number of evils have been committed in my name. :) > > Ugo Corda wrote: > > > I want to make sure that the quality of the BPEL spec is > maintained. > > > > Hmmm, the BPEL 1.1 spec described everything only in terms of the > > expression language. Are you saying that it was of poor quality? > (Before > > you answer, please keep in mind that you are listed as one > of BPEL 1.1 > > authors ;-). > > > > Ugo > > > > > -----Original Message----- > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > Sent: Friday, April 08, 2005 11:47 AM > > > To: Ugo Corda > > > Cc: wsbpel@lists.oasis-open.org > > > Subject: Re: [wsbpel] Issue 11 - Proposal For Vote > > > > > > > > > Please see below > > > > > > Ugo Corda wrote: > > > > > The result is that you can swap out expression > > > > > languages at will in BPEL and none of the 103 > specified > > > > > behaviors break. > > > > > > Of course it will break. Part of the 103 specified > behavior is a > > > > definition of the XPath 1.0 binding. If you replace XPath with > > > > something else, those sections will not be valid any more > > > and you'll > > > > have to write new bindings descriptions. > > > > > > > > > > As 103 explicitly points out there are two views of language > > > bindings. > > > There is how BPEL views languages and there is how languages > > > view BPEL. > > > > > > All aspects of BPEL's view of languages is written using > > > generic infoset > > > structures so that it is 100% independent of > expression language. > > > > > > What is expression language specific, and by definition must > > > be, is the > > > binding of the expression language to BPEL. > > > > > > But by defining BPEL's view of the expression languages in > > > infoset terms > > > you can swap out which expression language you are using and > > > none of the > > > BPEL specified requirements or behaviors change. > > > > > > > > I can find no reason why issue 11 should be held to a lesser > > > > > > standard of portability. > > > > > > > > This is a typical red herring. As you have already stated, you > are > > > > against adding this functionality to BPEL, so you > would > vote > > against > > the proposal even if it was expressed in > infoset terms. I > > > don't even > > > > know why I am spending any time discussing this. > > > > > > > > > > While it is true that I do not support the goals of issue 11 > > > I want to > > > make sure that the quality of the BPEL spec is maintained. So if > the > > > group decides they do want to add issue 11 functionality > then > we > > should > do it correctly and in a language neutral manner. > > > > > > Yaron > > > > > > > Ugo > > > > > > > > > -----Original Message----- > > > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > > > Sent: Wednesday, April 06, 2005 5:25 PM > > > > > To: Ugo Corda > > > > > Cc: wsbpel@lists.oasis-open.org > > > > > Subject: Re: [wsbpel] Issue 11 - Proposal For Vote > > > > > > > > > > > > > > > The reason why 103 doesn't define 14.3 in terms of the > > > infoset is > > > > > because, as Alex and I explained in New York, we couldn't > > > > solve > > > > all the > world's problems in 103. As such we explicitly > > > stated that > > > > we > expected > > > > > the translation of copy to infoset terms to happen as a > > > > > consequence of > > > > > issues 51 and 157 and therefore only made the > minimum changes > > > > > necessary > > > > > to 14.3 to allow us to implement the areas that 103 > addressed. > > > > > > > > > > However I think it is instructive to observe that 103 is > > > written such > > > > > that BPEL's view of expression languages is always > > > specified using > > > > > infoset terminology. The result is that you can swap out > > > expression > > > > > languages at will in BPEL and none of the 103 specified > > > > > behaviors break. > > > > > > > > > > I can find no reason why issue 11 should be held to a lesser > > > > > standard of > > > > > portability. > > > > > > > > > > Yaron > > > > > > > > > > Ugo Corda wrote: > > > > > > My point is that I find it strange that you are asking > > > to avoid the > > > > > > use of an expression language terminology, when > you are the > > > > > one using > > > > > > that same terminology in your latest approved proposal for > > > > > issue 103 > > > > > > (as I quoted below). > > > > > > > > > > > > The idea that using a generic infoset approach makes BPEL > > > > > independent > > > > > > of expression languages is an illusion. What BPEL is > > > > > talking about in > > > > > > the "from" and "to" parts are expressions. So you > > > still have to map > > > > > > from the chosen expression language to the infoset > > > representation. > > > > > > That mapping, which is an integral part of the "from" and > "to" > > > > > > semantics, can only be specified when you know which > expression > > > > > > language you are dealing with. So I don't see how > you can > > > > > claim that > > > > you are making BPEL independent of > > expression > languages. What we > > > > > > should really say is that so far we know well how to use > > > > > XPath 1.0 in > > > > > > BPEL, but we can only hint at using alternative expression > > > > > languages > > > > > > like XQuery/XPath 2.0. > > > > > > > > > > > > I am perfectly happy with using an expression language > > > terminology, > > > > > > but I would not have any particular problem considering an > > > > > alternative > > > > > > proposal based on infoset language (because, as I said > > > > > before, it does > > > > > > not change the substance of things in any important way). > > > > > If you want > > > > > > to offer a counterproposal that is based on infoset, I > > > > > might very well > > > > > > be willing to take it as a friendly amendment. > > > > > > > > > > > > Ugo > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > > > > > Sent: Monday, April 04, 2005 6:29 PM > > > > > > > To: Ugo Corda > > > > > > > Cc: wsbpel@lists.oasis-open.org > > > > > > > Subject: Re: [wsbpel] Issue 11 - Proposal For Vote > > > > > > > > > > > > > > > > > > > > > I'm not sure I understand your point. Are you > suggesting > > > > > that > a > > > > > > generic > infoset approach which makes BPEL > independent of > > > > > expression > > > > > > > language is > > > > > > > wrong or are you suggesting that you are being > > > asked to carry > > > > > > > a greater > > > > > > > burden than others in the group have borne? > > > > > > > > > > > > > > Yaron > > > > > > > > > > > > > > Ugo Corda wrote: > > > > > > > > Well, let's look, for example, at the latest > version of > > > > > > > this section > > > > > > > > 14.3 paragraph (from the resolution to issue 103): > > > > > > > > > > > > > > > > "The from-spec and to-spec MUST yield a node-set that > > > > > > > contains exactly > > > > > > > > one node. If the from-spec or to-spec selects > > > zero nodes or > > > > > > > more than > > > > > > > > one node during execution, then the standard fault > > > > > > > > bpws:selectionFailure MUST be thrown by a compliant > > > > > implementation". > > > > > > > > > > > > > > > > I don't see any generic infoset terminology in that > > > > > > > paragraph either. > > > > > > > > > > > > > > > > Ugo > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > > > > > > > Sent: Thursday, March 31, 2005 1:53 PM > > > > > > > > > To: Ugo Corda > > > > > > > > > Cc: wsbpel@lists.oasis-open.org > > > > > > > > > Subject: Re: [wsbpel] Issue 11 - Proposal For Vote > > > > > > > > > > > > > > > > > > > > > > > > > > > This proposal does not use infoset > > > terminology. In fact, the > > > > > > > > proposal > looks to be XPATH specific. > Defining issue > 11 > > > > > > > in terms of > > > > > > > > XPATH > semantics would mean that the issue 11 > features > > > > > > > could change > > > > > > > > in > functionality based on which > expression languages > > > > > > > were used as > > > > > > the > source or > destination. > > Minimally a proposal to > > > > > resolve this > > > > > > > > > issue should > be written using generic infoset > > > > > > > terminology so that > > > > > > > > issue 11 > behavior > > > > > > > > > will be consistent regardless of expression > language. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > Yaron > > > > > > > > > > > > > > > > > > Ugo Corda wrote: > > > > > > > > > > I have been working on a resolution of > this issue > > > > > with a few TC > > > > > > > > members who are > interested in > > a type of > > > resolution like the > > > > > > > > > one that > > > > > > > > > > Danny presented a few months ago. > Please find our > > > > > > > current proposal > > > > > > > > > > attached. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Ugo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Issue 11 - Proposal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. Append > > > > > > > > > > > > > > > > > > > > Syntax: > > > > > > > > > > <bpel:assign> > > > > > > > > > > <bpel:append> > > > > > > > > > > <bpel:from ... /> > > > > > > > > > > <bpel:to ... /> > > > > > > > > > > </bpel:append> > > > > > > > > > > </bpel:assign> > > > > > > > > > > > > > > > > > > > > The from-spec within <append> yields a > > > single node or a > > > > > > > > > node set. Note > > > > > > > > > > that the > > > > > > > > > > from-spec of <bpel:copy> still MUST > yield > ONLY > > one node. > > > > > > > The node set will be > > > > > > > > > > processed in document order (unless an > > > > > alternative order is > > > > > > > > > specified in the > > > > > > > > > > underlying query language). If the from-spec > > > yields atomic > > > > > > > > > values (e.g. > > > > > > > > > > numbers), those atomic values can be > > > converted to text > > > > > > > > > nodes, when needed. If > > > > > > > > > > the from-spec yields zero node, > > > "bpel:selectionFailure" > > > > > > > > > fault MUST be thrown. If > > > > > > > > > > the from-spec yields an attribute node, then > > > > > > > > > "bpel:selectionFailure" fault MUST > > > > > > > > > > be thrown. > > > > > > > > > > > > > > > > > > > > {{ Background context note on XPath 1.0 and > > > XSLT 1.0: the > > > > > > > > > selected set > > > > > > > > > > of nodes > > > > > > > > > > by XPath 1.0 in XSLT 1.0 is processed in > > > document order. > > > > > > > > > Hence, it is feasible > > > > > > > > > > and natural to process the nodes selected by > > > the from-spec > > > > > > > > > in the document order > > > > > > > > > > in <append> and other similar XML data > > > operations. For > > > > > > > > > details, please see > > > > > > > > > > section 5.4 in [XSLT1.0] specification. }} > > > > > > > > > > > > > > > > > > > > The to-spec MUST yield one single > element node as > the > > > > > > > > > target element > > > > > > > > > > node. > > > > > > > > > > Otherwise, "bpel:selectionFailure" > fault will be > > > > > generated. > > > > > > > The to-spec cannot > > > > > > > > > > refer to a partnerLink. The node-set > returned by > the > > > > > > > > > from-spec will be appended > > > > > > > > > > orderly as child nodes to the target > element node. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2. Insert > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.1 insertBefore > > > > > > > > > > > > > > > > > > > > Syntax: > > > > > > > > > > <bpel:assign> > > > > > > > > > > <bpel:insertBefore> > > > > > > > > > > <bpel:from ... /> > > > > > > > > > > <bpel:to ... /> > > > > > > > > > > </bpel:insertBefore> > > > > > > > > > > </bpel:assign> > > > > > > > > > > > > > > > > > > > > The restriction and semantics of from-spec under > > > > > > > insertBefore is > > > > > > > > > > similar to > > > > > > > > > > those in the case of <bpel:append>. > > > > > > > > > > > > > > > > > > > > The to-spec under <insertBefore> MUST points to > > > > > one or more > > > > > > > > > nodes. If > > > > > > > > > > more than > > > > > > > > > > one nodes are returned, the first node will > > > be used as the > > > > > > > > > reference node. The > > > > > > > > > > word "first" here means respect to the order > > > of the node > > > > > > > > > set selected by > > > > > > > > > > to-spec, which is by default in document > > > order, unless an > > > > > > > > > alternative order is > > > > > > > > > > specified in the underlying query language. > > > > > > > > > > > > > > > > > > > > The reference node MUST be an element node. The > > > > > parent of the > > > > > > > > > > reference node > > > > > > > > > > MUST be an element node also. Otherwise, > > > > > > > > > "bpel:selectionFailure" fault will be > > > > > > > > > > generated. The to-spec cannot refer to a > partnerLink. > > > > > > > > > > > > > > > > > > > > The node set generated by the from-spec > will be > > > > > > > inserted before the > > > > > > > > reference > > > > > > > > > > node in the document order (unless an > > > alternative order is > > > > > > > > > specified in the > > > > > > > > > > underlying query language). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.2 insertAfter > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Syntax: > > > > > > > > > > <bpel:assign> > > > > > > > > > > <bpel:insertAfter> > > > > > > > > > > <bpel:from ... /> > > > > > > > > > > <bpel:to ... /> > > > > > > > > > > </bpel:insertAfter> > > > > > > > > > > </bpel:assign> > > > > > > > > > > > > > > > > > > > > <insertAfter> is very similar to > > > <insertBefore>. Except: > > > > > > > > > > > > > > > > > > > > * If more than one nodes are returned by > > > the to-spec, > > > > > > > > > the last node will be > > > > > > > > > > used as the reference node. The word > > > "last" here > > > > > > > > > means respect to the > > > > > > > > > > order of the node set selected by > > > to-spec, which is > > > > > > > > > by default in document > > > > > > > > > > order, unless an alternative order is > > > specified in > > > > > > > > > the underlying query > > > > > > > > > > language. > > > > > > > > > > * Instead of inserting nodes before the > > > > > reference node, > > > > > > > > > the nodes selected > > > > > > > > > > by will be inserted after the > > > reference node in the > > > > > > > > > document order (unless > > > > > > > > > > an alternative order is specified in > > > the underlying > > > > > > > > > query language). > > > > > > > > > > * This operation can also be considered > > > a macro of > > > > > > > > > conditional-switch + > > > > > > > > > > (append or insertBefore). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3. Remove > > > > > > > > > > > > > > > > > > > > Syntax: > > > > > > > > > > <bpel:assign> > > > > > > > > > > <bpel:remove> > > > > > > > > > > <bpel:target ... /> > > > > > > > > > > </bpel:append> > > > > > > > > > > </bpel:assign> > > > > > > > > > > > > > > > > > > > > The syntax of "bpel:target" is similar to > > > and a subset of > > > > > > > > > to-spec used > > > > > > > > > > in <copy> > > > > > > > > > > with the "partnerLink" attribute removed. > > > Similarly, XPath > > > > > > > > > 1.0 is used as the > > > > > > > > > > default query language for <target>-spec. > > > > > > > > > > > > > > > > > > > > This <remove> operation remove nodes > specified by > the > > > > > > > <target>-spec > > > > > > > > > > from their > > > > > > > > > > parent nodes. Nodes specified by > <target>-spec MAY > be > > > > > > > > > multiple. Nodes being > > > > > > > > > > removed can be: text nodes, attribute > nodes and > > > > > element nodes. > > > > > > > > > > > > > > > > > > If the <target>-spec returns zero node, then > > > > > > > > > "bpel:selectionFailure" > > > > > > > > > > fault MUST > > > > > > > > > > be thrown. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reference: > > > > > > > > > > > > > > > > > > > > * [XSLT1.0] http://www.w3.org/TR/xslt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [date: 2005-03-30] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > To unsubscribe, e-mail: > > > > > wsbpel-unsubscribe@lists.oasis-open.org > > > > > > > > > > For additional commands, e-mail: > > > > > > > wsbpel-help@lists.oasis-open.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS > TC that generates this mail. You may a link to this group > and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr oups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]