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
