W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: File API commens

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 8 Oct 2009 09:49:55 -0700
Message-ID: <63df84f0910080949k18587929va7612b4deb6f536f@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>, Larry Masinter <masinter@adobe.com>
Cc: public-webapps@w3.org, arun@mozilla.com
Leaving some of the questions for arun

> - wouldn't FileStatus be a better name than FileError, given that it can
> also contain a success code?

Actually, we should probably follow HTMLs lead here and design this
like the HTMLMediaElement.error property. So make it only contain
error codes.

> - why would a Euro sign be represented as code 128 in a binary string?
> (don't tell me because of Windows character encodings :-)

Indeed, this looks wrong. In general I think it's a bad idea to
describe what any particular character represents, as you really
shouldn't think about this in terms of characters. Instead it'd be
better to say that U0080 represents 128, and U0081 represents 129, and
never mention what "a" or any other character maps to.

> - mediaType: can this contain parameters? An RFC link that provides an ABNF
> would be useful here (for instance,
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.7>)

Good question. I suppose if the OS is able to store parameters for the
media type for a file then that's possible.

> - why is a new URI scheme needed? Can't you just use urn:uuid?

I think we'd really like to avoid creating a new scheme if we could
reuse an existing one. I know Arun was looking for an existing scheme,
but not sure if he looked at the 'urn' scheme.

Would it need to be urn:somename:uuid though? like urn:fileid:uuid?

Also, Anne pointed out that we probably want fragment identifiers to
work in whatever URI is returned. Would that be possible if we use
'urn'? If I'm reading rfc2141 right, it seems to say it's undefined.

/ Jonas
Received on Thursday, 8 October 2009 16:50:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC