- From: Francisco Curbera <curbera@us.ibm.com>
- Date: Thu, 2 Jun 2005 00:02:41 -0400
- To: "Jonathan Marsh" <jmarsh@microsoft.com>
- Cc: public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
The most important issue here is that independent versifying of the three specs is a bad idea, a possible source of every kind of trouble. I completely agree with that; I think we have discussed that in the past in the context of this or other issues. Three namespaces, or a single one, could perfectly be used for the specs as far as I am concerned, but I don't believe it matters much as long as the fact that all specs need to evolve consistently is clearly spelled out. Another issue is whether Core and SOAP should be merged, and that we have also discussed several times in the past. It is a bad idea because undermines the possibility of using WS-Addressing semantics on non-SOAP protocols. Paco "Jonathan Marsh" <jmarsh@microsoft.com> To: <public-ws-addressing@w3.org> Sent by: cc: public-ws-addressing-req Subject: [i60] Splitting semantics of namespace across multiple WS-A specs uest@w3.org inhibits independent versioning 05/24/2005 04:47 PM I have an action to start discussion of this issue. I thought this issue would demonstrate that separate versioning of our three specs would lead to a cross-product of schemas, it turns out we simply can’t version these specs independently anyway. While it appears that we’ve created three independent specs, there actually is a hierarchy of dependencies: Core <-- SOAP Binding <-- WSDL Binding If the SOAP Binding changes, the WSDL Binding spec must also be updated, as it mandates a particular version of the SOAP Binding. If the Core changes, both the SOAP and WSDL Binding specs must also be updated, as they depend upon a particular version of the Core. New (SOAP or non-SOAP) bindings (including versions) cannot be introduced independently. For instance, if a new SOAP Binding for WS-A were introduced, the facilities in the WSDL binding would not be sufficient to indicate the new SOAP Binding is in use. If a non-SOAP Binding is being used, the WSDL Binding extension doesn’t provide a normative way to determine what binding features are being asserted. A separate WSDL Binding extension (or an extension to the wsaw:UsingAddressing extension) must be developed in each of these cases. I think this issue points out that the implications present in the spec that wsaw is separate from wsa for versioning purposes are misguided. A binding creator will have to define a separate extension, or an extension point on the extension, to denote which binding is in use. We should make it clear in the WSDL Binding spec that the extension only makes meaningful assertions when it is used in conjunction with a SOAP binding, and that those assertions are limited to the SOAP Binding we define. It isn’t a sufficient general purpose indicator to denote what it means for WS-Addressing to be engaged in some other type of binding. This mostly affects the Abstract and Introduction of the WSDL Binding spec. The split between Core and SOAP specs of the definition of a single namespace also causes some unfortunate consequences. Since the mapping of spec to namespace isn’t 1-1, some questions are left unanswered - is the namespace open, and each of these specs stakes out a few terms inside it, leaving the possibility that other specs to define additional terms? Or is the namespace closed, and versions or extensions need to be expressed through a different namespace? Having two specs implies it’s open (unless you tie those two specs even further together by specifying cross-dependencies). But the wsaw:UsingAddressing extension makes a strong implication that the namespace is closed, because it is insufficient to indicate where the definition of new terms might be found. Resolving this contradiction might have impact throughout the spec family. Merging the Core and SOAP Binding specs would reduce the implication of openness, and be consistent with the WSDL Binding. Adding text to the Core and SOAP Binding stating the namespace policy and making the cross-dependencies more explicit, is also possible. From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Prasad Yendluri Sent: Friday, April 15, 2005 11:28 AM To: public-ws-addressing@w3.org Subject: NEW ISSUE: Splitting semantics of namespace across multiple WS-A specs inhibits independent versioning Title: Splitting the semantics of a (e.g. WSAW) namespace across multiple WS-A specs inhibits independent versioning of the specifications Description: The proposed resolution for issue i021 plans to use a marker defined in the WSAW namespace introduced by one of the WS-A specifications to flag the use of WS-Addressing in a WSDL description. The intent is to use the WSAW namespace to identify the WS-Addressing specification and the version of it. However given WS-A is now split into three separate specifications the chosen namespace where this marker is defined needs to identify this group of specifications and their "common" version, there by inhibiting independent versioning of the specifications. Hence this brings up a generic issue with splitting semantics of a namespace across multiple specifications inhibiting the ability to versioning those specifications independently. Target: Core, WSDL Binding and SOAP Binding Justification: Given the WS-Addressing comprises three coupled but independent specification, it is highly desirable not to inhibit independent versioning of the constituent specifications, as each specification will need to change based on the issues and functionality changes pertinent to that specification. Ref: Action item, http://www.w3.org/2005/04/11-ws-addr-minutes.html#action03
Received on Thursday, 2 June 2005 04:02:46 UTC