Re: [XHR] What mime types should trigger XML parsing?

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  
>> <mjs@apple.com> 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

Received on Sunday, 23 April 2006 18:50:58 UTC