- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Mon, 16 May 2005 12:08:33 -0400
- To: Karl Dubost <karl@w3.org>, Ian Hickson <ian@hixie.ch>
- Cc: www-qa@w3.org
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