W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

random notes on the XHR editorial notes

From: Robin Berjon <robin.berjon@expway.fr>
Date: Wed, 5 Apr 2006 21:49:15 +0200
Message-Id: <B1C090FB-61DE-4DA8-ACC1-A7C6CBE35C1F@expway.fr>
To: Public Web API <public-webapi@w3.org>

Hi,

here are a few thoughts on the editorial notes that are in the draft.

First: since editors seem to be liking ednotes, would folks see value  
in having ReSpec generate anchors for them so we could easily link to  
them?

 "What about non-ECMAScript implementations?"

I think Cameron's idea of having a createXHR() available to the  
languages that may need it could be useful indeed.

 "Need to define which IDL specification we are going to conform to,  
if any."

This came up on xml-dev, where OMG IDL was blamed for the fact that  
we have createElement() and createElementNS() in the DOM instead of  
just one (there may be other reasons). I am all for forgetting about  
OMG IDL, but I think we need to consider the following:

  - some folks generate Java interfaces from the IDLs. I think we're  
safe so long as we generate a binding from what we have (which is  
easy to add to ReSpec, I can do it)
  - some implementations (Mozilla?) seem to use OMG IDL. Would they  
be fine with something else, or with hacking the something else  
themselves, or if we generated something more kosher and let them do  
whatever workaround they do to get around it for stuff they already  
support?
  - the stuff that's in the interface definition should be formal to  
some point. If we don't use OMG IDL, it would be really best if we  
defined whatever it is we use. We can keep it simple, but we might  
not be able to dodge writing a Note describing it.

 "What if languages don't have functions? Perhaps this should be an  
EventListener?"

What DOM 3 Events does currently is that in the Javascript binding it  
make EventListener be a Function (and doesn't give it the handleEvent  
field, which is debatable but would work well here). I think we  
should consider this option.

 "What about HEAD requests?"

This is worth a test of what current implementations do. Assuming a  
void it would be best to go to 3 once (so that we're always  
guaranteeing that 3 is touched at least once for any complete  
request, it makes scripting with it simpler), and hop immediately to 4.

 "What about PUT and DELETE?"

We were fairly agreed that these should be supported at the f2f,  
unless there is a good reason not to (e.g. current implementations  
skip them). In fact our resolution was that (again, unless we bumped  
into something during testing) all methods should be allowed,  
including the DAV ones which would be very cool for some uses, for  
instance CMS UIs.

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/
Received on Wednesday, 5 April 2006 19:49:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:54 GMT