Issue - 11 - proposal to vote - for new subissue [11.1] - making<assign> truely extensible

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

Hi, all,

Peter is still out this week. As per suggestions from Diane and Tony, I am sending this email to the public TC list under the issue 11 tag.

Please note that :

• this email contains a new sub-issue 11.1 description
  
• this email contains a formal proposal to vote for this sub-issue 11.1.
• After we vote on this sub-issue 11.1, the rest of issue 11 will still remain open.

Thanks!


Regards,
Alex Yiu



-------- Original Message --------

Subject:	new issue - sub-issue 11.1 - making truely extensible
Date:	Tue, 21 Dec 2004 16:10:41 -0800
From:	Alex Yiu <alex.yiu@oracle.com>
To:	Furniss, Peter <Peter.Furniss@choreology.com>, Diane Jordan <drj@us.ibm.com>
CC:	Alex Yiu <alex.yiu@oracle.com>, Danny van der Rijn <dannyv@tibco.com>

Hi, Peter,

After have a discussion and straw-poll in F2F, I believe that the timing is now appropriate for me to formally to open a new issue (sub issue) 11.1 to make <assign> truely extensible.

====================================
Background:

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>

Proposed Solution:

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.]
====================================


Have a nice holiday in south africa. :-)



Regards,
Alex Yiu