[i60] Splitting semantics of namespace across multiple WS-A specs inhibits independent versioning

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