Re: [File API] feedback on August 1/5 draft

Latest draft is: 
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html

Anne van Kesteren wrote:
> Thanks for the update to the draft! Below some feedback:
>
> In the table of contents the link to the filedata URL scheme is broken.
>   
Fixed.
>
> The Web IDL syntax needs to be updated. E.g. FileList can be simply described as
>
>   typedef sequence<any> FileList;
>
>   
Done
> I have not received any feedback on my comments as to why getAsDataURL is actually needed. I still think it should be dropped.
>
>   
The rationale submitted by Jonas seems to be sufficient. [1]
> I think getAsURL() should become an attribute instead. E.g.
>
>   readonly attribute DOMString localURL;
>
> Since it is just a reference there is no need this needs to be asynchronous and there is also no need for it to be method.
>
>   
Done.
> The constants of FileError need to be actually placed on the FileError object and renumbered as to make sense. They are not DOM exceptions so it does not make sense to align with that in any way.
>
>   
They are placed on the FileError object now, but have not been 
renumbered.  Additionally, slice is now spec'd to throw a FileException.

I'm not tightly wed to keeping the numbers the same as DOMException, but 
honestly reusing SECURITY_ERR and NOT_FOUND_ERR from DOMException seems 
desirable.  SECURITY_ERR is used by XHR as well, so keeping these 
consistent (since File API will probably used in conjunction with XHR) 
also seems desirable.  I also agree that simply using a meaningful 
constant name is also useful, but kept the numbers the same for consistency.

Aside from numbering, I don't think there's a big difference between 
FileError / FileException and SQLError/SQLException (or MediaError, 
etc.).  Do you feel very strongly about renumbering?
> The filedata URI scheme should allow the use of fragment identifiers on the resource. Also, I think we should drop the // from the scheme. I do not see why that is needed here.
>   
I've dropped the "//", but haven't spec'd the scheme to allow fragment 
identifiers on the resource.  Could give me a use case?
>
> Last time I also made comments regarding the details of discovering the encoding of a file etc. Those still seem to apply.
>
>   
Anne, I thought that even my past draft addressed most of them, with one 
exception!  These comments seem to have been:

 * I assume it is meant that if the encoding parameter is not provided 
UTF-8 is used for decoding the file. I think that should be made more clear.

--> It is clear, but only iff. implementations cannot determine a 
decoding to use.  You've said that the "left to implementations" part is 
unacceptable, but that actually seems desirable, and they MUST use UTF-8 
if they cannot determine the decoding.  Since they must fall back on 
UTF-8, is this not sufficient?

 * However, wouldn't it be better to use e.g. XML rules for XML files 
and HTML rules for HTML files?

--> The File interface has a mediaType attribute.  I reasoned that by 
determining the mediaType, callers can determine which rules to use, or 
at least determine whether they can use the filedata: scheme to surface 
the content, etc.  Would you like me to make explicit statements about 
XML/HTML, or is this sufficient?

 * It would also make sense to observe any BOM the file might have and 
maybe information provided by the platform? Rules similar to how 
responseText for XMLHttpRequest is computed could be used here I think.

--> I specify that user agents can make a determination, and assumed 
this as the case.  I can make this more explicit in a subsequent draft, 
and look at responseText rules.  This is probably the only thing not 
fully addressed, unless you have further nits on how I've addressed your 
other nits.

 * It should also define how to deal with bytes it cannot decode with 
the given encoding. E.g. replace them with U+FFFD as done elsewhere in 
the "Platform".

--> Done.

-- A*
[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0511.html

Received on Wednesday, 12 August 2009 15:14:41 UTC