Yes, 111 is the
right approach IMO. Keeping at least one <copy> in assign forces you to
use it as assign (yes I know you can always make a no-op copy but there is only
so far we can go with syntax). Using a set of semantic considerations (e.g.,
atomicity) specially designed for assign for something entirely different by
stealth is what I am uncomfortable with.
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Monday, December 13, 2004 7:20 AM
To: Alex Yiu
Cc: Ron Ten-Hove; Satish Thatte; wsbpeltc; Danny van der Rijn; Alex Yiu
Subject: Re: [wsbpel] Making
<assign> truely extensible (related to Issue 11)
Hi,
One more point to add:
In theory / according to the current grammar, we have not really enabled a
standalone extended activity yet. In order to have a standalone
"foobar" activity, the "foobar" needs to be piggy-backed on
<empty> activity.
Hopefully, Issue 111 (filed by Yaron) will take care of that:
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue111
Regards,
Alex Yiu
Alex Yiu wrote:
Hi, Satish and Ron,
Yes, guess from Satish and Ron is correct. My intention is to reuse
<assign> for its atomicity.
I also agree with Ron regarding to his comment on portability and
non-portability.
Currently, it is already legal to do the following:
<assign>
<foo:barOperation ... />
<copy> ... </copy>
</assign>
This changes in syntax does not make it <assign> less portable or more
portable. I shared this viewpoint when I was discussing with Danny.
My proposal is merely fixing the extensiblity of <assign>. Making
<assign> equipped with a truely usable extensibility.
Thanks!
Regards,
Alex Yiu
Ron Ten-Hove wrote:
Satish,
At the very least, arbitrary ordering of extension elements
within an <assign> ought to allowed, to allow specification of the of
execution within the atomic "block."
It seems to me that the atomicity property of an
<assign> must be preserved, even with extensions, otherwise the semantics
of <assign> is violated. Placing "foobar" within an
<assign> is a natural way to express the idea that it preserves the
atomicity, in a way that is consistent with BPEL.
This is no more "dangerous" than any other
extension to BPEL. The author of "foobar" (or any other extension)
must not change the semantics of BPEL. The user of "foobar" must be
aware that such extensions are non-portable. The TC should make such extensions
practical, and this is precisely what Alex's suggestion is about.
-Ron
Satish Thatte wrote:
A question: if
you are not going to use any <copy> elements, what exactly are you
reusing from <assign>? Why not just invent your own
“foobar” activity?
By reusing
<assign> but with no <copy> are you reusing rules such as
“atomicity” for your own “foobar” behavior? This
seems rather dangerous to me.
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Saturday, December 11, 2004 7:23 PM
To: wsbpeltc
Cc: Alex Yiu; Danny van der Rijn
Subject: [wsbpel] Making
<assign> truely extensible (related to Issue 11)
Hi, all,
Currently, <assign> is an BPEL extensible activity element. That means
people can potentially add some other construct under <assign> to denote
some of operations that the spec do not define. (So, the other operations can
be still under the same atomic assignment unit.)
However, the BPEL syntax grammar (including its XMLSchema) requires at least
one <copy> under <assign>. That is:
<assign
standard-attributes>
standard-elements
<copy>+
from-spec
to-spec
</copy>
</assign>
That implies we cannot have just one extended operation under the
<assign> syntax. E.g.:
<assign>
<foo:barOperation ... />
</assign>
Due to the current usage of XML Schema definition, it also forces the extension
element must appear before the <copy> element. E.g.: the following usage
is disallowed by the current schema design:
<assign>
<copy> ... </copy>
<foo:barOperation ... />
</assign>
In order to have the true spirit of extensibility of <assign> syntax, we
would like to suggest the following syntax changes:
<assign standard-attributes>
standard-elements
(
<copy>
from-spec
to-spec
</copy> |
any-element-of-other-namespace
)*
</assign>
Related Schema Change:
From:
-------------------------------------
<complexType name="tAssign">
<complexContent>
<extension base="bpws:tActivity">
<sequence>
<element
name="copy" type="bpws:tCopy"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
-------------------------------------
To:
-------------------------------------
<complexType name="tAssign">
<complexContent>
<extension base="bpws:tActivity">
<sequence minOccurs="0">
<element name="copy" type="bpws:tCopy" />
<choice minOccurs="0" maxOccurs="unbounded">
<element name="copy" type="bpws:tCopy" />
<any namespace="##other" processContents="lax"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
-------------------------------------
[Note: the XSD changes is not that straightforward because we want to avoid the
non-deterministic choice content model problem due to XSD semantics and our
current usage of its extension mechansim.]
I have been talking with Danny (cc'ed).
One of possible ways to pass this change as a sub issue of Issue 11 (i.e. Issue
11.1).
Thoughts?
Anyway, I guess we can discuss this a bit more during F2F.
I would like to send this out earlier for people to have more time to gather
their thought.
Thanks!
Regards,
Alex Yiu