[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Fw: [wsbpel] Issue - 92 - Proposal for vote
|
Hi Dieter et. al, I have a couple of comments: 1. First a minor one: The "<extension namespace="anyURI" ..." schema permits literally any namespace. I think we need to make it clear that extensions must not be defined in the bpws reserved namespace (http://schemas.xmlsoap.org/ws/2004/03/business-process). 2. Making "all" extensions in a namespace required/optional as an "all or nothing" via @mustUnderstand at the namespace level is too restrictive and undesirable IMO. Even though I like declaring extensions (namespaces) at the top level. I think as a practical case, one would typically want to make "some" of extensions required and some of them optional. Requiring one to invent a new namespace for each extension is undesirable as well. Given BPEL has a open-content extensibility model (as defined by extending tExtensibleElements), IMHO we should try and preserve as much of that as possible. This problem exists in other description languages like WSDL, that define a wsdl:required attribute, that can be placed on a specific extension with a value of true or false. Having a wsdl:required with a value of "true" unambiguously identifies that the extension is required and MUST be understood. If the attribute value is "false" or not present then the extension is an optional one. I would like to propose that we explore a similar option via the "@bpel:rquired". Thanks. Prasad ------- Original Message --------
Updates:
(a) changed true|false to yes|no
(b) clarified that ALL extensions must be declared
Kind Regards
DK
---------------------------------
Proposed resolution for Issue 92:
A new subelement of the process root element is used to declare extensions
used in the process and specify whether they must be understood by the
BPEL runtime.
Rationale:
This declaration provides information needed by the process deployer in
order to decide whether a BPEL process containing language extensibility
elements can be executed by the runtime.
Add text to section 6.2. The Structure of a Business Process
<process ...>
...
<extensions>?
<extension namespace="anyURI" mustUnderstand="yes|no"/>+
</extensions>
...
</process>
Add text to section 6.3. Language Extensibility
The "extensions" subelement of the process is used to declare the
namespaces of ALL BPEL extension attributes/elements and indicate
whether they carry runtime semantics that must be understood by
the BPEL runtime. If this criteria is not met, then the BPEL
implementation MUST reject the process.
If the runtime does not support one or more of the extensions with
mustUnderstand="true", then the process MUST NOT be deployed.
Extensions declared with mustUnderstand="false" MAY be ignored by the
runtime.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]