OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] W3C Schema: Resistance is Futile, says Don Box

[ Lists Home | Date Index | Thread Index ]

> -----Original Message-----
> From: Paul Prescod [mailto:paul@prescod.net] 
> Aaron Skonnard wrote:
> >...
> > 
> > If you drop the SOAP encoding rules (section 5), which many 
> > now consider to be deprecated by XML Schema, SOAP essentially 
> > codifies the following:
> > 
> > 1. Framing and extensibility (via headers)
> > 2. Standard representation for errors
> > 3. Binding for sending messages over HTTP
> > 4. Binding for mapping messages to RPC
> HTTP supports the first two and doesn't need the last two.
> > If HTTP is an application protocol, I don't see how SOAP can't 
> > be one.
> Let's look at the simplest possible HTTP message:
> GET /index.html HTTP/1.1
> It declares three things.
>  1. what method to use. The HTTP specification has tons to 
> say about the semantics of the "GET" method including its 
> idempotency, cachability and safety.

The SOAP operation is identified by the qualified name of the payload

>  2. what URI you want to get. If you read the HTTP spec 
> you'll find that there is a ton in there about the 
> interpetation of that and of course behind that is the entire 
> body of Web standards

A SOAP service is also identified by a URI (any transport).

>  3. the version of HTTP in use.

The version of SOAP is identified by the SOAP namespace.


> > ...
> > 
> > SOAP as it sits today doesn't give you much in terms of 
> > interoperability benefit simply because there are no standard 
> > headers. We're still trying to agree on the framing and 
> > extensibility mechanism before we charge down that path. 
> > The real interoperability benefit will come over time as
> > standard headers emerge.
> I agree, and think that this would be where SOAP could 
> provide great value if it didn't get there by tearing down 
> the interoperability we have already built around URIs and 
> operations upon them. Two steps backwards, one step forward. 

I think "tearing down" is dramatic. SOAP embraces HTTP and tries to
clearly codify its use to help ensure interoperability. This is where
you'd like to see REST come in, right?

> > HTTP wouldn't be much of a protocol either if you throw out all the
> > headers.
> I guess that's why HTTP defines a bunch of headers. 
> ;) So should SOAP.

That's exactly what's happening through layered specifications like
WS-Security proposed by Microsoft, IBM, and Verisign. There are many
other proposals on the table from different organizations.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS