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

Re: [XMLHttpRequest] update from the editor

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 8 May 2007 15:16:29 -0700
Message-Id: <CD2D18F8-5A3E-444A-A1BE-0D0D03FA8322@apple.com>
Cc: Anne van Kesteren <annevk@opera.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, "Web API WG (public)" <public-webapi@w3.org>
To: Jonas Sicking <jonas@sicking.cc>

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?

Received on Tuesday, 8 May 2007 22:16:45 UTC

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