I agree with Alex's that whether or not the extensible activity can be
ignored depends on whether the extension elements are required or not. So
this is up to the mechanism we eventually define to resolve issue 92.
Assuming that you can always ignore the activity contents and treat the
whole thing as <empty> does not seem consistent with the notion of
mandatory extensions.
The syntax of the extensible activity should be aligned with other
activities as much as possible of course.
Finally, I don't buy Alex' XSD-centric argument for reviewing the
resolution of 111.1. Let's not go there again - please.
Paco
Alex Yiu
<alex.yiu@oracle. To: Frank Leymann <>
com> cc: "'wsbpeltc'" <>, Alex Yiu
<>
03/26/2005 11:36 Subject: Re: AW: [wsbpel] Issue 111 - Proposal For Vote
PM
Hi,
After reading this proposal more closely, I guess what Yaron means might
be: the general optional nature of BPEL's standard attributes and standard
elements.
On the other hand, I do have two other questions / suggestions:
(1) Semantic of unknown extension:
About "the unknown activity MUST be treated as if it were an empty
activity"...
Should the child content of [other] namespace within <extensibleActivity>
be governed by the same set of rules from Issue 92 and 92.*? That was how I
approach Issue 182.
One more alternative semantic: if an BPEL implementation does not recognize
the child content within extensibleActivity, the BPEL processor MUST ALWAYS
reject the BPEL source code.
(2) Syntax:
Instead of
------------------------
<extensibleActivity >
<???:??? standard-attributes>
standard-elements
</???:???>
</extensibleActivity>
------------------------
Yaron, have you considered syntax:
------------------------
<extensibleActivity standard-attributes>
standard-elements
<???:??? />
</extensibleActivity>
------------------------
?
It looks more like other activities syntax-wise. It allows us to reuse
"tActivity" definition for standard attributes and elements.
Note:
standard-attributes include anyAttributes from other NS.
Standard-elements includes <sources> and <targets>, but excluding any
element from other NS. (This is different from other activity.)
XSD Details:
---------------------------
<complexType name="tExtensibleActivityAbstractBase" abstract="true">
<complexContent>
<restriction base="bpws:tActivity">
<sequence>
<element ref="bpws:documentation" minOccurs="0"
maxOccurs="unbounded"/>
<any namespace="##other"
processContents="lax" minOccurs="0"
maxOccurs="0"/>
<element name="targets" type="bpws:tTargets"
minOccurs="0"/>
<element name="sources" type="bpws:tSources"
minOccurs="0"/>
</sequence>
</restriction>
</complexContent>
</complexType>
<complexType name="tExtensibleActivity">
<complexContent>
<extension base="bpws:tExtensibleActivityAbstractBase">
<sequence>
<any namespace="##other" processContents="lax" />
</sequence>
</extension>
</complexContent>
</complexType>
---------------------------
Note #2:
The extra complicated XSD design here (if we like the new syntax) and
slightly odd syntax details (of both Yaron's suggestion and my new syntax
suggestion) are caused partially by XSD limitation and partially by the
issue 111.1 decision in March F2F, which I still tend to think it may not
be the most optimal one ...
If we go for the original design of Issue 111.1, the syntax details here
would be just: (a) add an xsd:any to "activity" group and (b) declare that
xsd:any must be type of "tActivity". End of definition. Simple and
elegant.
E.g.: (I would call it [A])
<flow>
...
<sequence>
<invoke ... />
<assign ... />
<receive ... >
<sources> <source linkName="L1"> </sources>
</receive>
...
</sequence>
<sequence>
<invoke ... />
<foo:myActivity>
<targets> <target linkName="L2"> </targets>
</foo:myActivity>
...
</sequence>
</flow>
With current 111.1 decision, the same example would become:
either: (Yaron's original suggestion, I would call it [B1])
<sequence>
<invoke ... />
<extensibleActivity>
<foo:myActivity>
<targets> <target linkName="L2"> </targets>
</foo:myActivity>
</extensibleActivity>
...
</sequence>
or: (this newer suggestion, I would call it [B2])
<sequence>
<invoke ... />
<extensibleActivity>
<targets> <target linkName="L2"> </targets>
<foo:myActivity>
</extensibleActivity>
...
</sequence>
I don't have a superstrong preference between [B1] and [B2].
( But, I guess I still a stronger preference for [A] ... :-) )
Thanks!
Regards,
Alex Yiu
Frank Leymann wrote:
Yaron,
why "MAY have BPEL'S standard..." instead of "MUST"?
Do you have an example, where it doesn't make sense to have standard
attributes and elements for an activity?
Gruss / Regards
Frank Leymann
-----Ursprüngliche Nachricht-----
Von: Yaron Y. Goland [mailto:]
Gesendet: Freitag, 25. März 2005 22:36
An: wsbpeltc
Betreff: [wsbpel] Issue 111 - Proposal For Vote
111 - Extension Activities
Proposal: Add an extensibleActivity element to hold extension
activities
Introduce Section 11.9
New activities can be introduced for use in BPEL by placing them
inside
of the extensibleActivity element. The contents of an
extensibleActivity
element MUST be a single element that MAY have BPEL's
standard-attributes and standard-elements defined on it. If the
element
contained within the extensibleActivity element is not recognized
then
the unknown activity MUST be treated as if it were an empty activity.
In
all cases however any standard-attributes or standard-elements used
on
the contained activity MUST be treated as defined by this
specification.
<extensibleActivity >
<???? standard-attributes>
standard-elements
</????>
</extensibleActivity>
Schema:
Add to activity group:
<element name="extensibleActivity" type="bpws:textensibleActivity"/>
Add the following definition:
<complexType name="textensibleActivity">
<sequence>
<any processContents="lax"/>
</sequence>
</complexType>
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
