+1
Step 1: declare which extensions are supported (optional or mandatory).
Step 2: use one of these extensions to specify additional semantics
(could be an empty element)
I fear that a shortcut that makes step 2 unnecessary might just end up
making things more complicated.
assaf
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"
> <> To: wsbpeltc <>
> 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:
>For additional commands, e-mail:
>
>
>
