Re: [FileAPI] File.mediaType
On Tue, 17 Nov 2009 22:26:20 +0100, Arun Ranganathan wrote: 1. I agree that name consistency is desirable, so mediaType is now simply type. I'll point out that
Re: [FileAPI] File.mediaType
Marcin Hanclik wrote: What if the @type is derived from unverified metadata and the UA relies on the underlying OS (assuming the file is local) ? Does it mean that the UAs should always sniff to ensure that the @type is correct? Should we apply the procedure similar to the one from P&C that derives the @type from the file name [4]? [4] http://dev.w3.org/2006/waf/widgets/Overview.html#rule-for-identifying-the-media-type-of-a User agents can use a variety of different steps to determine the type of a file. For instance: https://developer.mozilla.org/En/How_Mozilla_determines_MIME_Types#ExternalHelperAppService I am not sure it is necessary to specify a common approach here, but it is useful to specify what happens when the user agent cannot determine the type. I've made the following changes: 1. I agree that name consistency is desirable, so mediaType is now simply type. I'll point out that
Re: [FileAPI] File.mediaType
>>> Returning "application/octet-stream" rather than null also seems better >>> if the type is not known. That way you do not have to type check. Other >>> parts of the platform also handle "application/octet-stream" as unknown. >> >> It's been pointed out that user agents type check on files. If the >> mediaType is not known, users invoking the attribute can't do anything >> useful with it, so null is better. What are the use cases for using >> application/octet-stream instead? > > I guess not known might be useful. Can't we just make it the empty string > then? I don't really see the need to return something other than a > DOMString. I agree an empty string is just as good here. / Jonas
RE: [FileAPI] File.mediaType
>>What if the @type is derived from unverified metadata and the UA relies on >>the underlying OS (assuming the file is local) ? >>Does it mean that the UAs should always sniff to ensure that the @type is >>correct? Should we apply the procedure similar to the one from P&C that derives the @type from the file name [4]? [4] http://dev.w3.org/2006/waf/widgets/Overview.html#rule-for-identifying-the-media-type-of-a Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcin Hanclik Sent: Monday, November 16, 2009 1:30 PM To: Anne van Kesteren; a...@mozilla.com Cc: WebApps WG Subject: RE: [FileAPI] File.mediaType Hi, >>The current text says the string is ASCII-encoded. That's not true. It's >>in 16bit code points like any other DOMString. +1 The full definition stems from [RFC2045.5.1] and says that content type is not only ASCII, but it also removes some of the ASCII characters from the allowed ones. The IANA registration [RFC4288.4.2] procedure requires the following syntax: type-name = reg-name subtype-name = reg-name reg-name = 1*127reg-name-chars reg-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "." / "+" / "-" / "^" / "_" "mediaType The ASCII-encoded string in lower case representing the media type of the file, expressed as an RFC2046 MIME type [RFC2046]." Although IANA registered types are all lower case, the subtypes are not (not sure whether we want to mandate the toLower() normalization in the FileReader API). Therefore I suggest referring to IANA and RFC4288. >>> "mediaType" is more specific than "type". >> >>But it is less consistent with
RE: [FileAPI] File.mediaType
Hi, >>The current text says the string is ASCII-encoded. That's not true. It's >>in 16bit code points like any other DOMString. +1 The full definition stems from [RFC2045.5.1] and says that content type is not only ASCII, but it also removes some of the ASCII characters from the allowed ones. The IANA registration [RFC4288.4.2] procedure requires the following syntax: type-name = reg-name subtype-name = reg-name reg-name = 1*127reg-name-chars reg-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "." / "+" / "-" / "^" / "_" "mediaType The ASCII-encoded string in lower case representing the media type of the file, expressed as an RFC2046 MIME type [RFC2046]." Although IANA registered types are all lower case, the subtypes are not (not sure whether we want to mandate the toLower() normalization in the FileReader API). Therefore I suggest referring to IANA and RFC4288. >>> "mediaType" is more specific than "type". >> >>But it is less consistent with
Re: [FileAPI] File.mediaType
On Fri, 13 Nov 2009 11:36:33 +0100, Arun Ranganathan wrote: Anne van Kesteren wrote: This should be a bit more exact as to how the mediaType is returned. I would prefer ASCII-lowercase. Done. The current text says the string is ASCII-encoded. That's not true. It's in 16bit code points like any other DOMString. Returning "application/octet-stream" rather than null also seems better if the type is not known. That way you do not have to type check. Other parts of the platform also handle "application/octet-stream" as unknown. It's been pointed out that user agents type check on files. If the mediaType is not known, users invoking the attribute can't do anything useful with it, so null is better. What are the use cases for using application/octet-stream instead? I guess not known might be useful. Can't we just make it the empty string then? I don't really see the need to return something other than a DOMString. Also, maybe we should just call this type? File.type seems unambiguous enough. "mediaType" is more specific than "type". But it is less consistent with
Re: [FileAPI] File.mediaType
Anne van Kesteren wrote: This should be a bit more exact as to how the mediaType is returned. I would prefer ASCII-lowercase. Done. Returning "application/octet-stream" rather than null also seems better if the type is not known. That way you do not have to type check. Other parts of the platform also handle "application/octet-stream" as unknown. It's been pointed out that user agents type check on files. If the mediaType is not known, users invoking the attribute can't do anything useful with it, so null is better. What are the use cases for using application/octet-stream instead? Also, maybe we should just call this type? File.type seems unambiguous enough. "mediaType" is more specific than "type". -- A*
Re: [FileAPI] File.mediaType
On 11/10/09 11:58 AM, Anne van Kesteren wrote: True, can you ever get this situation when reading a file from disk? I'm not sure what you're asking... When loading a file from disk, the type is always unknown and has to be determined by the UA somehow, no? Sure, but there's also
Re: [FileAPI] File.mediaType
On Tue, 10 Nov 2009 17:53:14 +0100, Boris Zbarsky wrote: On 11/10/09 8:33 PM, Anne van Kesteren wrote: This should be a bit more exact as to how the mediaType is returned. I would prefer ASCII-lowercase. Returning "application/octet-stream" rather than null also seems better if the type is not known. That way you do not have to type check. Other parts of the platform also handle "application/octet-stream" as unknown. That's not necessarily true. Most simply, loading a url in a browser doesn't treat application/octet-stream the same way it treats a missing Content-Type header. True, can you ever get this situation when reading a file from disk? Also, maybe we should just call this type? File.type seems unambiguous enough. It seems that many people think of "JPG" or "PNG" or "HTML" etc as the "file type". Witness all the dialog in various software that talk about "PNG files" and such. Sure, but there's also
Re: [FileAPI] File.mediaType
On 11/10/09 8:33 PM, Anne van Kesteren wrote: This should be a bit more exact as to how the mediaType is returned. I would prefer ASCII-lowercase. Returning "application/octet-stream" rather than null also seems better if the type is not known. That way you do not have to type check. Other parts of the platform also handle "application/octet-stream" as unknown. That's not necessarily true. Most simply, loading a url in a browser doesn't treat application/octet-stream the same way it treats a missing Content-Type header. Also, maybe we should just call this type? File.type seems unambiguous enough. It seems that many people think of "JPG" or "PNG" or "HTML" etc as the "file type". Witness all the dialog in various software that talk about "PNG files" and such. -Boris
[FileAPI] File.mediaType
This should be a bit more exact as to how the mediaType is returned. I would prefer ASCII-lowercase. Returning "application/octet-stream" rather than null also seems better if the type is not known. That way you do not have to type check. Other parts of the platform also handle "application/octet-stream" as unknown. Also, maybe we should just call this type? File.type seems unambiguous enough. -- Anne van Kesteren http://annevankesteren.nl/
