Re: AW: [wsbpel] Issue 111 - Proposal For Vote

[Alex Yiu <alex.yiu@oracle.com>]

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:ygoland@bea.com] 
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: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org




---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org