[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 11 - Proposal For Vote
While you worry about the slippery slope, I am even more concerned about
the portability problems caused by lack of support for the most
elementary assignment capabilities, like being able to incrementally add
instances of a repeating element inside a loop.
This threat to portability is quite real. As far as I know, most
existing BPEL implementations have already introduced their own
proprietary extensions in order to overcome these limitations. For what
I can see, this area stands out as the most likely source of serious
portability problems for BPEL.
Ugo
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Sunday, April 03, 2005 11:36 PM
> To: Ugo Corda
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 11 - Proposal For Vote
>
>
> The copy operation is minimally needed to construct WSDL
> messages out of parts, and to assign partnerLinks and
> properties, which are core BPEL concepts. I agree with you
> that strict consistentcy requires we remove other options but
> we have chosen to take one simple step beyond but with the
> principle that we do not allow changing the XML structure of
> the destination of an assignment. Thus query-based
> assignment is really the same as property assignment but
> without explicit property definition. I find this a good
> place to stop to avoid stepping on a really steep slippery slope.
>
> ________________________________
>
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Sun 4/3/2005 10:28 PM
> To: Satish Thatte
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 11 - Proposal For Vote
>
>
>
> I would better understand your position if you were also
> proposing to remove the "copy" operation from the language.
> Why leave a "copy" operation with grossly crippled functionality?
>
> Ugo
>
> > -----Original Message-----
> > From: Satish Thatte [mailto:satisht@microsoft.com]
> > Sent: Sunday, April 03, 2005 10:06 PM
> > To: Ugo Corda; ygoland@bea.com
> > Cc: wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] Issue 11 - Proposal For Vote
> >
> >
> > Regardless of language, I still don't understand why it is
> useful to
> > add a small subset of the DOM API in BPEL statement form. While I
> > understand the desire for completeness, we need to
> recognize that BPEL
> > is in fact not a complete language. This seems to me like a (very)
> > partial solution to the problem of XML data manipulation in
> processes,
> > which in fact is outside our scope and hence its solution
> is best left
> > outside the language. Web service invocations already act as
> > completely general XML transducers in principle and we will
> > have enough extensibility to invent new transducers using
> > other technologies.
> >
> > ________________________________
> >
> > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> > Sent: Thu 3/31/2005 2:37 PM
> > To: ygoland@bea.com
> > Cc: wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] Issue 11 - Proposal For Vote
> >
> >
> >
> > 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
> >
> >
> >
> >
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]