Re: Spec organizations and prioritization

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