- From: David Booth <dbooth@w3.org>
- Date: Thu, 17 Jul 2003 12:56:35 -0400
- To: "Anne Thomas Manes" <anne@manes.net>
- Cc: www-ws-desc@w3.org
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 Thursday, 17 July 2003 12:56:41 UTC