On Sun, 23 Apr 2006 02:34:08 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
"Otherwise, if the Content-Type header contains a media type (ignoring
any parameters) that is either text/xml, application/xml, or ends in
+xml, it must be an object that implements the Document interface
representing the parsed document. If the document was not an XML
document, or if the document could not be parsed (due to an XML
well-formedness error or unsupported character encoding, for instance),
it must be null."
Should this be taken to mean that for any other Content-Type,
implementations MUST NOT attempt to parse as XML? If so, please say
that. Optionally allowing XML parsing for types not specifically
mentioned would be bad for interoperability.
So instead of "If the document was not an XML document" having "If
Content-Type did not contain such a media type"?
Also, consider the following media types that represent XML data of some
form, but are not text/xml, application/xml, or a type that ends in
+xml. Some of these are unofficial or obsolete:
text/xsl
364,000: http://www.google.com/search?q=text%2Fxsl
application/xslt+xml
9,270: http://www.google.com/search?q=application%2Fxslt%2Bxml
application/xsl-xml (note the dash...)
137: http://www.google.com/search?q=application%2Fxsl-xml
text/mathml
569: http://www.google.com/search?q=text%2Fmathml
application/mathml+xml
815: http://www.google.com/search?q=application%2Fmathml%2Bxml
text/xml-external-parsed-entity
application/xml-external-parsed-entity
Are these supported?
application/smil
That one is obsoleted by application/smil+xml... But yeah...
Of these, I only know for sure that text/xsl is in common use for
sending XML content, even though it is unofficial and technically
illegal.
Any proposals? Personally I don't really care about any of them...
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
