On Apr 23, 2006, at 6:57 AM, Robin Berjon wrote:
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"?
Sounds good to me.
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.
The only one not on the current list that Safari supports is text/
xsl. I don't care that much about it, but it is far more widely used
than the official "application/xslt+xml" and for various reasons
(namely the fact that IE insists on text/xsl for XSL stylesheets)
it's impossible to serve it with the proper MIME type. I don't know
if anyone cares about retrieving XSL stylesheets with XMLHttpRequest
though.
Regards,
Maciej
