Robin,
ArrayBuffers, and affiliated "Typed Array" views of data, are specified in a
working draft as a part of the WebGL work [1]. This work has been proposed to ECMA's
TC-39 WG as well. We intend to implement some of this in the Firefox 4 timeframe, and
have reason to believe other browsers will as well. I have thus cited the work as a
normative reference [1]
The TA draft doesn't include any copyright or licensing information. I take it
that the plan is to eventually have it at some stable URL accessible to all and
under an RF license?
Yes! Technical details are currently being hashed out on
[email protected] (the general ECMAScript discussion forum). I
expect it to have a more formal home, and of course, an RF license.
This is something we should fix in the short term as well, and I'll
raise this through the WebGL WG.
3. The renaming of the property to 'url' also suggests that we should cease to
consider an urn:uuid scheme.
I'm not sure that one follows from the other. The property's called 'url'
because that's what will be familiar to authors, but the magic string that goes
inside of it could still be a URN.
I agree that this is probably workable. (And thanks for commenting on
this issue :-) )
I don't really have a strong preference, but I believe that registering a URN
namespace (in the case where we would go for urn:file-data: instead of
urn:uuid:) is easier than registering a URI scheme. Since I have a strong
feeling that you'll be the one who'll end up doing that work, you might want to
take that into consideration ;-)
If we do go with a URN for the .url property, then I'm not sure what
benefit is gained from registering a new URN namespace (since we could
use urn:uuid:). One advantage of using urn:uuid was that the "new
technology" overhead was low. At the moment, I'm torn on this, but I'll
note that implementations are proceeding with what looks like a new
scheme (or at least what could be a new URN namespace).
Again, implementor feedback is welcome, but the point you make below is
what I think is true for other implementations (but not necessarily
Firefox):
Implementation-wise I can see how some might have the plumbing in place to
dispatch depending on URI schemes but not for URNs.
+1 (again, not true of Firefox, where it doesn't really make a difference).
Unless someone has a strong feeling (i.e. not bikeshedding) on this I would
suggest closing this issue and leaving it up to the editor.
Thanks :)
Is using a subset of HTTP response codes acceptable practice, or should we
forgo response codes in this specification?
That seems to risk getting you close to specifying the behaviour of file: :) The problem
of forgoing response codes is that it breaks a number of libraries. For instance (IIRC),
the following never calls you back: $.get("file:///foo.html", cb) because
jQuery never detects a successful fetch of the file (even though the underlying XHR may
have succeeded) — the same would apply to filedata:. A subset of HTTP has the downside
that it should ideally be consistent. Maybe that can be done with brutality? Reject any
method other than GET with a 405, return 400 for any header the author sets that involves
conditional or negotiated responses, 404 if the URI doesn't exist, and 200 if it does.
Only set the response headers that match information already exposed on the Blob.
All good suggestions. I think the subset can be determined by
researching what XHR is used for within file:///, which is how I'm
currently proceeding. I agree with GET + strict subset of responses.
Information set on Blob is likely to only include Content-Type (for now).
Editorial note
Issue: if it is determined that the type attribute is one of text/html,
text/xml, or application/xml then the specification should allow HTML5 [HTML5]
parsing (creation of Document) or XML parsing specified in XML specifications.
Should there be normative text for this?
I'm not sure I follow the intent exactly here, do you mean adding something
like readAsDocument()? That sounds nice (and ought to work for +xml types as
well) but is it essential enough?
User-agents do type determination on files, and if it is discovered that
the file in question (or Blob) is an HTML file or an XML file, we should
probably follow those rules. I don't think we need a readAsDocument( ),
since readAsText, which gives you a string, might be enough.
-- A*
