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


I completely agree with Satish. It would be unfortunate for us to knowingly
create new data manipulatoin legacy. Can;t anyone that cares about that
scenarion ("scenario X") come up with a less invasive proposal?

Paco



                                                                                                                                        
                      "Satish Thatte"                                                                                                   
                      <satisht@microsof        To:       <ygoland@bea.com>, "Ugo Corda" <UCorda@SeeBeyond.com>                          
                      t.com>                   cc:       <wsbpel@lists.oasis-open.org>                                                  
                                               Subject:  RE: [wsbpel] Issue 11 - Proposal For Vote                                      
                      04/26/2005 06:42                                                                                                  
                      PM                                                                                                                
                                                                                                                                        




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





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