RE: [TECH] Summary of conversation with Kansas State U.

Gregg Vanderheiden writes:
 > 
 >  The checklists are attached to the guidelines not the techniques -- though
 > they draw from the techniques.   There is more in the techniques than would
 > be in the checklists.  They are the minimum (with options where they exist)
 > needed to conform to the guideline's success criteria.  

This is my understanding exactly. The checklists are substantially
derived from the techniques; if all checklist items listed under a
success criterion are true, then that success criterion has been met,
as applied to the technology or technologies for which the checklist
is written.

There is still an open issue, raised by Gregg, concerning whether
checklists should be normative. The main argument against this has
been the need for flexibility in updating and republishing the
checklists. On the other side, the W3C process for publishing
revisions of specifications has been streamlined in recent years.

I am not trying to advocate this, but only to suggest it: one approach
would be to write each checklist for a specific version of a
technology. For example there could be an SVG 1.1 checklist, or an
HTML 4.01 checklist, or an XHTML 1.1 checklist, or a VoiceXML 1.0
checklist, etc. Where there are multiple techniques, some of which
rely on deprecated features of the technology or are crucially
important work-arounds for implmeentation problems, these could be
listed as optional checklist items, and marked as to their status
(i.e., deprecated feature or whatever it may be).

Again, I am not trying to advocate normative checklists, but only to
sketch one way in which such a proposal might work if the group
decided to pursue that course of action.

Received on Tuesday, 11 May 2004 04:30:31 UTC