[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 111 - Proposal For Vote
Consistency seems to e in the eye of the beholder. Having the <sources> and
<targets> buried two levels inside the top element in the activity (in this
case the extensionActivityWrapper) wrapper is not what regular activities
do. This is what I call "consistent":
<extensionActivityWrapper name="abc" ...>
<source linkName="l1"/>
<ns2:call ...> ...
</extensionActivityWrapper>
is nicely consistent with
<invoke name="abc" ...>
<source linkName="l1"/>
</invoke>
In both cases you find the link information and all other standard activity
stuff in the same place. Consistency wrt the location of core BPEL elements
and attributes (like those carrying link information and activity name)
seems much more relevant to me than architecting consistency wrt to some
yet to be defined and accepted extensions.
Paco
Alex Yiu
<alex.yiu@oracle. To: Danny van der Rijn <dannyv@tibco.com>, chris.keller@active-endpoints.com
com> cc: "'wsbpeltc'" <wsbpel@lists.oasis-open.org>, Francisco
Curbera/Watson/IBM@IBMUS, Alex Yiu <alex.yiu@oracle.com>
07/22/2005 05:09 Subject: Re: [wsbpel] Issue - 111 - Proposal For Vote
PM
Hi Chris,
If we adopt Yaron's May proposal, the similar code example will look like
the following:
(Note: the location change of <source> element)
<flow>
<links><link name="l1"></links>
<receive ...>
<target linkName="l1"/>
</receive>
<receive ...>
<ns1:assert>...expression...</ns1:assert>
<target linkName="l1"/>
</receive>
<extensionActivityWrapper>
<ns2:call process="ns:name">
<ns1:assert>...expression...</ns1:assert>
<source linkName="l1"/>
<ns2:call/>
</extensionActivityWrapper>
</flow>
Now, the syntaxes between standard activity and extended activity has a
much higher consistency, which Yaron and I are trying to achieve.
I guess that would fit Chris' preference and requirement also.
Since <source> is under BPEL NS and <call> and <assert> are under other NS
(NS1 / NS2), any BPEL processor should be able to make use this XMLNS
fundamental nature and locate the <bpel:source> under <ns2:call> easily.
Furthermore, Yaron's May proposal asserts that the XML element inside
extensionActivity wrapper "MUST make available BPEL's standard-attributes
and standard-elements" (i.e. including <bpel:source>, <bpel:target> and
etc) [Also, that is, the XML element must exhibit the syntax of an standard
activity (bpws:tActivity) ]
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
Chris Keller wrote:
Hi Danny,
You could write it that way but if your readers are setup to
find them at
the activity layer like sources and targets then they wouldn't
find them.
Right.
Plus it will be inconsistent for example:
<flow>
<links><link name="l1"></links>
<receive ...>
<target linkName="l1"/>
</receive>
<receive ...>
<target linkName="l1"/>
<ns1:assert>...expression...</ns1:assert>
</receive>
<extensionActivityWrapper>
<source linkName="l1"/>
<ns2:call process="ns:name">
<ns1:assert>...expression...</ns1:assert>
<ns2:call/>
</extensionActivityWrapper>
</flow>
Notice how standard elements will be with the wrapper but my
extended
standard elements are not.
We're in agreement there, just disagreement in how important it is to
have this kind of consistency.
- Chris
-----Original Message-----
From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Friday, July 22, 2005 1:27 PM
To: chris.keller@active-endpoints.com
Cc: 'Francisco Curbera'; 'wsbpeltc'
Subject: Re: [wsbpel] Issue - 111 - Proposal For Vote
In Paco's proposal, you would simply write that:
<extensionActivityWrapper>
<ns2:call process="ns:name">
<ns1:assert>...expression...</ns1:assert>
<ns2:call/>
</extensionActivityWrapper>
Chris Keller wrote:
Hi Paco,
I still have the one issue I mentioned in the last
meeting. This proposal
closes off the ability to add element based generic
activity extensions.
For example imagine an extension (which was actually
proposed at one time
called assert). In my extension assert may be applied to
any activity to
assert a precondition before executing the activity.
Given the schema that
you sent the following would be illegal.
<extensionActivityWrapper>
<ns1:assert>...expression...</ns1:assert>
<ns2:call process="ns:name"/>
</extensionActivityWrapper>
- Chris
-----Original Message-----
From: Francisco Curbera [mailto:curbera@us.ibm.com]
Sent: Friday, July 22, 2005 9:51 AM
To: wsbpeltc
Subject: [wsbpel] Issue - 111 - Proposal For Vote
111 - Extension Activities
Proposal: Add an extensionActivityWrapper element to
support extension
activities
Introduce Section 11.9
New activities can be introduced for use in BPEL by using
the
extensionActivityWrapper element. An
extensionActivityWrapper element MAY
contain BPEL's activity standard-attributes and
standard-elements;
additionally, it MUST contain a single extensibility
element from a
namespace different form the BPEL namespace, which
provides the information
required to execute the extensible activity.
If the extension element contained within the
extensionActivityWrapper
element is not recognized by the BPEL processor and is
not subject to a
mustUnderstand="true" requirement from an extension
declaration then the
new activity MUST be treated as if it were an empty
activity.
<extensionActivityWrapper standard-attributes>
standard-elements
<???? >
...
</????>
</extensionActivityWrapper>
Schema:
Add to activity group:
<element name="extensionActivityWrapper"
type="bpws:textensionActivityWrapper"/>
Add the following definition:
<complexType name="textensionActivityWrapper">
<complexContent>
<sequence>
<element name="targets"
type="bpws:tTargets"
minOccurs="0"/>
<element name="sources"
type="bpws:tSources"
minOccurs="0"/>
<any namespace="##other"
processContents="lax"/>
</sequence>
<attribute name="name" type="NCName"/>
<attribute name="suppressJoinFailure"
type="bpws:tBoolean"
use="optional"/>
<anyAttribute namespace="##other"
processContents="lax"/>
</complexContent>
</complexType>
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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]