RE: /service/@targetResource ?

Arthur,
 
First, it's important to stress that there still isn't consensus on this.  So I'm giving you my take, not the group view.
 
Web services specifications are applications of XML.  Meaning SOAP, WSDL, etc. are defined using XML schemas, and use XML instances to carry data, etc. as everyone knows.  So there is a distinction in Web services between the XML applications and the underlying execution environment responsible for implementing the processing model.  The execution environment is not defined beyond stating processing model requirements.  One of the great benefits of Web services therefore is the capability of mapping them to virtually any execution environment.
 
I like to draw the analogy with HTML, especially since XML is its sibling and a descendant of SGML.  In the HTML world a distinction is drawn between the document and the agent responsible for serving it.  I make the same argument for Web services, that the WSDL schema and corresponding XML document comprising the SOAP message are distinct from the agents responsible for generating/parsing/executing them.
 
Many Web services toolkits implement the convention that the URI for the Web service points to the WSDL file.  Once the WSDL file is downloaded, you get within it the URI which is the network address at which the executable agent can be found, and often these are the same.
 
I realize Web services break or distort many of the conventions and practices in the hypertext Web, but I believe it's important to draw the distinction between the XML documents that comprise Web services, and the agents that execute them, just as it's important to distinguish between HTML pages and Web servers.
 
I also realize that Web services are inconsistent with some REST principles, and this underlies much of the debate and highlights the difficulties in coming to consensus.  In my view Web services extend beyond the Web since they are mapped to executable programs that are not part of Web infrastructure per se, and follow different and distinct use cases from REST.  Therefore there are good reasons for Web services to be inconsistent with REST, since the two are aimed at fulfilling different goals.  But you will no doubt get a debate about that as well...;-)
 
Hope this helps clarify the thinking a bit.
 
Eric

-----Original Message-----
From: Arthur Ryman [mailto:ryman@ca.ibm.com]
Sent: Wednesday, May 14, 2003 11:11 AM
To: www-ws-desc@w3.org
Subject: /service/@targetResource ?



In the discussion with the architecture group today, there seemed to be confusion between a service and the resource is acts on. The architecture group defines a Web service to have something that has a URI, but that URI is not the same as the resource that the Web service acts on. 

For example, a bank might have a personal banking Web service. The account Web service acts on the bank. 

We can build a URI from the QName of the personal banking Web service, e.g. http://xml.fredsbank.com#service(PersonalBanking). The bank itself might have the URI http://fredsbank.com. 

We agreed to add an optional @resource attribute to <service>. I suggest it would be clearer to rename that attribute to @targetResource to make it clear that the service acts on that resource as opposed to it being the URI of the Web service. 

Arthur Ryman