Issue - 11.1 - Proposal For Vote

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

Proposal:

In order to have the true spirit of extensibility of <assign> syntax, we would like to suggest the following syntax changes:

The <assign> construct contains one or more elementary data manipulation operations, which are <copy> or operations defined as extension under other namespaces.

<assign standard-attributes>
    standard-elements
    (
      <copy>
        from-spec
        to-spec
      </copy>   |
      any-element-of-other-namespace
    )+
</assign>

The <copy> operation copies a type-compatible value from the source ("from-spec") to the destination ("to-spec").

[Note: the above changes go into section 9.4, starting from second paragraph]

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 (tActivity). Also, due to similar restrictions from XSD, the constraint of at least one data manipulation operation cannot be enforced directly by the XSD itself. BPEL implementation needs to do its own validation post XSD validation, similar to the case of enforcing that only one of multiple optional attributes at <variable> declaration is used.]




Regards,
Alex Yiu