Re: Answer to Ian Hickson: Formal vs prose language normativity

At 10:42 AM -0400 5/16/05, Karl Dubost wrote:
>Hi Ian,
>
>Le 05-05-15 à 21:17, Ian Hickson a écrit :
>>On Fri, 13 May 2005, Karl Dubost wrote:
>>>We do not necessary fully agree with your comments but we do understand
>>>your concerns. We came with the conclusion that it would be bad for
>>>developers if they can't move forward so we decided to keep our stance
>>>on having a rule to move forward in case of conflicts.
>>>
>>
>>I don't understand that.
>>What if the prose contradicts something else in the prose?
>
>
>I think we should try to make a more concrete examples. The QA 
>Working Group is trying to be pragmatic here.
>
>Statement: It will never be possible to publish a document as a REC 
>without errors.
>
>1. So a WG is developping a technology and is publishing WDs.
>2. Reviews help to fix mistakes in the specification (incoherence, 
>bugs, inconsistencies, etc, contradiction in the prose, the formal 
>language, or both).
>3. The technology is published as a REC.
>
>
>4.  An implementer detects an error in the specification, for 
>example contradiction between the formal language and the prose.
>5. The implementer send a comment to the Mailing List to open an issue.
>6. The WG has in charge to publish an errata on the technology.
>
>A few issues:
>     * The WG doesn't exist anymore
>     * The WG is not anymore chartered to make conceptual changes to 
>the specification
>     * The WG is slow to answer
>     * The interpretation in the community and/or in the WG are conflictual.
>
>Basically it might sometimes takes a lot of time to fix the mistake. 
>The question is then:
>     * Should all developers stop their work for months or years?
>     * Should developers rely on their own hacks to fix the mistake? 
>(might be interop problems)
>     * Should developers follow a rule given in the specification? So 
>at least there's a uniformity?
>
>The decision of the WG, I think, is in that sense being pragmatic. 
>Well, we recognize something bad might happen, and in this case you 
>should try to follow this rule. It doesn't mean that the WG will not 
>fix it, by the process document the WG has to fix it.
>
>But in the meantime what's happening? What are the solutions?
>
>Ian, do you have a solution for it that would be strict enough with 
>regards to your expectations but still tied to the reality of the 
>social building of a standard? :)

Of course.

Case WG is alive, spec is in CR:

Raise issue to WG and mark implementation as tentative, subject to
resolution of the submitted spec issue. Release processing is the art
of winnowing down the volume of such red and amber tags on the
implementation.  Developers can handle this.  Code is not so
brittle as to require total recode for one ambiguity in the spec.
Even if the impact is everywhere, you can incorporate compile-time
switches that make changing the assumption a matter of a build
and test cycle time, not a design/code cycle time.

Case WG is dead, spec is in legacy mode:

Raise issue to water-cooler-of-opportunity where users of this spec
congregate. Seek feedback from other implementers.

Go into plugfest mode and determine what interoperates with the
incumbent processor stock.

Subcase implementations consistent:
Pick the interpretation favored by incumbent implementations.

Subcase implementations not consistent:
go into "equivalent facilitation" mode where a comparable capability
is enabled by alternate, interoperable means.  In other words
work around the flaw in the spec.

The concrete fact the QAWG seems to be ignoring is that if you don't
have a development activity (WG) alive for the spec, you have the
opportunity to determine interoperation success empirically from an
established base of incumbent implementations.

Al

>I think we are making progress.
>
>
>--
>Karl Dubost - http://www.w3.org/People/karl/
>W3C Conformance Manager
>*** Be Strict To Be Cool ***

Received on Monday, 16 May 2005 16:28:20 UTC