[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 92 - Proposal for vote
Happy new year! :-)
If we go allowing extensions on <extensions> for (c), we will need to clarify that the ordering of <extensions> matters and make sure we don't run into other chicken-and-egg and catch-22 situations.
Looking forward to a more clarified proposal draft from you.
Dieter Koenig1 wrote:
Hi Alex, indeed, it was the intention to make declarations mandatory for all extensions (b). Your point (a) sounds absolutely reasonable to me, this should be kept consistent. I do not have a clear preference for (c); I could imagine additional extension-specific declarations within the <extension> element, however, I do not have a scenario at hand. Kind Regards DK Alex Yiu <alex.yiu@oracle. com> To Dieter Koenig1/Germany/IBM@IBMDE 23.12.2004 00:26 cc wsbpeltc <email@example.com>, Alex Yiu <firstname.lastname@example.org> Subject Re: [wsbpel] Issue - 92 - Proposal for vote Hi, DK I am agree with your proposal, generally speaking. There are few things/questions I would to mention/ask: (a) BPEL's current convention is using "yes" or "no" (bpws:tBoolean) instead of "true" or "false" (xsd:boolean). (b) Does this proposal mean ALL BPEL extension points (element/attribute) MUST be always declared with this syntax? Otherwise, the BPEL implementation should reject the process. I presume the answer is yes by reading the implication of the text. It would be nice to have explicit text on that. (c) I presume the <extension> related syntax does not have its own extension points. (e.g. location of extension definition). Again explicit text on this would be appreciated. Thanks! Regards, Alex Yiu Dieter Koenig1 wrote: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="true|false"/>+ </extensions> ... </process> Add text to section 6.3. Language Extensibility The "extensions" subelement of the process is used to declare all namespaces of BPEL extension attributes/elements and indicate whether they carry runtime semantics that must be understood by the BPEL runtime. 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. Kind Regards DK To unsubscribe from this mailing list (and be removed from the roster ofthe OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php .To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php .