- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 8 Oct 2009 09:49:55 -0700
- 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