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

At 12:34 PM -0400 5/23/05, Karl Dubost wrote:
>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. :)

OK, I remove my [zero-weight] vote to sustain an objection.

Thank you for giving us the draft language from the editor's draft.

I had not realized that the language at issue was in an informative section.

Further, I see that what you are after is more

"explain how the prose and formalism combine to create the definitive
statement of conformance" and not so narrowly "state a blanket
precedence for prose or formalism in case of a conflict."

The XQuery Formal Semantics example is a good one. For something that
authors may feel more closer to, you might consider adding the
interaction of productions and constraints in the XML specification,
e.g. at http://www.w3.org/TR/xml11/#sec-well-formed.

Best of luck with the uptake of the SpecGL.

Al

>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 17:16:32 UTC