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] Article: "The horror of XML"

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


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

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