RE: Issue 019: WSDL Version Neutrality

Below

> -----Original Message-----
> From: Hugo Haas [mailto:hugo@w3.org]
> Sent: Tuesday, November 16, 2004 2:14 PM
> To: Jonathan Marsh
> Cc: public-ws-addressing@w3.org
> Subject: Re: Issue 019: WSDL Version Neutrality
> 
> * 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.

That's not guarantee, as I'm sure you know.  There is nothing that says
that you are required to make WSDL available at the target namespace
(though it is recommended by the WSDL 2.0 spec as a good idea, IMO
mostly to justify the syntax choices we made in the face of murky
architecture).  There is nothing that lets me know from looking at the
message whether the URI is really a component designator or not (all I
know is that it's an action value).

Neither is there anything that says that if you dereference a URI from
the WSDL 1.1 default algorithm that you won't get some useful
information. It seems to be standard practice at the W3C to recommend
that you provide dereferencable documentation for any interesting URI,
and I think action qualifies.

So the benefits you seek are not guaranteed, nor are they precluded by
using a different algorithm.  If you concede that this line of argument
is not an irresistible argument in favor of Component Designators, I'll
concede that Component Designators have a slight advantage over the
current algorithm in this regard, and we can move on to weigh other
factors.

> > 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
> IMO.
> 
> 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.

The fragility and architecturally suspect nature of fragment identifiers
worries me.  You point out one of the pitfalls, but I fear there may be
others.  I've had to go to the TAG twice with fragment identifier issues
before and I hope not to do it again.  My experience says avoid fragment
identifiers if all else is equal.  (I know that's not a logical
argument, just background of where I'm coming from.)

> > 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.

While a component designator can always be used as an action, an action
cannot always be used as a component designator.  In the current
WS-Addressing spec, actions are not required to be unique across
operations (though in the default case they just so happen to be).  That
leads me to believe they are not "the same thing."  Reusing component
designators in this different context might reinforce that
misperception.

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

Received on Wednesday, 17 November 2004 19:49:24 UTC