On Tue, 23 Oct 2012, Ted Hardie wrote:
On Tue, Oct 23, 2012 at 4:51 PM, Ian Hickson <ian(_at_)hixie(_dot_)ch> 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. `._.-(,_..'--(,_..'`-.;.'