Re: [wsbpel] Issue 92 - 92.4 - Add a new section,13.7 to define extensions - Proposal For Vote

[Danny van der Rijn <dannyv@tibco.com>]

This confuses me:

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


Either my addled brain can't parse the sentence, or my semantic 
processor needs to be re-run with an ever larger stack.  What do you 
mean by this?  Is the key around what it means to "define" an extension?


Yaron Y. Goland wrote:

> 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>