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

["Yaron Y. Goland" <ygoland@bea.com>]

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
>