OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue 92 - 92.1 - a newer and potentially unifyingproposal


I didn't say that they don't matter to you.  Just that IF you argued 
that, I would disagree. 

The namespace provides help in that it can be used to track down 
acceptible syntax, generate picklists, etc.  If I (as an editor) know 
that the name of a partnerlink goes into extension element X's attribute 
Y, then I can help the user with valid values.  Similarly, for a 
validator.  This is common practice today.  The proposed method would 
require an editor to understand the BPEL way of extending things, and 
look up the extenion URI somewhere to find the defined schema.  Where to 
look it up is not defined now.

Danny

Yaron Y. Goland wrote:

> I can't imagine why you would argue that editors and such don't matter 
> to me since I have repeatedly argued that they are critical to BPEL. 
> However I still don't see how your point applies.
>
> Can you please provide an example where namespace provides any real 
> help to someone trying to use a generic BPEL editor with a BPEL 
> instance that has custom extensions? I.e. show an example of some 
> critical feature that works if we use the namespace attribute but 
> fails if we don't? Can you also please define the semantics of a 
> 'mustUnderstand' extension in that scenario?
>
>     Thanks,
>
>         Yaron
>
> Danny van der Rijn wrote:
>
>> Unfortunately, you missed some interesting discussion on this about 30
>> seconds after the F2F officially adjourned.
>>
>> My problem with your proposal is that it completely cuts any loosely
>> integrated tools, such as editors, syntax validators, etc., out of the
>> picture.  You may argue that they don't matter, but that's where we
>> would disagree.
>>
>> Danny
>>
>> Yaron Y. Goland wrote:
>>
>>  > Dieter and Alex's proposals both attempt to specify the syntax of
>>  > extensions. But that is error prone (as I explain in my blog article)
>>  > and completely unnecessary.
>>  >
>>  > All that is necessary is a simple list of what extensions are
>>  > supported where extensions are opaque IDs.
>>  >
>>  > When an engine runs a BPEL it looks at the extension IDs and sees
>>  > which ones are marked mandatory. If one is marked mandatory that the
>>  > engine doesn't support then the BPEL fails.
>>  >
>>  > Assuming all mandatory extensions are supported then when the BPEL
>>  > processes the BPEL file it simply ignores any elements or attributes
>>  > it doesn't recognize. There is therefore no need to explicitly 
>> specify
>>  > anything about syntax since the BPEL processor doesn't care. The only
>>  > thing the BPEL processor cares about are the elements and attributes
>>  > it DOES support and it already knows what those are.
>>  >
>>  > Generally speaking simpler is better and there is nothing simpler 
>> then
>>  > just specifying an opaque ID.
>>  >
>>  >         Yaron
>>  >
>>  > Francisco Curbera wrote:
>>  >
>>  >> My short summary of this discussion is this:
>>  >>
>>  >> 1. There is a very clear case for allowing an engine to decide if an
>>  >> extension is required by looking at... the extension element itself!
>>  >> Not a
>>  >> bad idea that Alex explains quite clearly. This is what Dieter's
>>  >> proposal
>>  >> allows.
>>  >>
>>  >> 2. There are ways in which we can add into BPEL explicit support for
>>  >> overloading the semantics of extension elements. This may or may not
>>  >> be a
>>  >> good idea, but the answer to that question clearly reaches far 
>> beyond
>>  >> BPEL.
>>  >> That notion is at the same time powerful and tricky, as the 
>> discussion
>>  >> between Alex and Yuzo shows.
>>  >>
>>  >> Somehow #2 sounds to me like a clear case of over-engineering; I 
>> don't
>>  >> think we should go there unless a very compelling use case (not an
>>  >> abstract
>>  >> example) is provided to justify it.
>>  >>
>>  >> Paco
>>  >>
>>  >>
>>  >>
>>  >>                                                                                                                                         
>>
>>
>>  >>
>>  >>
>>  >>                       Yuzo
>>  >> 
>> Fujishima                                                                                                    
>>
>>  >>
>>  >>
>>  >>                       <fujishima@bc.jp.        To:       wsbpeltc
>>  >> 
>> <wsbpel@lists.oasis-open.org>                                      
>>  >>                       nec.com>                 >> 
>> cc:                                                                                      
>>
>>  >>
>>  >>
>>  >>                                                Subject:  Re: 
>> [wsbpel]
>>  >> Issue 92 - 92.1 - a newer and potentially unifying proposal    
>>  >>                       03/18/2005
>>  >> 
>> 12:47                                                                                                  
>>
>>  >>
>>  >>
>>  >>                       >> 
>> AM                                                                                                                
>>
>>  >>
>>  >>
>>  >>                                                                                                                                         
>>
>>
>>  >>
>>  >>
>>  >>
>>  >>
>>  >>
>>  >> Alex,
>>  >>
>>  >> Thank you for the response. Please see my comments in-line.
>>  >>
>>  >> Alex Yiu wrote:
>>  >>  >
>>  >>  > Yuzo,
>>  >>  >
>>  >>  > Thanks for your very constructive reply.
>>  >>  >
>>  >>  > Regarding to your point (1):
>>  >>  >
>>  >>  > The reason that I am making namespace mandatory while 
>> extensionURI
>>  >>  > optional is: to retain an original feature in Dieter's proposal -
>>  >> i.e.:
>>  >>  > we can decide whether an extension construct is "mustUnderstand"
>>  >> by just
>>  >>  > looking up its namespace URI.  This is a good and important
>>  >> feature to
>>  >>  > maintain. E.g.:
>>  >>  >
>>  >>  > <scope>
>>  >>  >    <foo:ExtElem />
>>  >>  >    <bar:ExtElem />
>>  >>  >    ...
>>  >>  > </scope>
>>  >>  >
>>  >>  > BPEL tool can know that <foo:ExtElem /> is a "mustUnderstand", 
>> while
>>  >>  > <bar:ExtElem /> is NOT.
>>  >>  >
>>  >>  > To further illustrate my example:
>>  >>  >
>>  >>  > <process>
>>  >>  >    <extensions>
>>  >>  >       <extension namespace="http://bar.com"; <http://bar.com>
>>  >>  > extensionURI="http://bar2impl.com"; <http://bar2impl.com>
>>  >>  >             mustUnderstand="no" />
>>  >>  >    </extensions>
>>  >>  >    <scope>
>>  >>  >         <bar:ExtElem />
>>  >>  >         ...
>>  >>  >    </scope>
>>  >>  > </process>
>>  >>  >
>>  >>  > The above process definition can be processed by a BPEL engine 
>> which
>>  >>  > does not understand "http://bar.com"; <http://bar.com> and safely
>>  >>  > disregard the existence of <bar:ExtElem /> regardless of 
>> extensionURI
>>  >>  > value used in the declaration.
>>  >>  >
>>  >>  > Let me paraphrase myself. I think it is important to enable us to
>>  >> find
>>  >>  > *THE* "owner" of extension definition by looking up namespace.
>>  >> Using the
>>  >>  > same example:
>>  >>  >
>>  >>  > <bar:ExtElem />
>>  >>  >   ==> Namespace is: "http://bar.com"; <http://bar.com>
>>  >>  >   ==> Definition Owner is:  "http://bar2impl.com";
>>  >> <http://bar2impl.com>
>>  >>  >
>>  >>  >
>>  >>
>>  >> The namespace attribute is truly useful only when the extension 
>> need not
>>  >> be understood. In other words, all that an engine needs is the 
>> following
>>  >> rule: "An extension element that belongs neither of the 
>> namespaces of
>>  >> the optional extensions must be understood."
>>  >>
>>  >> In my approach, the namespace attribute must be specified only 
>> when the
>>  >> extension is optional (need-not-be-understood) and the namespace is
>>  >> different from the extension URI. (If the namespace is not 
>> explicitly
>>  >> specified for an optional extension, the value of the extension 
>> URI is
>>  >> used instead.)
>>  >>
>>  >>  > IMHO, the following usage (one namespace defined by multiple
>>  >> extension
>>  >>  > URI) should be disallowed. Otherwise, it will open a BIG can of
>>  >> worms:
>>  >>  >
>>  >>  >    <extensions>
>>  >>  >       <extension namespace="http://bar.com"; <http://bar.com>
>>  >>  > extensionURI="http://bar2impl.com"; <http://bar2impl.com>
>>  >>  > mustUnderstand="no" />
>>  >>  >       <extension namespace="http://bar.com"; <http://bar.com>
>>  >>  > extensionURI="http://bar3impl.com"; <http://bar3impl.com>
>>  >>  > mustUnderstand="yes" />
>>  >>  >    </extensions>
>>  >>
>>  >> Disallowing is OK for me, but we may be able to allow it.
>>  >>
>>  >> Case A: The engine supports the http://bar3impl.com but not
>>  >> http://bar2impl.com
>>  >>
>>  >> In this case, the engine should know specific elements/attributes 
>> in the
>>  >> http://bar.com namespace that are relevant to extension
>>  >> http://bar3impl.com. All other elements/attributes in the namespace
>>  >> should be for http://bar2imp.com and ignorable.
>>  >>
>>  >> Case B: The engine supports neither.
>>  >>
>>  >> In this case, the engine may erroneously reject a process definition
>>  >> that contains elements/attributes for http://bar2impl.com only 
>> and does
>>  >> not contain those for http://bar3imp.com because the engine cannot
>>  >> distinguish elements/attributes for bar2impl from those for 
>> bar3impl.
>>  >>
>>  >> But I don't think this error severe. Just removing the extension
>>  >> declaration for bar3impl should do.
>>  >>
>>  >> Could you elaborate on what you are worrying about?
>>  >>
>>  >>  >
>>  >>  >
>>  >>  > Regarding to your point (2):
>>  >>  >
>>  >>  > Whether it is a justified design to all an extensionURI to point
>>  >> to 2 or
>>  >>  > more namespaces are something that we need to think about.
>>  >>
>>  >> I agree.
>>  >>
>>  >>  > Unfortunately, it's kind of outside the scope of this TC to
>>  >> dictate the
>>  >>  > details of interpretation of extensionURI. So, in short, we 
>> should
>>  >> still
>>  >>  > allow that happen.
>>  >>  >
>>  >>  > When this happens, I would say I prefer syntax listed in (B). I
>>  >>  > understand it can be a bit verbose. However, it allows me to
>>  >> achieve two
>>  >>  > things:
>>  >>  >
>>  >>  > (I) Consider this example:
>>  >>  >
>>  >>  > <extensions>
>>  >>  >   <extension extensionURI="theExtension" namespace="namespaceOne"
>>  >>  >               mustUnderstand="yes"/>
>>  >>  >   <extension extensionURI="theExtension" namespace="namespaceTwo"
>>  >>  >               mustUnderstand="*no*"/>
>>  >>  > </extensions>
>>  >>  >
>>  >>  >
>>  >>  > The "yes" and "no" contrary above is intentional. It is 
>> definitely
>>  >>  > conceivable that one extensionURI defines extensions of 
>> multiple NS,
>>  >>  > where some of them are "mustUnderstand" and some of them are NOT.
>>  >>
>>  >> IMHO, if an extension allows "partial support", it is the extension,
>>  >> not the namespace(s), that is to be split, primarily.
>>  >>
>>  >> Suppose extension A allows partial support. Then A should be 
>> split into
>>  >> A1, A2, ... and so on. The namespaces may also be split, but the
>>  >> namespace splitting is secondary to that of the extension.
>>  >>
>>  >>  >
>>  >>  > (II) Again, being able to lookup the "owner" of extension
>>  >> construct by
>>  >>  > looking up namespace URI is a very important feature.
>>  >>  >
>>  >>  > All in all, it really depends on whether you look at the problem
>>  >> from a
>>  >>  > syntax-oriented viewpoint or from a semantic-oriented viewpoint.
>>  >>  > Unfortunately, for the latter case, interpretation of 
>> extensionURI is
>>  >>  > out of this TC scope. Otherwise, I would lean towards to your
>>  >> approach.
>>  >>  >
>>  >>  > Another important clarification to add:
>>  >>  >
>>  >>  > Advanced cases of mixed namespace managment within ONE extension
>>  >> point.
>>  >>  > Consider this example:
>>  >>  >
>>  >>  > <process>
>>  >>  >    <extensions>
>>  >>  >       <extension namespace="http://foo.com"; <http://foo.com>
>>  >>  > extensionURI="http://foo2impl.com"; <http://foo2impl.com>
>>  >>  >             mustUnderstand="yes" />
>>  >>  >       <extension namespace="http://bar.com"; <http://bar.com>
>>  >>  > extensionURI="http://bar2impl.com"; <http://bar2impl.com>
>>  >>  >             mustUnderstand="yes" />
>>  >>  >    </extensions>
>>  >>  >   <scope>
>>  >>  >       <foo:ExtElem1> <bar:ExtElem2 /> </foo:ExtElem1>
>>  >>  >       <bar:ExtElem3 />
>>  >>  >       ...
>>  >>  >   </scope>
>>  >>  > </process>
>>  >>  >
>>  >>  > We should EITHER saying the above usage is illegal?
>>  >>  >
>>  >>  > OR: it works with the following example semantics?
>>  >>  >
>>  >>  > The semantics of "<foo:ExtElem1> <bar:ExtElem2 /> 
>> </foo:ExtElem1>"
>>  >>  > should be under the domain of "http://foo2impl.com";
>>  >> <http://foo2impl.com
>>  >>  >.
>>  >>  >
>>  >>  > The semantics of "<bar:ExtElem3 />" should be under the domain of
>>  >>  > "http://bar2impl.com"; <http://bar2impl.com>.
>>  >>
>>  >> I think we should consider
>>  >>   <foo:ExtElem1> <bar:ExtElem2 /> </foo:ExtElem1>
>>  >> as being belonging to extension http://foo2impl.com.
>>  >>
>>  >> Generally speaking, inside an extension element, there can appear
>>  >> a lot of elements/attributes that does not belong to the same 
>> namespace
>>  >> as the extension element.
>>  >>
>>  >> Yuzo Fujishima
>>  >> NEC Corporation
>>  >>
>>  >>  >
>>  >>  >
>>  >>  > Again, this illustrates another aspect of the design of 
>> looking up
>>  >> the
>>  >>  > "OWNER" of extension by just doing namespace and XML information
>>  >> items
>>  >>  > analysis.
>>  >>  >
>>  >>  >
>>  >>  >
>>  >>  > If the TC feels comfortable with viewpionts expressed above, I 
>> would
>>  >>  > consolidate these clarification to my "newer" proposal. (Sorry
>>  >> rushing
>>  >>  > out my previous email out.)
>>  >>  >
>>  >>  >
>>  >>  >
>>  >>  > Thanks!
>>  >>  >
>>  >>  >
>>  >>  >
>>  >>  > Regards,
>>  >>  > Alex Yiu
>>  >>  >
>>  >>  >
>>  >>  >
>>  >>  > Yuzo Fujishima wrote:
>>  >>  >
>>  >>  >>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> <
>>  >> 
>> OF1830994A.7D15ACF8-ON85256FBD.005F9D2B-85256FBD.00603657@us.ibm.com">mailto:OF1830994A.7D15ACF8-ON85256FBD.005F9D2B-85256FBD.00603657@us.ibm.com 
>>
>>  >>
>>  >>  > <4230C1D7.2010603@bea.com> <4230C1D7.2010603@bea.com">mailto:4230C1D7.2010603@bea.com>
>>  >>  >>>In-Reply-To: <4230C1D7.2010603@bea.com>
>>  >> <4230C1D7.2010603@bea.com">mailto: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"; 
>> <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>>"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 <
>>  >> mailto:wsbpel-unsubscribe@lists.oasis-open.org>
>>  >>  >>>For additional commands, e-mail: 
>> wsbpel-help@lists.oasis-open.org <
>>  >> mailto:wsbpel-help@lists.oasis-open.org>
>>  >>  >>>
>>  >>  >>>
>>  >>  >>>
>>  >>  >>>
>>  >>  >>>
>>  >>  >>
>>  >>  
>> >>---------------------------------------------------------------------
>>  >>  >>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org <
>>  >> mailto:wsbpel-unsubscribe@lists.oasis-open.org>
>>  >>  >>For additional commands, e-mail: 
>> wsbpel-help@lists.oasis-open.org <
>>  >> mailto:wsbpel-help@lists.oasis-open.org>
>>  >>  >>
>>  >>  >>
>>  >>  >>
>>  >>  >
>>  >>
>>  >>
>>  >> 
>> ---------------------------------------------------------------------
>>  >> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>  >> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>  >>
>>  >>
>>  >>
>>  >>
>>  >> 
>> ---------------------------------------------------------------------
>>  >> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>  >> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>  >>
>>  >
>>  >
>>  > ---------------------------------------------------------------------
>>  > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>  > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>  >
>>  >
>>
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]