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, 24 Jul 2003 21:49:35 -0400
Message-Id: <5.1.0.14.2.20030724120918.02c27a88@localhost>
To: "Anne Thomas Manes" <anne@manes.net>
Cc: <www-ws-desc@w3.org>, "Arthur Ryman" <ryman@ca.ibm.com>

At 11:39 PM 7/23/2003 -0400, Anne Thomas Manes wrote:
>While I think that R120 specifies an important requirement (URI for each
>element within a WSDL document), I don't think it properly addresses the
>requirement that I'm making.
>
>A wsdl:service element is a definition of a service implementation, but it
>isn't the service itself.

I'm a little unclear about what you are advocating.  According to the 
terminology that (I think) the WG uses (and I tried to clarify in [1]), the 
"service" is the thing defined by the <wsdl:service> element.  But it 
sounds like you are referring to something else more abstract, such that a 
service (using the definition in [1]) may be an implementation of this more 
abstract thing.  (I'll call this abstract thing the "abstractService" for 
the moment.)

I agree that if we did this, you could easily recognize when two services 
actually implement the same abstractService.  However, two questions arise:

1. Would this be the same as the wsdl:interface?  After all, a wsdl:service 
implements a wsdl:interface.

2. If you are suggesting that the WSDL document be able to specify the URI 
of some other resource (the abstractService), then how would this 
abstractService compare with the notion of targetResource, which we 
considered but finally rejected?

>And I don't think it's appropriate to ask someone
>writing a DAML description to use a wsdl:service element to refer to the
>service implementation.

Presumably, under Arthur's proposal for satisfying R120, they wouldn't have 
to.  They would instead use the URI that is constructed from the 
wsdl:service's QName.  Of course, some negatives would include:

a. This URI would be constrained to be written a particular way, as 
specified by Arthur's R120 mapping.

b. You need to know Arthur's R120 mapping to know how to produce the URI 
from the QName.  Clearly, this is less obvious than simply copying a URI, 
if the wsdl:service had been identified by a URI to begin with.

c. If the service is first identified using something other than WSDL (such 
as DAML-S), the URI that is chosen to identify it may not conform to the 
pattern produced by Arthur's R120 mapping, so it may not reverse-map it 
back to a wsdl:service QName.

References
1. http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0018.html

>----- Original Message -----
>From: "David Booth" <dbooth@w3.org>
>To: "Anne Thomas Manes" <anne@manes.net>
>Cc: <www-ws-desc@w3.org>; "Arthur Ryman" <ryman@ca.ibm.com>
>Sent: Wednesday, July 23, 2003 10:41 AM
>Subject: Re: Naming the service resource
>
>
> > Anne,
> >
> > 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:
> > http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0021.html
> > Do you think his proposed mapping represents an adequate solution to the
> > problem?
> >
> >
> > 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,
> > >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
> > > >
> >
> > --
> > David Booth
> > W3C Fellow / Hewlett-Packard
> > Telephone: +1.617.253.1273
> >

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273
Received on Thursday, 24 July 2003 22:01:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:25 GMT