[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 unifying proposal
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" extensionURI="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" 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" ==> Definition Owner is: "http://bar2impl.com" 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" extensionURI="http://bar2impl.com" mustUnderstand="no" /> <extension namespace="http://bar.com" extensionURI="http://bar3impl.com" mustUnderstand="yes" /> </extensions> 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. 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. (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" extensionURI="http://foo2impl.com" mustUnderstand="yes" /> <extension namespace="http://bar.com" extensionURI="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". The semantics of "<bar:ExtElem3 />" should be under the domain of "http://bar2impl.com". 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> 4230C1D7.2010603@bea.com"><4230C1D7.2010603@bea.com> In-Reply-To: 4230C1D7.2010603@bea.com"><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> <extensions>? <extension namespace="anyURI" extensionURI="anyURI"? mustUnderstand="yes|no" />+ </extensions></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> <extensions> <extension namespace=<a class="moz-txt-link-rfc2396E" href=""http://foo.com">"http://foo.com"</a> /> </extensions></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: <xsd:import namespace="anyURI" schemaLocation="anyURI"? /> <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--------------------------------------------------------------------- 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]