Re: ISSUE 1049: Resolution?

Dear Ian,

This is my last attempt to see if you agree with the new wording or  
not. If not answered by the end of this week, we would considered the  
lack of answer as a reason to move forward.

Best Regards.


>> ===================================================
>> NORMATIVE, OPTIONAL
>>    Good Practice 11: Use formal languages when possible.
>>
>> INFORMATIVE
>>    What does it mean? If an existing formal language (e.g. DTD,  
>> Schemas,
>>    ...) is expressive enough to describe the technical  
>> requirements of
>>    the specification, use it and when the English prose and the  
>> formal
>>    language overlap, make it clear which one takes precedence in  
>> case of
>>    discrepancy. [INS: The presence of such a statement does not  
>> relieve
>>    the specification developers of their obligation to resolve  
>> conflicts
>>    through the [232]errata process required by the W3C Process  
>> Document
>>    [233]PROCESS-DOC]. :INS]
>>
>>     [232] http://www.w3.org/2004/02/Process-20040205/tr.html#errata
>>
>> INFORMATIVE
>>    Why care?When possible, there is an immediate benefit of using a
>>    formal language to describe conformance requirements. It minimizes
>>    ambiguities introduced by the interpretation of the prose.  
>> There is
>>    also the possibility of using existing tools for the given  
>> language to
>>    facilitate testing and validation.
>>
>>    [INS: However, prose remains necessary to allow implementers to  
>> understand
>> the specification, as well as to express additional requirements the
>> formal language cannot express; this means that there are possible
>> overlaps between the prose and the formal language. In this case, if
>> the developers of the specification have a clear position on which
>> one is the main point of reference in case of conflict, this
>> precedence should be clearly stated in the document. :INS]
>>
>> INFORMATIVE
>>    Related
>>      * Wiki: [234]Formal Language vs. Prose? [235]WIKI-FORMAL- 
>> LANGUAGE]
>>      * [236]Guidelines for the use of formal languages in IETF
>>        specifications [237]IETF-FORMAL]
>>      * INS: [238]Errata Management [239]PROCESS-DOC] :INS]
>>
>>     [234] http://esw.w3.org/topic/FormalLanguageVsProse
>>     [236] http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in- 
>> specs.txt
>>     [238] http://www.w3.org/2004/02/Process-20040205/tr.html#errata
>>
>> INFORMATIVE
>> Techniques
>>
>>      * There are plenty of formal languages used across W3C
>>        specifications: DTD, XML Schema, Relax NG, EBNF, Z  
>> Notation, etc.
>>        Picking the right one depends on the kind of specifications
>>        developed (language, XML or not, protocol) and the benefit  
>> from
>>        the formal language.
>>      * To avoid discrepancies between the English prose and the  
>> formal
>>        language, set up a process so that a given section is bound  
>> to a
>>        given part of the formal language, and one cannot be modified
>>        without the other.
>>      * Use the formal language tools to validate the examples  
>> given in
>>        the specification, to ensure they match.
>>      * When using several formal languages in combination, generate
>>        random content according to the rules defined in one of  
>> them and
>>        try to validate it with the others, to find discrepancies.
>>
>> INFORMATIVE
>> Examples
>>
>>    [240]XQuery Formal Semantics [241]XQUERY-SEMANTICS] section 1.1
>>    defines where the document is normative over the grammar specs
>>    (separate for XPath and XQuery) and where the grammar specs are
>>    normative.
>>
>>     [240] http://www.w3.org/TR/2005/WD-xquery-semantics-20050404/
>> =====================================
>>
>>
>> --
>> Karl Dubost - http://www.w3.org/People/karl/
>> W3C Conformance Manager
>> *** Be Strict To Be Cool ***
>>
>
>

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

Received on Tuesday, 31 May 2005 14:36:43 UTC