XML and SOAP constraints? (was RE: WSA constraints)

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Monday, September 23, 2002 2:40 PM
> To: Anne Thomas Manes; Mark Baker; www-ws-arch@w3.org
> Cc: mark.baker@sympatico.ca
> Subject: Re: WSA constraints
> 
>
> 
> I'm confused by the strong need to stick to XML as a constraint.
> To me, Web services are about service-oriented architectures and
> that does not necessarily imply the use of XML on the wire.
 
> XML is just one (really good) technology. However, its not the
> only technology available to serialize some typed information.

[not speaking as a co-chair, just thinking out loud]

As much as I shudder at the prospect of re-opening the "what is a
web service" discussion, I think we are going to have to take a
definitive stand on the role of XML and SOAP in the WSA.  Our working
definition talks about "interfaces and bindings ... capable of being
defined, described, and discovered as XML artifacts."  As I recall, we mean
"XML" (as does SOAP 1.2, explicitly) to mean the Infoset, not the
serialization syntax.  Clearly a module that takes a binary representation
of a SOAP message, parses it into an XML infoset representation, processes
it according to the SOAP model, and passes it along in XML 1.0 serialization
syntax is a "SOAP processor".  

I think we should clarify this somewhere, perhaps along the lines of
Sanjiva's explanation above.   Would you disagree, Anne? If so, what can we
say about non-XML web services in the architecture?  

FWIW, I was originally inclined to think of an HTML page for something like
a stock quote or online catalog with a well-documented format that a program
could easily work with (e.g., "id" attributes that would point to specific
bits of information), that was invoked with a well-documented URI format, as
a "web service" even though it didn't use XML, SOAP, or WSDL.  I wouldn't
defend that position now, at least in terms of the WSA -- a "WSA-compliant
web service" needs to be grounded in *something* so that additional features
(choreography, security, reliable transport, etc.) can be layered on it.
Hmm, I guess the WS Description folks are talking about being able to
describe non-XML content, so if they do that, perhaps my example *would* be
compliant.  Or for that matter, if browsers reliably parse HTML into an
infoset so that a portable DOM program can extract the information in a WSDL
description, I guess it could be an  "XML" web service as far as we're
concerned.

On the other hand, the path of least resistance and most interoperability
might be to accept that a "W3C WSA-compliant XML web service" *must* use
SOAP and be capable of being described with WSDL.  (Mind you, I think this
is totally orthogonal to the issue of REST vs something else ... the
SOAP-format resource could be accessed via the HTTP methods  and identified
by a URI).  Do we need to do that to keep the WSA reasonably focussed?  Will
we get major pushback from anyone if we go that direction?

Received on Monday, 23 September 2002 15:18:03 UTC