W3C home > Mailing lists > Public > www-qa@w3.org > November 2002

Re: rewrite of TOC checkpoints.

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Mon, 4 Nov 2002 09:11:56 -0700 (MST)
To: Lofton Henderson <lofton@rockynet.com>
cc: www-qa@w3.org
Message-ID: <Pine.BSF.4.44.0211040903470.1835-100000@measurement-factory.com>

On Mon, 4 Nov 2002, Lofton Henderson wrote:

> Perhaps a definition of navigation mechanism would help, or a
> limitation on what is considered valid.  Something with some sort of
> directness and linkage, as opposed to a instruction to the reader to
> "grep on all MUST occurrences".
> (Hmm... having said that, a smart "complete-sentence" grep with line
> numbers and maybe even links -- as opposed to the standard unix
> single-line dumb 'grep' -- doesn't sound bad.  I.e., the navigation
> mechanism could be some extra-document process that extracts and
> presents one or more information-specific tabulations or TOCs.)

We should be careful when allowing external tools such as a navigation
mechanisms to satisfy a checkpoint. It is always possible to implement
such a tool. A WG can consider the checkpoint satisfied just because
somebody has announced the first version of a tool. However, since
SpecGL does not control the external implementation, it may not
satisfy SpecGL intentions. As an extreme example, think of a for-fee
proprietary navigation mechanism sold by a third party.


P.S. While being appropriately dumb, Unix grep can display multi-line
     context and line numbers (e.g., grep -n -3 MUST rfc.txt).

                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance
Received on Monday, 4 November 2002 11:12:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:30 UTC