Hi Alex,
I am suggesting this as an alternate mechanism to use of
@SchemaLocation and @SchemaLanuguage.
Given both of the above @'s are optional once can chose not to specify
these and supply a RDDL doc at the location the namespace URI resolves
to.
In addition I think we should consider doing it for own own BPEL
namespace.
Regards, Prasad
Alex Yiu wrote:
Hi,
Interesting suggestion ...
Some clarification questions:
- Are you suggesting we must always use RDDL mechanism to resolve
resources? Or, you are suggesting RDDL as a supplementary mechanism in
addition to the simple Location URI mechanism?
- Do you want to apply RDDL to <bpel:import>? (A new issue?
or Issue 88?)
- Do we want to add RDDL as a normative reference to the BPEL
spec?
and which standard spec has added RDDL as a normative reference for its
resource look up so far?
My current gut feeling is: if we want to use RDDL, we should use it as
a supplementary way. If we want to use RDDL, we should use it
consistently in all "location-URI" related BPEL construct. (e.g.
bpel:import). And, I am worrying whether we run too ahead of other
related specs (e.g. WSDL and XSD) in terms of RDDL support.
Thanks.
Regards,
Alex Yiu
Prasad Yendluri wrote:
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 .
|