The recent trend on this seems to be towards having the (extension)
namespace URI resolve to a (RDDL) document that embeds the URL for the
associated schema (if any) in addition to describing the extension
formally. WS-Addressing had recently done this for its own namespace
(see attached) and XML schema had also done this
http://www.w3.org/2001/XMLSchema.
I guess the proposal is to make the schemaLocation an optional @ but,
using the RDDL approach confines things to one URI and any changes are
reflected in the document that the URI resolves to rather than the BPEL
definition having to update multiple URIs associated with the extension
Regards, Prasad
Alex Yiu wrote:
Hi all,
Here is the proposal to vote for Issue 92.7. (attached HTML file).
Thanks!
Regards,
Alex Yiu
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 .
|