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