Hi all,
Some comments on Issue 92's current poposal:
- After more thinking, I would prefer we don't need to declare the
namespace as an extension, if that extension is optional to understand.
- We may want to consider adding an optional schemaLocation
attribute for people to denote where they can get the schema defintion
for those extension element.
- Again, I really still think declaration of extension should NOT
be extensible themselves. Otherwise, we need to define the ordering of
those extensions.
This is a very normative issue. One way or the other, it must be stated
very explicitly in the proposed resolution.
Please note that: there are more thoughts forming on Issue 92.
Let's discuss more on tomorrow conf call.
Thanks!
Regards,
Alex Yiu
Assaf Arkin wrote:
+1
Assaf
Dieter Koenig1 wrote:
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.
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.
|