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

> -----Original Message-----
> From: Austin, Daniel [mailto:Austin.D@ic.grainger.com]
> Sent: Friday, February 22, 2002 5:59 PM
> To: 'David Orchard'; www-ws-arch@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
> 
> 
> I believe that our charter specifies that XML must be used. [1]

Does that mean that we're working on the definition of an "XML Web Service"?
Or that we're at the moment working on a definition of a generic "web
service", with the caveat that our architecture will only cover "XML Web
Services." 

Cheer up, it gets worse :~) We're going to encounter some semantic dragons
if we try to limit web services to "XML", because would have to define
"XML", and that's not easy either!  Our Charter references the XML activity
page, not the 1.0 syntax, and SOAP 1.2 is based on the InfoSet. Likewise,
our Charter talks a good bit about URIs and the Web Architecture; is a
serialization of a SOAP request in URI syntax "XML?"  (The possibility has
been discussed on the dist-app and TAG lists, as I recall). Likewise the DOM
Abstract Schema spec has an explicit use case for representing RDBMS schema
via the DOM interfaces; and I know of various tools that parse a non-XML
syntax and generate SAX events, so there's precedent for manipulating
non-XML resources with XML interfaces. And HTTP can handle multiple (XML and
non-XML) representaitons of the same abstract "resource".  If someone
requests a non-XML representation of a service resource, are we going to say
that it's not REALLY a web service, but it is if they request an XML
representation?  

Sorry, I know I'm being a bit pedantic ... and don't worry, I don't suggest
we go down any of these ratholes! I'm just saying that we have our work cut
out to define "web service" without getting too picky about exactly what
role "XML" must play in the definition. 

We all know a pure case of a web service when we see one, i.e. a WSDL
definition in a UDDI directory used to rigorously define a SOAP message that
will invoke a software component that generates an XML result.  We also
probably agree  that an HTML form that that changes frequently that contains
instructions for how a human user can enter information and get a result in
a loosely-defined format that only human intelligence can make sense out of
is *not* a web service.  Where exactly in the middle a "web page" definitely
becomes a "web service" could be debated endlessly.  Rather than trying to
draw a hard line, let's accept that there is a large grey area in the
middle, warn our readers that it exists, and illustrate our definition with
pure cases of web services and not-web-services, and clarify our position on
some interesting corner cases, much like those that David Orchard outlined
yesterday.

Received on Friday, 22 February 2002 19:10:27 UTC