Hi, Yuzo,
Yuzo wrote: on whether the same NS can be defined by multiple
extensionURI:
Disallowing is OK for me, but we may be able to allow it.
Case A: The engine supports the http://bar3impl.com but not
http://bar2impl.com
In this case, the engine should know specific elements/attributes in the
http://bar.com namespace that are relevant to extension
http://bar3impl.com. All other elements/attributes in the namespace
should be for http://bar2imp.com and ignorable.
Case B: The engine supports neither.
In this case, the engine may erroneously reject a process definition
that contains elements/attributes for http://bar2impl.com only and does
not contain those for http://bar3imp.com because the engine cannot
distinguish elements/attributes for bar2impl from those for bar3impl.
But I don't think this error severe. Just removing the extension
declaration for bar3impl should do.
Could you elaborate on what you are worrying about?
The main thing that I worry about is: multiple extension URIs define
overlapping and conflicting extension.
E.g. one extension URI may define "foo:bar" under "sequence" is an
integer value, while the extension URI define "foo:bar" under
"sequence" as a QName value.
I have seen enough similar troubles in the XML data world, when merging
multiple sources of XML data definition together. I don't want to see
the same headache in BPEL extension source world. :-)
Regarding to your other questions, hopefully my second email on this
thread (addressing some questions / concerns of Yaron and Paco) would
give you a good enough answer. [ Especially, from the part of I
expressed a sample BPEL source code using the pure "Yaron's" approach,
which should be very similar to your approach. ]
Thanks!
Regards,
Alex Yiu
Yuzo Fujishima wrote:
Alex,
Thank you for the response. Please see my comments in-line.
Alex Yiu wrote:
Yuzo,
Thanks for your very constructive reply.
Regarding to your point (1):
The reason that I am making namespace mandatory while extensionURI
optional is: to retain an original feature in Dieter's proposal - i.e.:
we can decide whether an extension construct is "mustUnderstand" by just
looking up its namespace URI. This is a good and important feature to
maintain. E.g.:
<scope>
<foo:ExtElem />
<bar:ExtElem />
...
</scope>
BPEL tool can know that <foo:ExtElem /> is a "mustUnderstand", while
<bar:ExtElem /> is NOT.
To further illustrate my example:
<process>
<extensions>
<extension namespace="http://bar.com" <http://bar.com>
extensionURI="http://bar2impl.com" <http://bar2impl.com>
mustUnderstand="no" />
</extensions>
<scope>
<bar:ExtElem />
...
</scope>
</process>
The above process definition can be processed by a BPEL engine which
does not understand "http://bar.com" <http://bar.com> and safely
disregard the existence of <bar:ExtElem /> regardless of extensionURI
value used in the declaration.
Let me paraphrase myself. I think it is important to enable us to find
*THE* "owner" of extension definition by looking up namespace. Using the
same example:
<bar:ExtElem />
==> Namespace is: "http://bar.com" <http://bar.com>
==> Definition Owner is: "http://bar2impl.com" <http://bar2impl.com>
The namespace attribute is truly useful only when the extension need not
be understood. In other words, all that an engine needs is the following
rule: "An extension element that belongs neither of the namespaces of
the optional extensions must be understood."
In my approach, the namespace attribute must be specified only when the
extension is optional (need-not-be-understood) and the namespace is
different from the extension URI. (If the namespace is not explicitly
specified for an optional extension, the value of the extension URI is
used instead.)
IMHO, the following usage (one namespace defined by multiple extension
URI) should be disallowed. Otherwise, it will open a BIG can of worms:
<extensions>
<extension namespace="http://bar.com" <http://bar.com>
extensionURI="http://bar2impl.com" <http://bar2impl.com>
mustUnderstand="no" />
<extension namespace="http://bar.com" <http://bar.com>
extensionURI="http://bar3impl.com" <http://bar3impl.com>
mustUnderstand="yes" />
</extensions>
Disallowing is OK for me, but we may be able to allow it.
Case A: The engine supports the http://bar3impl.com but not
http://bar2impl.com
In this case, the engine should know specific elements/attributes in the
http://bar.com namespace that are relevant to extension
http://bar3impl.com. All other elements/attributes in the namespace
should be for http://bar2imp.com and ignorable.
Case B: The engine supports neither.
In this case, the engine may erroneously reject a process definition
that contains elements/attributes for http://bar2impl.com only and does
not contain those for http://bar3imp.com because the engine cannot
distinguish elements/attributes for bar2impl from those for bar3impl.
But I don't think this error severe. Just removing the extension
declaration for bar3impl should do.
Could you elaborate on what you are worrying about?
Regarding to your point (2):
Whether it is a justified design to all an extensionURI to point to 2 or
more namespaces are something that we need to think about.
I agree.
Unfortunately, it's kind of outside the scope of this TC to dictate the
details of interpretation of extensionURI. So, in short, we should still
allow that happen.
When this happens, I would say I prefer syntax listed in (B). I
understand it can be a bit verbose. However, it allows me to achieve two
things:
(I) Consider this example:
<extensions>
<extension extensionURI="theExtension" namespace="namespaceOne"
mustUnderstand="yes"/>
<extension extensionURI="theExtension" namespace="namespaceTwo"
mustUnderstand="*no*"/>
</extensions>
The "yes" and "no" contrary above is intentional. It is definitely
conceivable that one extensionURI defines extensions of multiple NS,
where some of them are "mustUnderstand" and some of them are NOT.
IMHO, if an extension allows "partial support", it is the extension,
not the namespace(s), that is to be split, primarily.
Suppose extension A allows partial support. Then A should be split into
A1, A2, ... and so on. The namespaces may also be split, but the
namespace splitting is secondary to that of the extension.
(II) Again, being able to lookup the "owner" of extension construct by
looking up namespace URI is a very important feature.
All in all, it really depends on whether you look at the problem from a
syntax-oriented viewpoint or from a semantic-oriented viewpoint.
Unfortunately, for the latter case, interpretation of extensionURI is
out of this TC scope. Otherwise, I would lean towards to your approach.
Another important clarification to add:
Advanced cases of mixed namespace managment within ONE extension point.
Consider this example:
<process>
<extensions>
<extension namespace="http://foo.com" <http://foo.com>
extensionURI="http://foo2impl.com" <http://foo2impl.com>
mustUnderstand="yes" />
<extension namespace="http://bar.com" <http://bar.com>
extensionURI="http://bar2impl.com" <http://bar2impl.com>
mustUnderstand="yes" />
</extensions>
<scope>
<foo:ExtElem1> <bar:ExtElem2 /> </foo:ExtElem1>
<bar:ExtElem3 />
...
</scope>
</process>
We should EITHER saying the above usage is illegal?
OR: it works with the following example semantics?
The semantics of "<foo:ExtElem1> <bar:ExtElem2 /> </foo:ExtElem1>"
should be under the domain of "http://foo2impl.com" <http://foo2impl.com>.
The semantics of "<bar:ExtElem3 />" should be under the domain of
"http://bar2impl.com" <http://bar2impl.com>.
I think we should consider
<foo:ExtElem1> <bar:ExtElem2 /> </foo:ExtElem1>
as being belonging to extension http://foo2impl.com.
Generally speaking, inside an extension element, there can appear
a lot of elements/attributes that does not belong to the same namespace
as the extension element.
Yuzo Fujishima
NEC Corporation
Again, this illustrates another aspect of the design of looking up the
"OWNER" of extension by just doing namespace and XML information items
analysis.
If the TC feels comfortable with viewpionts expressed above, I would
consolidate these clarification to my "newer" proposal. (Sorry rushing
out my previous email out.)
Thanks!
Regards,
Alex Yiu
Yuzo Fujishima wrote:
Hi,
I would like to make two points.
Point 1: Make extenstionURI mandatory rather than namespace
An extension defines the namespace(s) it uses, not vice versa. In other
words, if an engine knows an extension, it should know the namespace(s)
used. Specifying namespace(s) in addition to the extension URI is
redundant per se.
Therefore, for me, it makes more sense to make
namespace attribute optional
and
extensionURI attribute mandatory.
Point 2: More than one namespace for an extension
In my opinion, using more than one namespace for an extension should be
rare. But I may be wrong, as at least Yaron seems to have a use case.
If we are to allow using more than one namespace for an extension,
extension declaration should look like:
(A1)
<extensions>
<extension extensionURI="theExtension" mustUnderstand="yes">
<namespace>namespaceOne</namespace>
<namespace>namespaceTwo</namespace>
</extension>
</extensions>
or:
(A2)
<extensions>
<extension extensionURI="theExtension" mustUnderstand="yes"
namespaces="namespaceOne namespaceTwo"/>
</extensions>
rather than:
(B)
<extensions>
<extension extensionURI="theExtension" namespace="namespaceOne"
mustUnderstand="yes"/>
<extension extensionURI="theExtension" namespace="namespaceTwo"
mustUnderstand="yes"/>
</extensions>
B is more redundant and error-prone; what should happen if
mustUnderstand is yes for one and no for the other?
Yuzo Fujishima
NEC Corporation
Alex Yiu wrote:
References: OF1830994A.7D15ACF8-ON85256FBD.005F9D2B-85256FBD.00603657@us.ibm.com"><OF1830994A.7D15ACF8-ON85256FBD.005F9D2B-85256FBD.00603657@us.ibm.com> OF1830994A.7D15ACF8-ON85256FBD.005F9D2B-85256FBD.00603657@us.ibm.com"><mailto:OF1830994A.7D15ACF8-ON85256FBD.005F9D2B-85256FBD.00603657@us.ibm.com> 4230C1D7.2010603@bea.com"><4230C1D7.2010603@bea.com> 4230C1D7.2010603@bea.com"><mailto:4230C1D7.2010603@bea.com>
In-Reply-To: 4230C1D7.2010603@bea.com"><4230C1D7.2010603@bea.com> 4230C1D7.2010603@bea.com"><mailto:4230C1D7.2010603@bea.com>
Content-Type: multipart/alternative;
boundary="------------050006030409020902060909"
This is a multi-part message in MIME format.
--------------050006030409020902060909
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi, all,
As discussed in the F2F, here is the written up details of a potentially
unifying proposal for Issue 92.1. Hopefully, it would address the need
>from both sides while retaining simplicity.
Thanks!
Regards,
Alex Yiu
===========================================
Issue 92.1 - Alternative Proposal to deal with namespace URI and
extension URI
<extensions>?
<extension namespace="anyURI"
extensionURI="anyURI"?
mustUnderstand="yes|no" />+
</extensions>
The "namespace" declares which namespace-URI extension elements and
attributes are being used under. It mainly governs the syntactic part of
the extension. It also provides information whether a BPEL processor
MUST understand extension constructs under a particular namespace.
The optional "extensionURI" is used to point to the semantical
definition of extension used under the declared namespace. The
semantical definition MAY include extra information for BPEL tools /
processors to validate extension construct usage. However, the
interpretation of the extensionURI is out of the scope of this
specification.
When the optional "extensionURI" attribute is missing:
<extensions>
<extension namespace="http://foo.com" <http://foo.com> />
</extensions>
the "namespace" URI will be re-used as the default extension URI. That
means the namespace URI is a well-known URI. And, the semantics of
extension is specified by the owner of that particular namespace.
Having two URIs (one for syntactic and one for semantic) separated but
still paired up allows us to:
* decouple the syntax and semantics of extension
* reuse the same extension syntax (identified by the namespace URI)
but with different implementations (identified by the extensionURI)
If we have just extensionURI without the namespace URI, BPEL authors and
tools would not know which extension syntax are governed which
extensionURI, especially when multiple extensions are used within the
same process definition. It would make the process definition much
harder to comprehend. Also, declaring an extension with a namespace URI
allows BPEL processors and tools identifies which extension constructs
can be safely ignored by just cross checking namespaces and their
corresponding "mustUnderstand" attribute. BPEL processors do NOT need to
understand the definition pointed by extensionURI, which is a
out-of-scope mechanism.
Please note that similar patterns have been used in other XML-syntax
based language before. E.g.:
* XSD: <xsd:import namespace="anyURI" schemaLocation="anyURI"? />
* JSP tag library extension: taglib-uri and taglib-location
* BPEL: Say, same XQueryX expression (of same namespace URI) coupled
with different XQuery execution context and data bindings pointed
by different expressionLanguage URIs.
===========================================
--------------050006030409020902060909
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Hi, all, <br>
<br>
As discussed in the F2F, here is the written up details of a
potentially unifying proposal for Issue 92.1. Hopefully, it would
address the need
>from both sides while retaining simplicity.<br>
<br>
<br>
Thanks!<br>
<br>
Regards,<br>
Alex Yiu<br>
<br>
<br>
<br>
===========================================<br>
<br>
<span style="text-decoration: underline;">Issue 92.1 - Alternative
Proposal to deal with namespace URI and extension URI</span><br>
<br>
<pre> <extensions>?
<extension namespace="anyURI"
extensionURI="anyURI"?
mustUnderstand="yes|no" />+
</extensions></pre>
<br>
The "namespace" declares which namespace-URI extension elements and
attributes are being used under. It mainly governs the syntactic part
of the extension. It also provides information whether a BPEL processor
MUST understand extension constructs under a particular namespace. <br>
<br>
The optional "extensionURI" is used to point to the semantical
definition of extension used under the declared namespace. The
semantical definition MAY include extra information for BPEL tools /
processors to validate extension construct usage. However, the
interpretation of the extensionURI is out of the scope of this
specification. <br>
<br>
When the optional "extensionURI" attribute is missing: <br>
<pre> <extensions>
<extension namespace=<a class="moz-txt-link-rfc2396E" href=""http://foo.com" <http://foo.com>>"http://foo.com" <http://foo.com></a> />
</extensions></pre>
the "namespace" URI will be re-used as the default extension URI. That
means the namespace URI is a well-known URI. And, the semantics of
extension is specified by the owner of that particular namespace. <br>
<br>
Having two URIs (one for syntactic and one for semantic) separated but
still paired up allows us to:<br>
<ul>
<li>decouple the syntax and semantics of extension</li>
<li>reuse the same extension syntax (identified by the namespace URI)
but with different implementations (identified by the extensionURI) <br>
</li>
</ul>
<br>
If we have just extensionURI without the namespace URI, BPEL authors
and tools would not know which extension syntax are governed which
extensionURI, especially when multiple extensions are used within the
same process definition. It would make the process definition much
harder to comprehend. Also, declaring an extension with a namespace URI
allows BPEL processors and tools identifies which extension constructs
can be safely ignored by just cross checking namespaces and their
corresponding "mustUnderstand" attribute. BPEL processors do NOT need
to understand the definition pointed by extensionURI, which is a
out-of-scope mechanism. <br>
<br>
Please note that similar patterns have been used in other XML-syntax
based language before. E.g.:<br>
<ul>
<li>XSD: <xsd:import namespace="anyURI" schemaLocation="anyURI"?
/> <br>
</li>
<li>JSP tag library extension: taglib-uri and taglib-location <br>
</li>
<li>BPEL:
Say, same XQueryX expression (of same namespace URI) coupled with
different XQuery execution context and data bindings pointed by
different expressionLanguage URIs. <br>
</li>
</ul>
<br>
===========================================<br>
</body>
</html>
--------------050006030409020902060909--
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org <mailto:wsbpel-unsubscribe@lists.oasis-open.org>
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org <mailto:wsbpel-help@lists.oasis-open.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org <mailto:wsbpel-unsubscribe@lists.oasis-open.org>
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org <mailto:wsbpel-help@lists.oasis-open.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
|