Re: [wsbpel] Issue 92 - 92.1 - a newer and potentially unifying proposal

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

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>      &lt;extensions&gt;?
         &lt;extension namespace="anyURI" 
                    extensionURI="anyURI"? 
                    mustUnderstand="yes|no" /&gt;+
      &lt;/extensions&gt;</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>      &lt;extensions&gt;
         &lt;extension namespace=<a class="moz-txt-link-rfc2396E" href="http://foo.com";>"http://foo.com";</a> /&gt; 
      &lt;/extensions&gt;</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: &lt;xsd:import namespace="anyURI" schemaLocation="anyURI"?
/&gt; <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--