OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue 11 - Proposal For Vote


> 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.

> 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.

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
> >  > >  >
> >  > >  >
> >  > >
> >  >
> >  >
> > 
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]