W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

[XHR] LC comments from the XForms Working Group

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Fri, 13 Jun 2008 13:22:15 +0100
Message-ID: <ed77aa9f0806130522n6f082457vf3e1d205da48116d@mail.gmail.com>
To: public-webapps@w3.org
Cc: public-forms@w3.org


I've been asked by the XForms Working Group to send some last call
comments on the XHR draft.

We think the draft is well done, and will prove extremely useful. We
realise that the main intent of the draft is to document *what already
exists* by way of XHR implementation in browsers, and we think it does
this very well.

We're also quite pleased to note that the XHR object could be used in
other contexts, and our only comments are that this should be made
clearer. We propose a couple of minor changes to facilitate this.

In section 2.1 (Dependencies), you have:

  "HTML 5

    This specification depends on HTML 5 for defining the Window
object and finding
    the character encoding of a text/html resource. A conforming user agent must
    support these features. [HTML5]"

This should be changed (or a note added) to stress that this
dependency on HTML 5 only applies if a user agent actually supports
the HTML 5 Window object. Section 4 makes this clearer, but the fact
that the dependency on Window is *conditional* in section 4 needs to
be reflected in section 2.1.

In section 4 we have:

  "Objects implementing the Window interface must provide an XMLHttpRequest()
  constructor. [HTML5]

  In ECMAScript this can be used as follows:

  var client = new XMLHttpRequest();

  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). The pointer can become "null" if the object is

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

Although an implementation need not support Window--as outlined in the
first paragraph quoted--it does need to provide a connection between
the XHR object and a Document object. If it doesn't, then steps 6 and
11 of the open() method will not work correctly:

  6. If stored url is a relative reference resolve it using the
current value of the
  baseURI attribute of the Document pointer. If this fails raise a SYNTAX_ERR
  exception and terminate these steps.


  11. If stored url is not of the same-origin as the origin of the
Document pointer the
  user agent should raise a SECURITY_ERR exception and terminate these steps.

In both situations Document is *required*, so a conforming
implementation needs to provide one somehow.

The spec already leaves room for an implementation to provide this
'somehow', in the note that was quoted above:

  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.

But as currently worded, it relates to implementing Window and
Document behaviour "in any way they desire", rather than saying that
the provision of the 'Document pointer' can be achieved "in any way
they desire". Something along the following lines needs to be added:

  In particular, note that a conforming user agent only needs to
provide a value for
  the Document pointer, to allow for the correct functioning of steps
6 and 11 in the
  open() method.

(Or 'associated Document object'...or whatever is the preferred term.)

We feel that although these are minor changes, they would clarify for
implementers that the XHR object is usable in a broad range of



Mark Birbeck, webBackplane



webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Friday, 13 June 2008 12:22:51 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:09 UTC