Re: [wsbpel] Issue 92 - 92.1 - Do not associate XML namespaces withextension IDs - Proposal For Vote

[Francisco Curbera <curbera@us.ibm.com>]

Your example is precisely the kind that I think is out of scope of this
issue. The details of the engine behavior are not language extensions but
engine specific policies. These are two very different things and I don't
think we should be try to define a BPEL-specific policy mechanism.

Paco



                                                                                                                                  
                      "Yaron Y. Goland"                                                                                           
                      <ygoland@bea.com>        To:       Francisco Curbera/Watson/IBM@IBMUS                                       
                                               cc:       wsbpeltc <wsbpel@lists.oasis-open.org>                                   
                      03/07/2005 09:40         Subject:  Re: [wsbpel] Issue 92 - 92.1 - Do not associate XML namespaces with      
                      AM                        extension IDs - Proposal For Vote                                                 
                      Please respond to                                                                                           
                      ygoland                                                                                                     
                                                                                                                                  




This approach is appropriate for defining a XML document instance. But
we are defining a programming language that happens to use XML for its
persistence format. Therefore our extensions will not and in fact cannot
just be limited to extending the syntax of the language but also will
extend the semantics of the language, including aspects of the semantics
that are not even expressed in the syntax, such as changes or
modifications to runtime behavior.

For example, if someone decided to actually define how the elephant (the
notional BPEL message dispatcher we all work so hard not to talk about)
works they might include an extension in their BPEL declaring that their
BPEL program's logic depends on the person's interpretation of the
elephant's functionality. In that case they would place an extension
element in their BPEL process and nothing else, no elements, no
attributes, nothing beyond the extension declaration itself. Because the
thing their extension is changing is not the syntax of the BPEL process
but the expectations of the BPEL processor's behavior.

             Yaron

Francisco Curbera wrote:
> I think the really important point is whether the <bpel:extensions>
element
> should declare XML language extensions alone or also support something
> else. The intent has always been the former. So, call it "namespace" or
> "URI", the requirement is that it identifies an XML dialect being used in
> the definition of the process, and the way we identify XML dialects today
> is by providing the namespace of the schemas that define them. Anything
> else sounds like trying to expand the scope of issue 92.
>
> Paco
>
>
>
>

>
>
>                       "Yaron Y.
> Goland"

>
>
>                       <ygoland@bea.com>        To:       wsbpeltc
> <wsbpel@lists.oasis-open.org>
>
>
> cc:

>
>                       02/28/2005 09:45         Subject:  [wsbpel] Issue
92 -
> 92.1 - Do not associate XML namespaces with
>
>                       PM                        extension IDs - Proposal
For
> Vote
>
>                       Please respond
> to

>
>
>
> ygoland

>
>
>

>
>
>
>
>
> The current proposal uses an attribute called "namespace" to identify
> the name of an extension. This is an unfortunate choice as it implies
> that the URI used to identify the extension is also the namespace URI of
> the attributes and elements associated with that extension. As I explain
> in <http://www.goland.org/Tech/extensions.htm>
> associating the extension URI and namespace URIs is not a good idea. It
> provides very little added benefit since it can only catch a tiny
> handful of typos and it makes re-use painful.
>
> I therefore propose that we name the attribute that will identify the
> extension "extensionURI" (based on a suggestion from Alex Yiu). This
> would make the syntax for the extension element into:
>
> <process>
>      …
>         <extensions> ?
>            <extension extensionURI=”anyURI” mustUnderstand=”yes|no”/> *
>         </extensions>
>      …
> </process>
>
>                          Yaron
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>