Issue 92 - 92.5 - Allow extensions to be declared under scope elements- Proposal For Vote

["Yaron Y. Goland" <ygoland@bea.com>]

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