Normative or informative?

Hello,

Summary of this (rather long) message:
I summarized the assumptions that we made in yesterday's call and the W3C 
Recommendation track.  I claim that technology-specific checkpoints as well 
as a set of core checkpoints could be normative while the supporting code 
examples and implementation details could be informative. To support my 
point, I created a few core checkpoints, a few technology-specific 
checkpoints, and suggestions for supporting discussions.

The issues and assumptions from yesterday's telcon:
1. It is preferable that people only interact with one layer of the 
document.  We assume that in most cases, the one layer that developers will 
work with is the technology-specific checkpoints (commonly referred to as 
"layer 3" in yesterday's call).
2. It is therefore preferable that a person could claim conformance if they 
have followed the technology-specific checkpoints.
3. However, our assumption yesterday was that the technology-specific 
checkpoints might be updated frequently.  And, if updated frequently they 
should be informative.
4. There is concern that informative technology-specific checkpoints would 
not carry as much weight as we like.  It seems that developers need 
something normative to claim conformance to.
5. The issue with publishing a normative document is how long it takes to 
update.  We might not have the flexibility we need.

Therefore, I took an action item to investigate the possibilities of the 
W3C process [1].

A document on the W3C Recommendation track usually goes through the 
following steps:
1. Public Working Draft (should be updated every 3 months, can stay at this 
level indefinitely and usually with several non-public working drafts in 
between)
2. Last Call (It is suggested to last 3-4 weeks)
3. Candidate Recommendation (Criteria are set before entering this stage 
and must be satisfied before the document moves on. This step can be 
skipped if for some reason it is urgent to get to PR).
4. Proposed Recommendation (Mandatory 4 weeks minimum)
5. Sent to the directory (2 weeks)
6. Recommendation

If something has been published as a Recommendation and:
if only editorial clarifications or bug fixes are made, the document may be 
republished without going through the process.
if a new requirement is added, the document has to go back through the process.
	
However, the question is, "where in the process does it return to - last 
call or proposed recommendation?"
It appears that last year when HTML 4.0 was updated to HTML 4.01 it did not 
go back to last call but went to Proposed Recommendation (on August 24, 
1999 and then became a Recommendation on 24 December 1999).  A revised 
version of CSS was published with  last year, but I have not tracked down 
what process it went through.  Since there were only editorial changes it 
is still CSS1 rather than CSS1.01.

The minimum time per the above calendar for publishing minor updates seems 
to be 6 weeks.

The goal of making something normative is to provide a stable document. It 
if changes often is it really "normative."  However, how often will 
technology-specific documents realistically need to change?

Changes to technology-specifics seem to be based on a few things:
1. browser updates
2. spec changes
3. new ideas or work arounds
4. assistive technology updates

We had anticipated that the current Techniques document would be fairly 
dynamic, yet it hasn't really changed too much or very often (we're just 
now getting ready to publish a new note).  Therefore, I would like to 
challenge the assumptions that we were making yesterday.

I think that we can make technology-specific checkpoints normative (and 
therefore stable). I think that we can do this by separating the 
technology-specific checkpoints from the techniques (informative - code 
examples, explanations, screen shots, etc).

For example, for XHTML a few technology-specific checkpoints (normative) 
might be:
Provide an "alt" attribute for every IMG element.
Provide a "longdesc" attribute for some IMG elements.
Provide text equivalents or descriptions within the content of all OBJECT 
elements.
Associate each LABEL element with its INPUT element with the "for" 
attribute (on the LABEL element).

A  core techniques document (informative) would discuss:
how to write text equivalents,
how to decide when to write a long description,
and how to write a long description.

While the HTML specific techniques (informative) would discuss:
examples of "alt" on IMG,
examples of "longdesc" on IMG,
the many uses of OBJECT with examples of each,
examples of associated LABEL and INPUT elements.

The HTML/XHTML spec won't change too much from here on out.  If it does, we 
should be well aware of the changes before they happen.  They will all be 
on the same W3C schedule as we are!  Browser updates might change the 
priority or preference of some items, but how much?  If a new browser 
supports cool features but no one uses it yet, does that change what we 
suggest developers do?

As always, the wording is really rough in these "straw" proposals, but I 
hope you get the general idea of what we might be able to make normative 
versus informative.

--wendy

[1] http://www.w3.org/Consortium/Process/Process-19991111/tr.html#Recs

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Friday, 18 August 2000 17:38:18 UTC