On Apr 23, 2006, at 11:45, Anne van Kesteren wrote:
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"?
And we would list a few media types that must be parsed as XML? I
don't expect the list to grow, all the new ones likely follow the
+xml rule.
application/xsl-xml (note the dash...)
This dates back from when the proposal was to have -xml instead of
+xml. You'll also find some amount of image/svg-xml (which alas ASV
accepts).
text/xml-external-parsed-entity
application/xml-external-parsed-entity
Are these supported?
They probably shouldn't be since they cannot always be represented as
Documents (but as DocumentFragments).
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...
I don't really care either, I'd be happy with a/x, t/x, and +xml.
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
