[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: W3C Schema: Resistance is Futile, says Don Box

• To: "'Paul Prescod'" <paul@p...>,<xml-dev@l...>
• Subject: RE: W3C Schema: Resistance is Futile, says Don Box
• From: "Aaron Skonnard" <aarons@d...>
• Date: Tue, 11 Jun 2002 23:44:24 -0600
• Cc: "'Rich Salz'" <rsalz@d...>
• Importance: Normal
• In-reply-to: <3D06D031.C2A27901@p...>
• Organization: DevelopMentor
• Reply-to: <aarons@d...>

> -----Original Message-----
> From: Paul Prescod [mailto:paul@p...] 
> 
> 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
element.


>  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.

<snip/>

> > ...
> > 
> > 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.

-aaron
http://staff.develop.com/aarons

• Follow-Ups:
  • Re: W3C Schema: Resistance is Futile, says Don Box
    • From: Paul Prescod <paul@p...>

• References:
  • Re: W3C Schema: Resistance is Futile, says Don Box
    • From: Paul Prescod <paul@p...>

• Prev by Date: Re: Come On, DTD, Come On! Thoughts on DSDL Part 9
• Next by Date: Best Mailing List for Web Services?
• Previous by thread: Re: W3C Schema: Resistance is Futile, says Don Box
• Next by thread: Re: W3C Schema: Resistance is Futile, says Don Box
• Index(es):
  • Date
  • Thread