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