[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 92 - 92.5 - Allow extensions to be declared under scope elements- Proposal For Vote
Proposal: Allow the extensions element to be used under scopes. Note however that the semantics of an extensions element are always global, that is, they always apply to the process as a whole, never to just a specific scope. Rationale: Allowing for extension elements under scopes makes it easy to create re-usable libraries and dynamically generated code (ala what the GRID folks are doing). For example, one can create libraries of scopes that can be cut and pasted into place without having to worry about fixing up extension declarations. Similarly if one is, for example, translating a model into BPEL and that model calls out to various libraries who generate actual BPEL code the libraries can easily declare what extensions they need within the scopes they generate. Note however that the semantics of the extensions declaration are always global. So if someone defines a mandatory extension five scopes deep the processor must understand that mandatory extension or reject the entire process. Also note that allowing extensions to be declared under scopes (with global semantics) has no performance penalty for the BPEL processor as BPEL’s static analysis requirements already require a processor to review the entire process before accepting it for execution. Summary of changes: Add language to 13.7 to make it legal to use the extensions element in scopes. Section 13.7 Remove the process element from around the extensions element sample schema. From: “…which is available as a child of the process element…” To: “…which is available as a child of both the process element and the scope element…” Add the following sentence to the end of the paragraph which starts “Extension declarations which are marked mustUnderstand=”yes”…”: The lexical scope of an extensions element is the entire process so even if an extensions element is declared on a scope nested many levels deep in a process, possibly in a scope that isn’t even in reachable code, the mustUnderstand semantics MUST still apply to the entire process. Add the following sentence to the end of the paragraph which starts “Extension declarations which are marked mustUnderstand=”no””: As with mandatory extensions the lexical scope of an optional extension declaration is the entire process. From: The same extension URI MAY be used multiple times in the extensions element. To: The same extension URI MAY be used multiple times in a single extensions element or across multiple extensions elements in the same process. From: The extension declarations in an extensions element MUST be treated as an unordered set. To: The total set of extensions declared throughout an entire process MUST be treated as a single unordered set. Schema: Add to the tScope declaration: <element name=”extensions” type=”bpws:tExtensions” minOccurs=”0”/> Thanks, Yaron
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]