W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2003

Re: Naming the service resource

From: David Booth <dbooth@w3.org>
Date: Thu, 17 Jul 2003 12:56:35 -0400
Message-Id: <>
To: "Anne Thomas Manes" <anne@manes.net>
Cc: www-ws-desc@w3.org


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 Thursday, 17 July 2003 12:56:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:32 UTC