[
Lists Home |
Date Index |
Thread Index
]
7/5/2002 7:36:46 AM, Eric van der Vlist <vdv@dyomedea.com> 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.
|
