Re: [XHR] SVG WG LC comments

Dear SVG WG,

I noticed you e-mailed your comments to our new list. Thanks! (Despite  
this being contrary to the advice in the XMLHttpRequest Last Call draft I  
will still duly process them...)


On Wed, 11 Jun 2008 12:00:51 +0200, Erik Dahlström <ed@opera.com> wrote:
>  │ 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.

Since not everything is fully detailed yet in HTML5 this would be an  
ongoing process that I rather not do. Also, it should be quite obvious  
that XMLHttpRequest does not depend on database storage.


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

Since I've found the links in HTML5 to not always be stable I've not done  
this for now. However, one search on the frontpage of  
http://www.w3.org/TR/html5/ will give you the results you need so this  
doesn't seem too important.


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

The specification defines various terms throughout the specification. Only  
terms that didn't really fit anywhere else are in 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.

Actually, the overhead that Window has, such as browsing contexts, origin,  
etc. is vitally important to XMLHttpRequest. Especially when it comes to  
URI resolution and security.


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

A lot of prose throughout the specification is an implementation detail.  
For instance, the "XML response entity body" definition, the "send()  
flag", the concept of "author request headers", etc. It doesn't seem  
useful to flag these all given that there's no direct confusion.


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

It's the concept "null". It doesn't really matter whether it's a string,  
the value, or the empty string. (The value null is clearly marked as such  
throughout the specification.)


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

Once someone defines garbage collection in sufficient detail we might be  
able to do that.


>  │ 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?

Clarified.


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

Done.


> Consider adding a comma before “et cetera” in step 3 of the XML response  
> entity body algorithm.

Done.


> 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/

Done.


> 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).

This seems like a comment that should be directed at the HTML WG:

   public-html-comments@w3.org


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

I dropped that paragraph earlier today.


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

The constant _value_ is not in line. The one for SECURITY_ERR is 18, the  
others are 101 and 102.

Kind regards,


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 12 June 2008 13:15:06 UTC