Re: QASG last call comments: Normative redundancy

* Ian Hickson wrote:
>"5 Good Practice E [...] make it clear when the English prose and the
>formal language overlaps which one should be held for true in case of
>discrepancy" -- I would recommend making them _both_ normative and not
>have one override the other. If prose and formal language are
>inconsistent, then an error has crept into the specification, and
>there is no guarentee that the error will be in the one that has been
>marked non-normative. Whenever there is an inconsistency, the working
>group should IMHO issue a (normative) errata to address the problem.

Suppose you want to restrict something to "#" followed by six hex digits
case-insensitively; the formal language can only express this by listing
all 113,379,904 values; this is typically not an option, so you choose
some approximation like a string with seven characters or just a string
with US-ASCII characters or whatever the formal language might offer.

Doing so would cause formal language and prose to be inconsistent and
there is no sane way to remove the conflict without prose that lets one
part override the other. Your proposal is thus paradoxical, you need to
violate it in order to implement it (you would need prose that states
this is a known inconsistency and the prose is normative, for example.)

Note that the good practise is not meant to provide an excuse to keep
such problems in the specification, but rather a conflict resolution
mechanism to avoid encountering such problems (you might not read the
overidden part at all) and such that you can resolve the conflict your-
self if you encounter it before the problem is fixed. This is typically
reasonable as the Working Group has good reasons to have more confidence
in some part of the specification than the other, especially if one part
is actually redundant (you might have all things in prose without any
dependency on the formal language).

Your proposal would basically only provide practical benefits if you
assume that such more serve (as they are not internally resolved)
inconsistencies make it more likely that people spot and report such
problems; I don't think this would be the case and it risks that there
are going to be less interoperable implementations as with your proposal
there would be more rules to choose from.

There is of course the risk that the "overridden" (or informative) part
is actually the intended one, but even if the inconsistency is spotted,
reported and informatively resolved, there is no gurantee that this
would help much (the response might come too late, other implementers
resolved the conflict differently, etc.)
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 19 January 2005 17:11:39 UTC