Re: Naming the service resource

Effectively, the service QName and a serviceURI perform the same function:
they name the service. The difference is that the service QName is a QName
rather than a URI. As long as everything associated with a service has the
ability to work with XML and reference a QName, I'd say that this difference
is mostly irrelavent, but I'm not convinced that everything that might want
to reference a service can effectively use a QName to do so. Certainly a URI
has much wider application.

But that doesn't really hit the core issue. As TimBL has said repeatedly,
all *important* resources should have a URI (not a QName). I consider a Web
service to be an important resource.

My expectation is that in the future a service may have many different
descriptions -- a WSDL description, a DAML description, a policy
description, a text description, and who knows what other type of semantic
description. Is this group audatious enough to claim that the WSDL
description is *the* primary description that defines the service? If so,
then the wsdl:service QName could be the official name of the service. But I
wouldn't be that audatious. IMHO, the service is a resource in its own
right, whether or not it has a WSDL description, and as such, it ought to
have a URI.

Best regards,
Anne

----- Original Message -----
From: "David Booth" <dbooth@w3.org>
To: "Anne Thomas Manes" <anne@manes.net>
Cc: <www-ws-desc@w3.org>
Sent: Thursday, July 17, 2003 12:56 PM
Subject: Re: Naming the service resource


>
> Anne,
>
> On today's teleconference, I took an action to ask you what is the
> difference between your proposed serviceURI and the service QName that we
> currently have.
>
> In [1] you wrote:
> >My suggestion is that we name the *service resource*, as opposed to the
> >interface to the service or the definition of the service. I don't think
> >that it's appropriate to use the WSDL document plus fragment identifier
> >for this purpose, because the fragment identifier is the URI of the
> >definition of the service, not the service itself.
>
> Do you mean that you don't think it would be appropriate to use the URI of
> a WSDL document, plus the fragID of the service, to identify the
> service?  If so, I agree, but I don't think that is what others were
assuming.
>
> I believe we've been assuming that the service QName (i.e.,
targetNamespace
> + Local name) would adequately identify the service, independent of
> endpoints, though it is true that it is syntactically ambiguous, since
WSDL
> 1.2 treats different element types as being in different symbol
> spaces.  (You could have a service, interface, operation and message all
> called "foo", so they'd all have the same QName, and it would not be an
> error in WSDL 1.2.)
>
> Would your proposed serviceURI be semantically similar to the existing
> QName, aside from the inherent ambiguity of our WSDL 1.2 QNames?   If not,
> what would be the differences?
>
> 1. http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0008.html
>
>
> --
> David Booth
> W3C Fellow / Hewlett-Packard
> Telephone: +1.617.253.1273
>

Received on Tuesday, 22 July 2003 15:56:16 UTC