[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]