[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 11 - Proposal For Vote
Sure, let's start a new TC in OASIS, so it will take another couple of
years before it gets finalized. In the meanwhile, all kind of
proprietary extensions to BPEL will flourish.
No, thanks.
By the way, talking of Java, why haven't you guys started standardizing
BPELJ in JSR-207? You had a great opportunity there, still a year went
by and nothing has happened yet.
Ugo
> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Wednesday, April 06, 2005 5:27 PM
> To: Ugo Corda
> Cc: Satish Thatte; wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue 11 - Proposal For Vote
>
>
> I think that COPY has some minimal utility for a few key
> scenarios but I
> do not believe it is or was ever intended to be a generic data
> manipulation language. Copy, as Satish has pointed out, was really
> intended to just enable a few very limited scenarios having
> to do with
> things like assigning partnerLinks EPRs and copying message parts.
>
> As for XUPDATE, either they will take forever because updating XML is
> hard and we should therefore not be taking it on ourselves. Or, they
> won't take forever because the subject is tractable, in which case we
> should let them get on with it and not take it on ourselves.
>
> Also, XUPDATE isn't the only language available that can manipulate
> arbitrary XML structures. XSLT, Java, Python, C, C# and so on are all
> able to manipulate arbitrary XML structures. It is preferable
> to define
> bindings to those languages than to turn BPEL into a generic
> programming
> language. As for where to standardize such bindings? There are many
> choices but OASIS would be an obvious one.
>
> Thanks,
>
> Yaron
>
> Ugo Corda wrote:
> > > Its intention was strictly to address 'programming
> > > in the large' issues, which does not include data
> > > manipulation.
> >
> > There is already a lot of data manipulation in BPEL. Are you
> > suggesting that it should be removed? Or do you think that what is
> > already there satisfies the 80/20 rule? I certainly don't.
> >
> > > It would be, in my opinion, much better were we to take
> an existing
> > > language that supports XML manipulation and provide a > standard
> > binding for it to BPEL.
> >
> > Who is going to provide this standard binding? You say it is out of
> > scope for the TC. So who else would do it? Are you thinking of
> > XUpdate? That activity basically just started from scratch
> once again
> > last February. It might take another couple of years to finalize
> > (judging from the time taken by XQuery so far).
> Standardizing an XML
> > manipulation language for BPEL a couple of years from now will be
> > completely futile: all possible damage to BPEL portability will
> > already have been done by then.
> >
> > Ugo
> >
> > > -----Original Message-----
> > > From: Yaron Y. Goland [mailto:ygoland@bea.com]
> > > Sent: Monday, April 04, 2005 6:34 PM
> > > To: Ugo Corda
> > > Cc: Satish Thatte; wsbpel@lists.oasis-open.org
> > > Subject: Re: [wsbpel] Issue 11 - Proposal For Vote
> > >
> > >
> > > BPEL is not nor was it ever intended to be a universal
> generic >
> > programming language. Its intention was strictly to address >
> > 'programming > in the large' issues, which does not include data
> > > manipulation. I think
> > > it inappropriate to bloat BPEL with features that are
> not relevant to
> > > its core mission.
> > >
> > > It would be, in my opinion, much better were we to take
> an existing
> > > language that supports XML manipulation and provide a
> > > standard binding
> > > for it to BPEL. Although such work is clearly outside the
> > > scope of the
> > > TC it is a scenario that BPEL explicitly provides
> extension hooks to
> > > support.
> > >
> > > Yaron
> > >
> > > Ugo Corda wrote:
> > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > 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]