[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 11 - Proposal For Vote
Of course we disagree on the "undesirable aspects" part regarding the
proposal (what a surprise ...)
Ugo
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Tuesday, April 26, 2005 4:24 PM
> To: Ugo Corda; ygoland@bea.com
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 11 - Proposal For Vote
>
>
> Complete and consistent standards have a way of making
> proprietary legacies obsolete. When standards themselves
> create legacies with undesirable aspects there is a much
> stickier problem as we will discover with WSDL 1.1.
>
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Tuesday, April 26, 2005 3:53 PM
> To: Satish Thatte; ygoland@bea.com
> Cc: wsbpel@lists.oasis-open.org
> 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
>
>
> ---------------------------------------------------------------------
> 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]