[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]