Re: Answer to Ian Hickson: Formal vs prose language normativity

+1 Hixie is right; the group is wrong.

Unless the group is comfortable that the tiebreaker rule reflects the
actual preponderance of latent errors in the work, a tie-breaker rule
is dangerous. The only interoperation-safe thing for implementers to
do given an arbitrary tie-breaker rule is to work around the likely
interoperation-failure of the feature that is the subject of the
conflict by including redundant measures that afford comparable
functionality by means not dependent on this feature. And if the QA
standards say there has to be a tie-breaker rule, the rule must be
assumed by implementers to be arbitrary; and the results of relying on
specification knowledge that depends on the tie-breaker rule to be
deterministic to be capricious.

Tiebreaker rules are piety in the sky. Implementers will follow the
formalism or the prose at random no matter what the spec says about
tie-breaker rules. In other words, the tie-breaker rule in the spec
induces a false sense of security or CYA for the spec writers but is
the same old failure to accomplish mission in terms of ensuring
interoperation as without the tie-breaker rule in the spec.

Al

At 1:17 AM +0000 5/16/05, Ian Hickson wrote:
>On Fri, 13 May 2005, Karl Dubost wrote:
>>
>>  We do not necessary fully agree with your comments but we do understand
>>  your concerns. We came with the conclusion that it would be bad for
>>  developers if they can't move forward so we decided to keep our stance
>>  on having a rule to move forward in case of conflicts.
>
>I don't understand that.
>
>What if the prose contradicts something else in the prose?
>
>Why is that case different than if the prose contradicts something in the
>formal language?
>
>In fact, the fact that developers would be blocked when the prose
>contradicts the formal language is a *good thing*. If one is arbitrarily
>picked as the one they must follow, there is a 50% chance that they will
>invest time and effort into implementing the wrong one, possibly without
>even raising it as an issue (after all, "the spec is clear"). Then when
>the error is fixed, there is a 50% chance that they will have to rewrite
>their implementation -- and a high probability, in practice, that they
>will not, leading to conflicting implementations and bad interoperability.
>
>This is already seen in cases where specs are vague -- implementors shrug,
>decide on what they think is best, and implement that, without contacting
>the working groups. Anything that can be done to discourage this should,
>in my opinion.
>
>As it currently stands, I would not be able to ever write a specification
>that included normative formal language and was compliant with these
>requirements, as I could not see any way to pick which should be the
>"default" when they conflict.
>
>
>>  BUT we will add the prose of Al Gilman to the text and we will make
>>  extra warnings.
>>
>>  If a conflict is identified in a specification, the WG ***has to
>>  publish*** an errata and we will emphasize that by a link to the Process
>>  Documents which has already such a request.
>
>If the working group still disagrees with my comment, and still wants to
>encourage spec authors to state an (arbitrary) conflict resolution
>mechanism, then I would like to see it explained why conflicts between
>prose and formal-language parts of the spec require such conflict
>resolution while conflicts between two different prose parts of the
>specification do not.
>
>Cheers,
>--
>Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 16 May 2005 16:02:31 UTC