RE: [chairs] New rule on which document wins when there is ambiguity

[Matthew Dovey <m.dovey@jisc.ac.uk>]

> In summary: the notion of precedence introduced by the word "prevails"
> was NOT, as I recall, intended to address the matter of (apparent discrepancy
> and) highest authority in cases where (e.g.,):
> 
> a) an assertion in prose (embodied in the main prose document
>     which is part of a specification) conflicts, or apparently
>     conflicts with an assertion based upon declarations in
>     a W3C XML schema file, RNG schema, DTD, Schematron schema, or
>     other machine-readable text with computer language definitions

<snip>

> c) one kind of formal language description embedded, as
>     display text, in the main prose document (part) of a
>     specification conflicts with assertions made by a
>     DIFFERENT kind of formal language description carried
>     in a plain text (machine-readable) file that is also part
>     of the specification [e.g., RNG schema in the prose is in conflict
>     with a separate W3C XML Schema file definition]
> 
> RATHER, the "discrepancy" envisioned in the new TC Process document
> (sentence containing "the separate file prevails") and mentioned in Mary
> McRae's announcement [2] is simply a situation arising from human editing
> error and/or machine conversion error, where the TC's intent is to include
> the SAME machine-readable formal language definition text in BOTH:
> 
> [i]  separate plain-text file, for use mainly by machines [ii] the main prose
> specification document, as display text,
>       for use mainly by human readers
> 
> Viz., the intent was that the text characters be identical (modulo white space
> allowable for a particular formal language representation) in BOTH [i] and [ii],
> but it's discovered that by error, some textual difference has crept in, and it
> was undetected at publication time.

If the error is purely presentational, then I'm not convinced that there is a significant problem which warrants its own dedicated OASIS rule.  On the other hand if an error of the above form is not purely presentational, then it causes either the machine readable file to be syntactically incorrect for the machine parsers - although this should be detected and fixed by the sorts of tools Toby refered, or the two situations (a) and (c) above. When the error (however caused or overlooked) causes cases (a) and (c) above, then determining the corrective course of action involves weighing up the consequences to existing implementations if the error were fixed to be what was intended, against the consequences as regards the consequences on the internal consistency if the error is accommodated in the specification. That decision depends very much on the context and circumstances and can't be determined by a hard and fast generic rule.

Matthew