Short review of XHR

As requested, below are some comments on XHR that you (Erik/Doug) may
wish to incorporate into our group’s reply.  Note that none of these are
particularly SVG-centric, though.  The version I reviewed is:
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?rev=1.192



2.1 Dependencies

  │ A conforming user agent must support at least the subset of the
  │ functionality defined in HTML 5 that this specification relies upon,
  │ such as the Window object and serializing a Document object. [HTML5]

Could you mention here exactly what parts of HTML 5 are depended upon?
For example, I’m not going to implement the whole of the Window
interface in Batik (yet) for XMLHttpRequest support (including client-
side databases and various other things).


2.2 Terminology

It might be nice to have links directly to the definitions of these
terms in HTML 5, here.


4. The XMLHttpRequest Object

  │ When the XMLHttpRequest() constructor is invoked a persistent
  │ pointer to the associated Document object is stored on the newly
  │ created object. This is the Document pointer. The associated
  │ Document object is the one returned by the document attribute from
  │ the object on which the XMLHttpRequest() constructor was invoked
  │ (a Window object).

Since the document attribute is actually from the AbstractView
interface, I wonder if there’s a neat way you could reference that
interface instead of Window for this, to avoid all of the extra overhead
that Window has.  How about replacing:

  Objects implementing the Window interface must provide an
  XMLHttpRequest() constructor.

with:

  Objects implementing the AbstractView interface that is the default
  view of the document must provide an XMLHttpRequest() constructor.

and in:

  The associated Document object is the one returned by the document
  attribute from the object on which the XMLHttpRequest() constructor
  was invoked (a Window object).

do s/a Window/an AbstractView/, and in:

  If iframe is a Window object, client will have a pointer to
  iframe.document in the following example:

do s/a Window object/an AbstractView object which represents the default
view of the document/.


  │ The pointer can become "null" if the object is destroyed.

If the Document object is destroyed?  So the document pointer is a
WeakReference, in Java-talk?  Maybe this should be made more explicit.


  │ Note: As per the conformance criteria implementations are free to
  │ implement this in any way they desire as long as the end results
  │ are identical to those given by the English prose.

Free to implement what, the specification?  The XHR interface?  That
above paragraph about the document pointer?


Step 3 of the text response entity body algorithm should probably have a
reference [XML].


I’d put a comma before “et cetera” in step 3 of the XML response entity
body algorithm.


In the description of the open() method:

  │ 6. Convert stored url to a URI as defined by section 3.1 of RFC
  │ 3987. If this fails (the ToASCII operation for instance), raise a
  │ SYNTAX_ERR exception and terminate these steps.

s/operation/operation fails/


In the send() algorithm:

  │ ↪ data is a Document
  │
  │     Let data be data.innerHTML as defined by section 2.5 of HTML 5.
  │     Encode it using data.inputEncoding or UTF-8 if
  │     data.inputEncoding is null. Re-raise any exceptions the
  │     data.innerHTML getter algorithm raises. [HTML5]

The innerHTML getter algorithm requires that an explicit xmlns=""
attribute is present for elements in no namespace, instead of relying on
the fact that if there is no xmlns= attribute one of the
ancestor-or-self::* elements that it defaults to being in no namespace.
This means, for example, that the following:

  var doc = document.implementation.createDocument(null, "test", null);
  var r = new XMLHttpRequest();
  r.open("somewhere");
  r.send(doc);

would send the string '<test xmlns=""/>' (or something equivalent, but
the xmlns="" would have to be in there).  Do (m)any existing XHR
implementations serialise the document in this way?  Is there any
benefit from requiring this?  The rest of the innerHTML getter algorithm
I’m happy with (where it deals with unserialisable nodes).


4.1 Events for the XMLHttpRequest Object

  │ This section describes the various events that can be dispatched on
  │ objects implementing the XMLHttpRequest interface. For this version
  │ of the specification only one event is defined. 

Why say “various events” when there is only one?


4.2 Exceptions for the XMLHttpRequest Object

  │ Note: The SECURITY_ERR exception is expected to be eventually folded
  │ into an update of the the DOM Level 3 Core specification with an
  │ equivalent definition and identical constant value. Until that
  │ happens it is defined here to guide implementors. (This is also the
  │ reason the constant value is not in line with the other exceptions.) 

What do you mean be “not in line” here?  That it is not in the same grey
box with the IDL for those constants?  If so, well, then it is in line.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Wednesday, 4 June 2008 06:47:24 UTC