Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Apologia pro SOAP (was RE: toxins/tocsins )
 7/5/2002 7:36:46 AM, Eric van der Vlist <vdv@d...> wrote: > >If I use a conform XML parser I am unable to check that a document is a >valid SOAP document using a XML schema language or a XSLT >transformation. I don't understand why not. There are normative WXS schemas defining the valid components of all the SOAP namespaces. A schema-aware system could validate the SOAP elements/attributes in a message ... and SOAP by definition can't say anything about the parts of the message that aren't in its namespace. It's true that SOAP forbids one from using DTDs or PIs anywhere in the message, and that constrains one's ability to validate the content in other namespaces. Still, the reasons for this have to do with the problems of XML itself: there's no way to embed an arbitrary XML 1.0 document inside another (constraints on where DTD info can occur), entity declarations and references create all sorts of interoperability problems that the archives of this list will describe in horrifying detail, and the common use of PIs as a "secret handshake" between applications and thus an invitation to interoperability problems. [The latter is perhaps a weak reason for forbidding PIs in SOAP, but AFAIK the XMLP WG has gotten very little pushback on this ... SOAP 1.2 is in last call, so speak now or forever hold your peace!] Given SOAP's most basic requirement -- to be an envelope to wrap around XML message(s) to provide additional routing/processing information -- how could SOAP *not* forbid embedded DTDs? If DTDs were namespace-aware, I guess the SOAP envelope could come after the DTD information ... but that would be a bit bizarre for an envelope, no? > >In other words, I can't process a SOAP document with a conform XML >parser and a parser which processes a SOAP document as specified by the >SOAP specification isn't a conform parser, ie I need a different set of >tools to process XML and SOAP documents. Not an XMl 1.0 processor, but you can with a conforming WXS processor ... granted it wouldn't understand the SOAP semantics, but neither would it understand SVG semantics ... but one *could* implement the SOAP processing rules in SAX or DOM applications, AFAIK. Of course, maybe the idea of an XML envelope around XML messages is just broken, and the industry should standardize on MIME or something as a way of packaging the messages, with SOAP just one of the XML documents in the package. SOAP 1.2 doesn't describe a normative way to do this, but it is possible (and there will be some non-normative description of how to do it available). >Shouldn't we worry to need a different set of tools for each new "XML >application"? Wouldn't you use different tools to process Docbook and SVG? RDF and XHTML? All XML provides is a common infrastructure for parsing, transformation, manipulation, querying, etc., and you can apply all that to SOAP. If there was a standard way of declaring the profile of XML that an application used, you could validate SOAP with totally generic tools. If there was a standard way of embedding XML documents in other XML documents, SOAP wouldn't need to use the subset. I don't like the fact that SOAP is used to cloak some horrible, tightly-coupled, quasi-proprietary products and architectures in the XML standards flag any more than Eric or Simon ... but I guess I think that "SOAP doesn't create horrible quasi-proprietary non-scalable, non-interoperable messes, people create horrible quasi-proprietary non-scalable, non-interoperable messes with SOAP"... and they do the same with XML, CORBA, HTTP, Java, etc. etc. etc. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
