Issue - 92.7 - proposal to vote

[Alex Yiu <alex.yiu@oracle.com>]

Hi all,

Here is the proposal to vote for Issue 92.7. (attached HTML file).
Thanks!

Regards,
Alex Yiu

Title: Issue 92.7 - Proposal

Proposal for Issue 92.7

Last modified: Jun 27, 2005 - 7 pm PDT

Summary:
Adding optional schemaLocation and schemaLanguage attribues to
<extension> and an optional schemaLanguage attribute to
<extensions>

-------------------------
<extensions schemaLanguage="URI"?>
    <extension namespace="URI" mustUnderstand="yes|no" 
               schemaLocation="URI"? schemaLanguage="URI"? />* 
</extensions> 
-------------------------

Rationale:
To enable a portable syntax validation mechanism for extensions used in
WS-BPEL. Particularly, enabling de-coupling and interoperability
between BPEL designer tools and BPEL engine in the context of BPEL
extensions. 

Details:

The optional "schemaLocation" refers to the location of a schema for
XML which provides extra syntax validation information for extension
element and attributes used in WS-BPEL. The usage of the
"schemaLocation" is optional. That means, when the attribute can be omitted, WS-BPEL processor will NOT do any syntax
validation, if it does not understand that namespace (i.e. not a well-known namespace to a particular implementation). 

If the extension attributes and elements are invalid according to the
schema specified by the "schemaLocation", the WS-BPEL processor MUST
detect this condition during static analysis and reject the process
defintion. 

WS-BPEL specification does not mandate a particular schema language for
XML to be used for extension syntax validation. The choices of schema
languages include and are not limited to: W3C XML Schema
(http://www.w3.org/2001/XMLSchema). The schema language used by a
particular extension is indicated by the "schemaLanguage" attribute of
the corresponding <extension> element. For a particular <extension> declaration, if the WS-BPEL
processor does not understand a particular schemaLanguage and
mustUnderstand is set to no, the processor does not need to perform
syntax validation. On the other hand, if mustUnderstand of the
<extension> element is set to yes under the same unsupported
schemaLanguage situation, the processor MUST reject the process
definition during static analysis.

If the "schemaLanguage"
attribute at <extension> element is omitted, the default value
will come from the "schemaLanguage" attribute of the parent
<extensions> element. 

There is no default value for "schemaLanguage" attribute at <extensions>. 


Syntax summary:
-------------------------

<extensions schemaLanguage="URI"?>

    <extension namespace="URI" mustUnderstand="yes|no" 

               schemaLocation="URI"? schemaLanguage="URI"? />* 

</extensions> 

-------------------------

For example:
--------------------------
<extensions schemaLanguage="http://www.w3.org/2001/XMLSchema">
    <extension namespace="http://foo.com" mustUnderstand="yes" 
            schemaLocation="http://foo.com/wsbpel/extension.xsd" />
    <extension namespec="http://bar.com" mustUnderstand="no" /> 
    <extension namespec="http://bar2.com" mustUnderstand="yes" />
    <extension namespec="http://some.org" mustUnderstand="no" 
          schemaLocation="http://some.org/wsbpel/extension.rng"
          schemaLanguage="http://relaxng.org/ns/structure/1.0" />
</extensions> 
--------------------------

The extensions under namespace of "http://foo.com" and
"http://some.org" are validated with schemas from
"http://foo.com/wsbpel/extension.xsd" (in W3C XML Schema) and
"http://some.org/wsbpel/extension.rng" (in Relax NG) respectively .