Issue 92 - 92.4 - Add a new section, 13.7 to define extensions -Proposal For Vote

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

Introducing an extension mechanism brings up questions like:
  * What sort of things can be extended?
  * How are syntax and semantics associated with an extension?
  * What does it mean to support an extension?
  * Since optional extension are, well, optional, why allow them to be 
declared?
  * What happens if the same extension is declared twice?
  * What is the schema for the extension elements?

To answer these questions I propose that we add a new section to the 
BPEL specification, 13.7 Extension Declarations. 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 on run time behavior and so on. This specification does 
not attempt to define or constrain all the possible syntactic and 
semantic extensions one could make to BPEL.

BPEL provides the <extensions> element, which is available as a child of 
the process element, to declare the use of extensions. Each extension is 
identified by an extension URI. The BPEL specification provides no 
guidance as to how one associates syntax or semantics with an extension 
URI. Although it is encouraged to provide extension URIs which are 
resolvable and which provide information about the extension, this is 
not required.

 From the perspective of a BPEL processor the only action to take with 
an extension URI is to compare it to the list of extension URIs 
supported by the processor. If there is a match then whatever syntax and 
semantics are identified by the extension URI is supported.

For example, someone could decide to add several new activities to BPEL 
and perhaps put in new attributes specifying quality of service (QOS) 
behavior and provide a single extension URI which indicates support for 
all of the previous. Systems that do not support the extension URI will 
not necessarily understand what extensions were defined by the ID, only 
that whatever semantics/syntax the extension may specify, the processor 
doesn't support them. Systems that do support the extension URI are 
assumed through some undefined mechanism to be fully aware of the 
syntactical and semantic extensions associated with the extension URI 
and be able to support them.

<process>
    …
       <extensions> ?
          <extension extensionURI=”anyURI” mustUnderstand=”yes|no”/> *
       </extensions>
    …
</process>

Extension declarations which are marked mustUnderstand=”yes” are called 
mandatory extensions. A BPEL processor MUST support all mandatory 
extensions in a BPEL process definition or the processor MUST refuse to 
process the definition.

Extension declarations which are marked mustUnderstand=”no” are called 
optional extensions. It is not necessary to define an optional extension 
in order to use extension attributes or elements with optional semantics 
as section 6.3 specifies how to ignore unrecognized attributes or 
elements. The ability to declare an optional extension is primarily a 
convenience which makes it easier to provide information about the use 
of an optional extension in a well known location.

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=”tExtension” minOccurs=”1” 
maxOccurs=”unbounded”/>
          </sequence>
       </extension>
    </complexContent>
</complexType>

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

       Thanks,

                 Yaron