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

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 <>
    

    

      To: 
      Furniss, Peter <>, Diane
Jordan <>
    

    

      CC: 
      Alex Yiu <>, Danny van der Rijn
<>
    

  

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