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