Issue - 92.4 - Proposal For Vote

["Yaron Y. Goland" <ygoland@bea.com>]

Issue 92.4 -

I propose that we move the text that issue 92 added to section 6.2 and 
instead add it as specified below to a new section to the BPEL 
specification, 13.7 Extension Declarations. Note that I did make one 
normative change to 92, I changed the "+" to "*" for the extension 
element. The purpose of this change is to allow people to use the 
extensions (notice the plural) element with new extension elements. I 
propose that the text of the section be:

The BPEL process definition is designed to be extensible. Extensions to
BPEL could include anything ranging from new attributes to new elements 
to restrictions or extensions of run time behavior and so on.

    <process ...>
       ...
       <extensions>?
          <extension namespace="anyURI" mustUnderstand="true|false"/>*
       </extensions>
       ...
    </process>

The "extensions" child element of the process element is used to declare 
namespaces of BPEL extension attributes/elements and indicate whether 
they carry semantics that must be understood by a BPEL implementation.

If the implementation does not support one or more of the extensions 
with mustUnderstand="yes", then the process MUST be rejected.

Optional extensions are extensions which the BPEL process MAY ignore. 
Optional extension MAY be declared using the extensions element with 
mustUnderstand="no" but there is no requirement to do so. The purpose of 
allowing optional extensions to be declared using the extensions element 
is to provide a well defined location where additional information about 
the optional extension can be found.

The <extension> declaration element under <extensions> is itself extensible.

The same extension URI MAY be declared multiple times in the extensions 
element. If an extension URI is identified as mandatory in one extension 
element and optional in another then the mandatory semantics have 
precedence and MUST be enforced. The extension declarations in an 
extensions element MUST be treated as an unordered set. That is, BPEL 
does not provide any way to establish precedence between extension 
declarations based on ordering.

------------------------------------

I also propose the following changes to schema:

Schema:
Add to the tProcess declaration:
<element name="extensions" type="bpws:tExtensions" minOccurs="0"/>

Add new declaration:
     <complexType name="tExtensions">
         <complexContent>
             <extension base="bpws:tExtensibleElements">
                 <sequence>
                     <element name="extension" type="bpws:tExtension" 
minOccurs="0" maxOccurs="unbounded"/>
                 </sequence>
             </extension>
         </complexContent>
     </complexType>


     <complexType name="tExtension">
         <complexContent>
             <extension base="bpws:tExtensibleElements">
                 <attribute name="namespace" type="anyURI"/>
                 <attribute name="mustUnderstand" type="bpws:tBoolean"/>
             </extension>
         </complexContent>
     </complexType>