- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 20 Mar 2012 14:47:58 +0100
- To: Anne van Kesteren <annevk@opera.com>
- Cc: public-w3process <public-w3process@w3.org>
Le mardi 20 mars 2012 à 06:30 -0700, Anne van Kesteren a écrit : > On Tue, 20 Mar 2012 06:12:57 -0700, Dominique Hazael-Massieux <dom@w3.org> > wrote: > > Sure, but these edge cases clearly don't have such a big impact on > > interop that it prevented large-scale deployment; so I think it would > > have been better to ship a spec leaving the edge cases undefined (which > > is in any case the situation we're in now), rather than trying to tackle > > all the edge cases and never get the RF commitments. > > 1. That's make work. It isn't, if you agree that an important part of our goal is the get RF commitments; if you don't, then indeed. > 2. That would not have helped with all the bug > reports browser vendors have been getting over the past years with regards > to XMLHttpRequest as the specification would not have given an answer on > how to proceed. Indeed, it wouldn't have helped; that's something that XMLHttpRequest Level 2 would have done. Also, efforts would have converged on XMLHttpRequest Level 2 more quickly. > Putting a few words on a paper with a W3C sticker on it does not really > make a standard. That's not what I'm suggesting; I'm suggesting that in this case, we have a widely interoperable feature: we should document what's interoperable, make it go through our various quality checks, document what is not interoperable as well, and get the RF Commitments. Then we can start a new cycle focusing on fixing what's not interoperable (and adding new features that are needed). > In the HTML4-era that was acceptable, now it's not. You're preaching to the choir, really. To be very explicit, I think the work you and Hixie have done in this space is remarkable and absolutely needed. But not finishing the process to get RF commitments creates a lot of jeopardies for a lot of the involved actors. Now, arguably we need to reduce the work needed to get the RF commitments (and there is a lot of room for that, as I want to develop in a separate message), and this may mean changing the patent policy in the future. But given the amount of time and work that will be needed before we change the patent policy, it sounds more than risky to wait to get the RF commitments until the PP is modified. So for the foreseeable future, the PP is an unavoidable constraint. To get to the crux of why we need a Rec to get RF commitments, patent owners don't want to give unrevokable RF commitments for things that are still in flux; so we should document what's not in flux [and we know it isn't, because it is implemented and interoperable] and get the RF commitments. > If > you are interested in that maybe you should just go ahead and push > http://en.wikipedia.org/wiki/XMLHttpRequest through the Recommendation > track. Are you asserting that this page is a good documentation of the existing interoperability among implementations? Dom
Received on Tuesday, 20 March 2012 13:48:27 UTC