OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]