Re: File API commens

Julian Reschke wrote:
> Hi,
>
> here are a few comments after a superficial read of 
> <http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html>:
>
> - wouldn't FileStatus be a better name than FileError, given that it 
> can also contain a success code?
I'm in the process of updating the spec. to reflect the event-based 
model [1].  I agree that we shouldn't mix codes here, and I intend to 
only have 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 :-)
This is a mistake; noted with thanks :)
>
> - 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>)
I refer to RFC 2046 -- is this insufficient?  If so, I'll gladly provide 
an ABNF.
>
>
> - don't say URL when you mean "URI"
As I update the spec., I'll resist this erratic impulse.
>
> - RFC 2234 (ABNF) has been updated multiple times, it's now RFC 5234
>
Noted with thanks.
> - why is a new URI scheme needed? Can't you just use urn:uuid?
>
So I originally started off with urn:uuid, but switched to a scheme to 
make *explicit* the reference to file data (and distinct from file://).  
My reasoning was that a generic urn wasn't as explicit a reference as a 
scheme would be; moreover, we were defining a subset of HTTP as 
responses, so I felt that a scheme was more appropriate here.  I'm 
amenable to changing it back to the simpler urn: form if others disagree 
with this reasoning.  Perhaps making it a urn: has the added advantage 
of further reducing the possibility of confusion with the legacy file:// 
(which behaves inconsistently).  I'm interested in more feedback about 
this issue.
> - the definition of URLs and URIs is in RFC 3986, not RFC 1630.
>
Noted with thanks.
> BR, Julian
-- A*
[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html

Received on Thursday, 8 October 2009 18:13:11 UTC