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] SOAP, XSD, and HTTP

[ Lists Home | Date Index | Thread Index ]

At 12:47 PM 6/12/2002 -0400, Mike Champion wrote:
>Uhh, they aren't deprecated by SOAP 1.2.  SOAP defines a data
>model that is rich enough to handle arrays, structs, graphs,
>etc. that can be defined in actual programming languages
>but XSD does not directly support.   Also, SOAP -- being just
>an "envelope" -- defines a model to identify the encoding style,
>which may be XSD, SOAP, or something yet to be invented.

I have a very hard time reconciling an admixture of envelopes with messages 
and the kinds of approaches I see REST advocating.

>It's time to move on ...  Or to put it more bluntly, "REST WON!
>Learn to accept victory gracefully!"

I don't see victory here.  I see people weary of argument who are more or 
less agreeing on the least possible set of items in order to get on with 
the work they plan to do anyway.

>Of course, SOAP will continue to be mis-used, just as HTTP is mis-used;
>the W3C has tried to clarify best practice for its use.

And that will accomplish very very little.

>I would suggest that people who feel strongly about the mis-use of SOAP
>focus on educating the abusers, and on demanding tools from vendors that
>easily support best practices for the use of WSDL, HTTP, and SOAP.

We've tried this at the Web Standards Project.  My continual frustration at 
the uselessness of such tactics and the W3C's refusal to "demand" anything 
led me to wander away to places where I could more bluntly state my 

>To trot out my favorite aphorism yet again, "the best is the enemy of the
>good."  I could probably be persuaded that SOAP is not "the best", and that
>"HTTP everywhere" and using REST-friendly ideas such as tupe spaces /
>XML spaces to achieve notification, reliability,  security, etc. are the
>"best" way forward.  Still, a) none of these are fundamentally incompatible
>with SOAP and b) setting up SOAP and REST as enemies will probably result
>in a worse situation (e.g., the Web being "embraced and extinguished" by
>a SOAP Everywhere protocol stack) than we would be in with a grudging
>respect between the various partisans.

SOAP is not the best, certainly.  I have a very hard time even qualifying 
it as "good" overall.  It's a remarkable misuse of multiple technologies, 
doing an amazing job of ignoring the potentials of those technologies.

While I often enjoy creative mixing of things that probably shouldn't be 
mixed, this case seems like one where it's worth laying out the trenches 
and settling in for a very long guerilla battle to come.

Simon St.Laurent
"Every day in every way I'm getting better and better." - Emile Coue


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

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