W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

Re: Issue 019: WSDL Version Neutrality

From: Hugo Haas <hugo@w3.org>
Date: Tue, 16 Nov 2004 17:14:02 -0500
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: public-ws-addressing@w3.org
Message-ID: <20041116221402.GA1017@w3.org>
* Jonathan Marsh <jmarsh@microsoft.com> [2004-11-15 11:24-0800]
> >   This leaves us with an interesting issue: if there is a WSDL 1.1 and
> >   WSDL 2.0 description available, which is the implicit value of the
> >   action property? If in a year's time we release WSDL 2.1, what
> >   happens? I believe that there is an implicit value of the action URI
> >   recognized by the recipient of the addressing information for the
> >   description of the service made in each version of WSDL. Those are
> >   equivalent for the purpose of our specification.
> Just because WSDL 2.0 has coined a URI that one could use as an action,
> doesn't mean that we have to use it as our default.  You point out at
> least one good reason not to - that having a URI creation algorithm that
> is independent of the WSDL version is a good idea.  Identifying a
> component and specifying an action are not necessarily the same thing.
> The similarity of the results of the algorithm to generate unique action
> URIs to WSDL component properties, which have the same characteristic,
> is to some degree conincidental.

Because WSDL 1.1 and 2.0 have different component models, we will not
escape the chore of writing a specific section for each of those. As
WSDL 2.0 already defines URIs to identify each component, which will
be included in our media type registration, I think that it would be a
bad thing to have another URI to refer to essentially the same thing.

That way, if a developer gets a SOAP message, she can look at the
action, paste it into a (Web, WSDL, UDDI, etc.) browser and get the
right snippet of XML if it's the implicit WSDL 2.0 URI using the
component designator.

> In any case, it's important to recognize the difference in use cases
> between describing an existing Web Service and developing a Web Service
> from scratch.  The defaulting mechanism is good for the latter case - it
> gives you a complete set of action URIs quickly.  If you are describing
> (say in WSDL 2.0) an existing service (say described in WSDL 1.1), you
> already have a set of action URIs for that service, and you would have
> to set those explicitly in the new WSDL if the default algorithm doesn't
> match.
> A single defaulting mechanism simplifies migration of a WSDL 1.1 service
> + WS-Addressing to WSDL 2.0 + WS-Addressing.  It also appears to me to
> be simpler to adapt the existing WSDL 1.1 algorithm to accommodate WSDL
> 2.0 than the reverse.

As you pointed out, this is only a migration argument. From an
architectural standpoint, and recognizing that eventually people will
describe their services in WSDL 2.0 and not necessarily in WSDL 1.1 —
or just for backwards compatibility purposes — it's much cleaner to
use the component designator URI as the implicit value for WSDL 2.0

Maybe if others agree with me, and if we also want to ease migration,
we should actually change the algorithm for 1.1 to match 2.0's. My
only concern is that we would define a fragment identifier for a
text/xml document. I _think_ it would be OK if we call out that, for
WSDL 1.1, those fragments identifiers would be meaningless and that
the URI would only make sense in the context of the [action] property.

> And of course, this doesn't prevent one from using the WSDL 2.0
> Component Designator URIs if one wants to specify them explicitly --
> even for a WSDL 1.1 service, though one should be aware that the context
> of that URI is "action" not "component identification".

It seems that we disagree on the purpose of the URI. You see a clear
separation between action and component identification, while I don't
see why it needs to be the case: it's just an identifier pointing to
the same thing.



Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Wednesday, 17 November 2004 00:57:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:21 UTC