[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 92 - 92.1 - a newer and potentially unifying proposal
References: <OF1830994A.7D15ACF8-ON85256FBD.005F9D2B-85256FBD.00603657@us.ibm.com> <4230C1D7.2010603@bea.com>
In-Reply-To: <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"; />
</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";</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--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]