Re: Naming the service resource


You pose an important question, and I certainly agree that a service is 
important enough to warrant a URI.

Arthur Ryman has done some excellent work figuring out how to
make the QName --> URI mappings work, given that our QNames are ambiguous:
Do you think his proposed mapping represents an adequate solution to the 

At 10:25 PM 7/21/2003 -0400, Anne Thomas Manes wrote:
>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,
>----- Original Message -----
>From: "David Booth" <>
>To: "Anne Thomas Manes" <>
>Cc: <>
>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
> >
> > I believe we've been assuming that the service QName (i.e.,
> > + Local name) would adequately identify the service, independent of
> > endpoints, though it is true that it is syntactically ambiguous, since
> > 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.
> >
> >
> > --
> > David Booth
> > W3C Fellow / Hewlett-Packard
> > Telephone: +1.617.253.1273
> >

David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Wednesday, 23 July 2003 10:41:52 UTC