OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Making <assign> truely extensible (related to Issue 11)


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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]