← Prev in month ← Prev in thread
Next in thread → Next in month →

Issue - 11.1 - Proposal For Vote

From
Alex Yiu <>
Date
2005-01-14T19:30:31+00:00
ID
Thread
Issue - 11.1 - Proposal For Vote
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
← Prev in month ← Prev in thread
Next in thread → Next in month →