comments from Osmosoft on the File API

At Osmosoft, we took some time to collectively read the File API 
Editor's Working Draft 28 October 2009:

    http://dev.w3.org/2006/webapi/FileAPI/

Our interest in this specification stems from our contribution
to the open source product TiddlyWiki -- an example of a 
Single Page Application (SPA), a concept we presented to the 
W3C Devices Workshop in December 2008:

    http://tiddlywiki.com
    http://www.w3.org/2008/security-ws/papers/osmosoft.html

Overall we welcome the formalization of access to local files,
including binary data within a client-side Web application and
can envisage migrating a number of features currently implemented
using access to a file:// URI TiddlyWiki if and when it becomes
available in browser implementations.

During our review we have one overall disappointment: whilst the 
Use Cases describe saving local files programatically, the 
specification does not provide any write methods. 

We wondered if these were to be  provided in a later version 
or via extensions? --We now gather this is a topic of debate within 
the WG and with the DAP WG.

We do have some very minor comments which we hope 
will help move the specification forward.

* Status of this Document
The Status section states this is the work of the Web Applications 
Working Group, but we were unable to find mention of the spec from 
the Working Group page, or in the list of chartered deliverables:

    http://www.w3.org/2008/webapps/ 
    http://www.w3.org/2008/webapps/charter/webapps-deliverables.html 

What is the current expectation of the status of the published 
document? Is it on the Recommendation track, or will it be 
published as a Working Group Note?

What is the relationship between the File API document and 
the File Upload API listed on the historical Web API WG page?

    http://www.w3.org/2006/webapi/
    http://www.w3.org/TR/file-upload/

* Acknowledgements
Where is the original document from Robin Berjon? A link to the 
input document may help us better understand the context of this
specification.

* Processing Models
Much of the specification seems to be written in terms of 
pseudo-code steps. Whilst this follows the style of parts
of the HTML 5 specification, and simplifies cloning a working 
implementation, it can make it harder to read and more difficult
to write tests for than a series of assertions. I'd suggest
wherever possible, replacing the processing steps with a set of
inputs, observable changes of state and outputs, even if this
does make the specification more verbose.

* Conformance
The terminology used for conformance currently links within the document, 
rather than to HTML 5 specification.

We'd also suggest adopting the HTML 5 colours for terminology, 
internal and external references.

A a frag-id for each individual assertion, along with a table listing 
all of the assertions at the end of the document useful when building 
test suites.

* Normative references
Along with the authors, it would be useful to have an indication of the
current status of each of the documents referenced. Many seem to be
still at working draft.

HTH
Paul
--
http://blog.whatfettle.com
http://osmosoft.com

Received on Wednesday, 11 November 2009 12:30:41 UTC