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

[Yuzo Fujishima <fujishima@bc.jp.nec.com>]

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> <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--
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 
> 
>