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

Re: random notes on the XHR editorial notes

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 06 Apr 2006 11:24:13 +0200
To: "Web APIs WG (public)" <public-webapi@w3.org>
Message-ID: <op.s7kxqnvj64w2qv@id-c0020.oslo.opera.com>

On Wed, 05 Apr 2006 21:49:15 +0200, Robin Berjon <robin.berjon@expway.fr>  
> 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?

If links to them have the "This verison" URL as base I guess that's fine...

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

I raised an issue on this.

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

This seems fine. Although I'm not sure who's going to write that Note...

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

I raised an issue on this.

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

Yeah something like that. I'll try to add some text to that affect  

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

That's fine. I guess we need some text for them though. How they are  
handled and all that.

Anne van Kesteren
Received on Thursday, 6 April 2006 09:24:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC