Re: formal vs. prose and PR [was: Re: Final minutes QA WG Teleconference May 16]

Hi Al,


Le 05-05-23 à 12:03, Al Gilman a écrit :
> Despite the outstanding issue
>
> "Formal vs prose language normativity"

Which has been taken into consideration during the PR Call. We are  
acknowledging the issue and we are still trying to find a solution.  
We discussed about it with the director and other participants of the  
call.
We really try to move forward with a consensus and we really hear  
your concerns and the one of Ian Hickson. :)

> ... for which the QA Working Group has failed to do due diligence to
> resolve the issue.

Look at the mails ;) and I'm still in the process of trying to find a  
solution. We already made the point of errata process. We added text  
to the document. No attempt to escape just the opposite. So let's  
continue on the work.


Let's try to work together. :)

This is the Good Practice how it stands in the Editor's Draft version.

===================================================
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: Taking such a position doesn't relieve the WG  
from
    dealing with any discrepancies as [232]errata [233]PROCESS-DOC] as
    defined in the Process Document. :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.

    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 which  
case, it
    is important to define which one is the main point of reference in
    case of disjunction.

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/
=====================================


I would add that in the section "3. Beyond Conformance". There's a  
section dedicated to internal review process to focus on quality  
aspects and to try to remove as much as possible: discrepancies,  
ambiguities, mistakes, etc.


Then to be clear: :)))

* We are not dealing with problems arising at writing time, because  
these problems if detected are solved right away.
* We are dealing with post-publication problems.

->    The Process Document says already something for Errata Management.
[[[
Working Groups must track errata on an "errata page." An errata page  
is a list of enumerated errors, possibly accompanied by corrections.  
Each Recommendation links to an errata page; see the Team's  
Publication Rules.
A correction is first "proposed" by the Working Group. A correction  
becomes normative -- of equal status as the text in the published  
Recommendation -- through one of the processes described below. An  
errata page may include both proposed and normative corrections. The  
Working Group must clearly identify which corrections are proposed  
and which are normative.

A Working Group should keep their errata pages up-to-date, as errors  
are reported by readers and implementers. A Working Group must report  
errata page changes to interested parties, notably when corrections  
are proposed or become normative, according to the Team's  
requirements. For instance, the Team might set up a mailing list per  
Recommendation where a Working Group reports changes to an errata page.

]]] - http://www.w3.org/2004/02/Process-20040205/tr.html#errata


There are two ways of dealing with the Ian Hickson about
[[[
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: Taking such a position doesn't relieve the WG  
from
    dealing with any discrepancies as [232]errata [233]PROCESS-DOC] as
    defined in the Process Document. :INS]
]]]
     [232] http://www.w3.org/2004/02/Process-20040205/tr.html#errata



Let's try a new version of the text. What about

    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. There are often overlap between the
    English prose and the formal language requirements, beware of any
    discrepancies. You may decide to introduce a mechanism to report and
    help developers take decisions in front of such discrepancies.
    Taking such a position doesn't relieve the WG from
    dealing with any discrepancies as [232]errata [233]PROCESS-DOC] as
    defined in the Process Document.

     [232] http://www.w3.org/2004/02/Process-20040205/tr.html#errata


Al Gilman, Ian Hickson, would it be closer from the spirit of what  
you are saying. If not, could you propose a wording to reach  
consensus expressing both sides concerns :)



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

Received on Monday, 23 May 2005 16:34:25 UTC