[XHR] SVG WG LC comments

Hello webapps wg,

These are LC comments on the XMLHttpRequest specification from the SVG WG.

This is the version of the spec that was reviewed:
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?
This would help implementations that wish to implement only the XMLHttpRequest interface, without for example support for clientside databases and various other things in the Window object.


2.2 Terminology
---------------

 │ The terms origin and event handler DOM attribute are defined by the HTML 5 specification. [HTML5]

Please provide links to the definitions of the terms 'origin' and 'event handler DOM attribute' in the HTML5 spec.


4. The XMLHttpRequest Object
----------------------------

 │ This is the Document pointer.

If 'pointer' or 'Document pointer' is a term (which the styling seems to indicate) then please add it to section 2.2.


 │ 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 DONE state has an associated error flag which can be either "true" or "false". │ The initial value of the error flag is "false".

Please consider adding a sentence saying that the "error flag" is not exposed through the XMLHttpRequest interface, it's an implementation (and specification) detail.


 │ If the response entity body is "null" return the empty string and terminate these steps.

Is that the string "null", or the value null, or perhaps even the empty string? This comment applies throughout the spec. Please define null as a term, and use that instead, with the same visual style as other terms (that is: without the quote-marks and in bold).


 │ 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].


Consider adding 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
looks fine (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.

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Wednesday, 11 June 2008 10:01:35 UTC