W3C home > Mailing lists > Public > public-webapi@w3.org > May 2007

Re: [XMLHttpRequest] update from the editor

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 08 May 2007 15:29:30 -0700
Message-ID: <4640F9CA.8090004@sicking.cc>
To: Maciej Stachowiak <mjs@apple.com>
CC: Anne van Kesteren <annevk@opera.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, "Web API WG (public)" <public-webapi@w3.org>

Maciej Stachowiak wrote:
> On May 8, 2007, at 1:25 PM, Jonas Sicking wrote:
>> Anne van Kesteren wrote:
>>>>>  * text/xsl has been added as a MIME type that causes
>>>>>    responseXML to return a Document object (if the resource
>>>>>    can indeed be parsed according to the XML specfications.)
>>>>>    Again, for compatibility reasons.
>>>> There is no need for the draft to encourage use of unregistered media
>>>> types, and there is very little need for the draft to apply non-XML
>>>> treatment to media types like application/smil which are defined for
>>>> use with XML documents. I believe it is entirely sufficient and more
>>>> appropriate to state, for example, "If the internet media type in the
>>>> Content-Type header indicates the entity body is an XML document, ...".
>>> Vendors have indicated they would like to have defined what that 
>>> would mean, which is what the draft now tries to say. This indeed 
>>> excludes (now obsolete?) MIME types such as application/smil but I 
>>> don't think that will cause a problem in practice. If it does, I 
>>> suppose we should get implementation feedback during CR.
>> I think it's inappropriate to have an absolute list like the spec has 
>> now. Ideally I'd like to use the wording Bjoern suggested, but if we 
>> absolutely have to list mimetypes why not do something like:
>> If there is no content type, or the content type is one that the UA 
>> considers to be an XML type ... . At least the following types 
>> SHOULD[1] be considered XML types; application/xml, text/xml, text/xsl 
>> and any type ending in +xml.
>> [1] not sure if it should be a MUST or SHOULD requirement.
> It should be a MUST because:
> - We want test cases to cover it.
> - There's no sensible reason to let a UA to not treat any of the listed 
> types as XML if it supports XML at all, if at least some UAs do.
> I'm also not sure of the benefit of letting the UA treat arbitrary other 
> types as XML besides those listed. Modern XML MIME types should all be 
> following the +xml convention. And clearly for interoperability we want 
> it to be the case that the UA MUST NOT treat text/html or text/plain or 
> image/png as XML types. What types are there where it would be 
> acceptable for the UA to go either way?

Currently mozilla treat 'text/rdf' as XML in addition to that list, 
though I don't feel strongly about including that. Don't know how much 
stuff out there with that mimetype. I'll check with rdf people.

If we are making the list absolute, I feel weird about including things 
like 'text/xsl' and 'text/rdf' as neither of them are real mimetypes. Is 
there really a lot that would break if 'text/xsl' was not included?

/ Jonas
Received on Tuesday, 8 May 2007 22:32:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC