On Tue, 23 Oct 2012, Ted Hardie wrote: > On Tue, Oct 23, 2012 at 4:51 PM, Ian Hickson <ian@xxxxxxxx> wrote: > > Having multiple specs means an implementor has to refer to multiple > > specs to implement one algorithm, which is not a way to get > > interoperability. Bugs creep in much faster when implementors have to > > switch between specs just in the implementation of one algorithm. > > First, do you have data that supports this assertion? No. > Second, multiple folks in this conversation have asserted that the right > way to approach this is to have *two* algorithms. The first is "method > to get from string to URI" and the second is "Process URI". That would be inefficient, so isn't likely to be a solid implementation strategy in many environments. I don't see any reason to do it this way. > It also seems far more likely to me that bugs will creep in from > re-defining a known algorithm (the "process URI" bit from the pair > above) than from the separation of that from a different operation. That's what regression tests and review are for. Obviously if we rewrote the algorithms and introduced bugs and just left them as is, we'd be pretty awfully incompetent. Nobody is suggesting that the work will be done before we have reached a point where the new spec is as good or better than the existing specs. > If the results of the rewording would be different operations then, as I > have noted before, you really should use different terms and admit to > the fork. There's no desire to make the new spec incompatible with existing software. That would not be a useful spec. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'