Re: QASG last call comments: Normative redundancy

Le 20 janv. 2005, à 07:41, Ian Hickson a écrit :
> On Wed, 19 Jan 2005, Bjoern Hoehrmann wrote:
>>
>> 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
>
> That rather depends on the formal language. You could describe it in 
> some
> language as:
>
>    '#' [a-fA-F0-9]{6}

Which is not the case of many languages defined at W3C (Cf. DTD and 
Schema), but that's not indeed a complete excuse.


> In cases where the formal language is inadequate for describing the 
> actual
> requirements, then indeed, it should be informative.

Not necessary. Let's see that a bit further. Often, not necessary all 
the time, but often ;), there is this case:

     1          2
+----------+-------+
| Formal   | Spec  | A
| Language | Prose |
+----------| -  -  |
            |       |
            |       | B
            |       |
            |       |
            +-------+

As in we can define a lot more with the Spec prose than inside the own 
limitations of the formal language.
	If (Formal Language) == (Spec Prose)
		then (Formal Language) is the only normative version.
	If (Formal Language) isaSubsetOf (Spec Prose)
		then only on the common part the (Formal Language) is the normative 
version.

We all agree, there should never be conflicts between the two… though 
we all agree that bad things happen sometimes. :) So as Björn said, the 
Good Practice is how to avoid problems more than creating.

As a technique, we could try to add something about consistency 
checking between the two.
	"Do a consistency checking between the prose and the formal language 
of the specification to remove any ambiguities and contradictions."

If we go a bit further, I think that often it's very frustrating for 
the specification reader to have things defined in the formal language 
and not expressed in the prose of the specification. Then the prose 
should at least express everything which is given in the formal 
language for human consumptions, where formal language is more for 
machine consumptions (aka validation for example).

> My comment was
> directed more at the common case of the formal language being just as
> expressive as the English prose, but one being (mostly arbitrarily or
> politically) chosen as the normative one.

In that case you set one normative, if there is conflict, it means that 
the checking work has not been done. If the informative prose is 
correct, it means that's an error of the specification to fix, but not 
a requirement for the spec reader to switch from one statement to the 
other. Specifically useful in terms of references, and conflict 
resolutions in discussions. There are sometimes never ending discussion 
sinside W3C because of such conflicts.

> That is, I was talking more about unintentional conflicts than known
> conflicts due to limitations of the formal language.


Conflicts are always unintentional IMHO :) or it's called a masochistic 
stance on writing a specification ;)

> In my work with various working groups I have found it to be 
> substantially
> easier to deal with cases where the spec was internally inconsistent, 
> than
> in cases where an informative part of the spec contradicted a normative
> part (and the normative part was the one in error).

Both should not happen. well... it must not...


-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***