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

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

You're right. The language is confusing. Better language would probably be:

It is not required to include an extension element declaring the use of 
an optional extension. Any unsupported optional attributes or elements 
will be safely ignored by BPEL processors using the rules in section 6.3.

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