[
Lists Home |
Date Index |
Thread Index
]
> In other words, XML processors used for SOAP need to report at least the
> presence of a document type declaration precisely because SOAP forbids
> these. A processor which does not handle the document type declaration
> is inadequate for SOAP.
And "and PI" to the above. SOAP doesn't allow DTDs or PI's.
>> Since SOAP 1.2 is defined on the infoset, it presupposes that a parser
>> has done its work ... AFAIK, that doesn't imply an XML syntax
>> parser, just one that produces XML Infosets.
>>
>
> On no. Not another one. You mean you can send something to a SOAP
> service that is not an XML document, provided the service knows how to
> turn it into an infoset? Yuck. I'm sure that loophole will do wonders
> for interoperability. Every day in every way I'm learning to despise the
> Infoset just a little bit more.
It's not quite that bad. SOAP 1.2 is defined in terms of the infoset.
(At the time, I argued against this and lost.) While this mainly makes
the spec more verbose and harder to read, it does allow one to create a
SOAP message with DOM, and send it to someone else via SAX or suchlike.
That might be a good thing. However, the only defined mappings all say
"serialize according to XML 1.0".
I think we're getting an interesting split in W3C specs: those that are
defined in terms of the serialization, and those that are defined in
terms of infoset. The problem comes when the mix, such as when you want
to sign or encrypt a SOAP message. Seems like TAG fodder...
/r$
|
