RE: Web Service Definition [Was "Some Thoughts ..."]

> -----Original Message-----
> From: Gaertner, Dietmar [mailto:Dietmar.Gaertner@softwareag.com]
> Sent: Saturday, March 02, 2002 4:23 PM
> To: 'jasnell@us.ibm.com'
> Cc: 'www-ws-arch@w3.org'
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
> 
> 

> Take for example the stockquote "service", which we all know and love
> returning, a plain HTML page. It can be implemented as an application or 
> component, identified by an URI
> (e.g. http://www.stockquote.org/quotes?symbol=xzy), can be 
> described (the URI is enough
> of a description, if you wish), can be accessed by software via
> internet-based protocols, and the interaction does not necessarily require
human 
> interaction (the client could scrape the HTML).

Hi Dietmar,

I think this is exactly the kind of question that will clarify what we want
to do, and *perhaps* allow a crisper definition of "web service" somewhere
down the road.

I personally think this is sortof a web service, but I wouldn't dispute that
it is not what we want to focus on.  Let's talk about what would make it a
web service:

a) If the result were HTML with well-documented div/span tags and class/id 
   attributes to identify the   specific information being returned (to make
   "scraping" easier)?
b) If the result was XML with the vocabulary clearly documented?
c) If the result was XML that matched a specific schema?
d) If the result was SOAP with the payload documented in human-readable
form?
e) If the result was SOAP and the payload documented with WSDL?
f) If URI encoded a SOAP invocation message and the result was SOAP with the

   payload documented with WSDL.

OK, NOBODY would dispute that f) is a "web service", right?  Likewise, e) is
pretty clearly a "web service" under our charter; to insist that the
invocation is a SOAP message rather than a "human readable" URI would be
unacceptable to a signficant number of people in the W3C, probably including
the Director (as I read his various musings on the Web Architecture,
anyway).

d) is also a "web service" in what I take to be the consensus of the WG as
expressed on teleconferences and the mailing list.  I doubt if very many
people here would vote against c) either.

b) is getting fuzzy for most of us, I'll bet ... and a) is really fuzzy.  I
personally would say that both are within our scope so long as the
documentation of the result is unambiguous enough to be used by ordinary
programmers to write the code to "scrape" the result into the calling
application's data structures.  To insist that the documentation has to be a
schema or WSDL, I believe, leads to the "it's turtles all the way down"
problem, i.e., sooner or later, the documentation, code or schema or
whatever has to be sensible to a human being.  See Clay Shirky's article at
http://www.xml.com/pub/a/2001/10/03/webservices.html ... and the "turtles"
reference is explained at http://www.the-funneled-web.com/Hawking.htm

Nevertheless, I wouldn't insist on a) or b) being "web services" if that's
what it takes to move forward.

Received on Sunday, 3 March 2002 01:13:49 UTC