W3C home > Mailing lists > Public > public-xg-app-backplane@w3.org > June 2008

Action item to comment on XMLHttpRequest

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Wed, 4 Jun 2008 10:35:51 +0100
Message-ID: <ed77aa9f0806040235m27507bd1pf9cd61e15f9d58ae@mail.gmail.com>
To: www-forms@w3.org
Cc: public-xg-app-backplane@w3.org

Hello all,

I have an action item to review Anne's draft of the XMLHttpRequest
object. I'm also CC'ing this to the Backplane XG, since I think it is
many ways more relevant to their work.

GENERAL

In general the whole thing is a good idea. XHR has obviously been
around for a while now, and has been implemented in many different
ways. Producing a standard is definitely a good idea.

And although my guess is that the draft only aims to ratify what
already exists, rather than adding new features, I think it would
still be beneficial to XForms and the backplane if some of our core
submission processing was defined in terms of this more fundamental
unit, even if it doesn't yet do everything that we might want.

So my comments are *not* along the lines of 'wouldn't it be great if
it did this', because I am assuming additional features are for a
subsequent release. Instead I'm focusing on where the object fits in
to a wider picture, and in particular I'm concerned with issues such
as how an object is created, how it relates to other objects, and so
on.


MINIMAL

I think it would be useful to allow implementations to support a
'minimal' object, that would still be useful in many different
environments. The kind of thing I'm thinking of here is that there is
no need to make support for methods of HEAD and OPTIONS a 'MUST' in a
minimal implementation, and there doesn't seem to be a need to insist
on the presence of a DOM.

Of course, in documenting the current state of affairs with respect to
implementations, these methods will almost certainly exist; but whilst
I agree that it's ok to create a spec that doesn't add more than
already exists 'in the wild', it is still usefull for the spec to
allow future implementations to use less.

For example, it's possible to imagine a JSON-only use of XHR, that
needs a few basic methods, and retrieves non-XML data.


CONSTRUCTION

Section 2.1 seems to imply that the Window object is a required part
of the spec, but in section 4 it seems that the relationship is "*if*
you support Window you MUST support the XHR constructor", but not "you
MUST support Window".

If this is the case (and I think it should be), then I'd like to see
this drawn out a bit more. I think it would be incredibly useful if
the draft defined the core XHR object (obviously a kind of 'version
1.0' of XHR), but then leave open how different environments
incorporate that object. As I said, I realise that this spec is about
documenting what already exists, so we shouldn't be proposing new
events, etc.; but I think it is a small consideration to allow the
object as defined (and consequently all future versions of this
object) to be 'floating'.

To illustrate the point, XHR could be used in a JavaScript-only
environment (i.e., one outside of a browser) which does not have a
Window object, but still has a top-level context; so the constructor
might still exist, but not on the Window object.

Another example would be to use the DOM 3 Implementation technique to
obtain objects, or to add a createXHR() method to Document (like
document.createEvent()).


DEPENDENCIES

I've mentioned that XHR doesn't appear to need to *depend* on the
Window object, and I'd also add that the situation is the same for
HTML 5; there shouldn't be a dependency on HTML 5 since the object
should be usable in many contexts. (And in fact, there doesn't seem to
be any need for the dependency.)


BASEURI AND SECURITY

Since it would be possible to create an XHR object that is separate
from a Document object, then the wording of 'base' and security
behaviour would need to be slightly modified. For example, if the XHR
object is operating independently of a Document object, then it would
need a 'baseURI' value setting so that relative paths can be resolved,
and cross-domain concerns can be honoured.


CONCLUSION

Even though there are many features that we'd no doubt like to see in
an XHR object, this first version is fine, and gets the ball rolling.
Even in this form (documenting the current state of affairs) it
provides a useful foundation for both the XForms and backplane
submission work. In my view, it would be good for us to start
incorporating this document into our thinking.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Wednesday, 4 June 2008 09:36:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 4 June 2008 09:36:27 GMT