informative vs normative docs etc....

A long aside about process. No substantive discussion. Please skip if 
process bores you.

=========================


I feel there is a certain amount of disagreement about:

a) the nature of the informative docs we might be publishing
b) how we decide which informative docs to publish

Actually it is probably worth dividing docs into three classes:

normative specifications
    - these are often very technical and hard to read, but contain 
precise descriptions of the *design*

informative descriptions of normative specifications
   - these are easier to read, and are logically dependent on the 
normative spec

informative specifications
   - these are documents which describe some ancilliary technology that 
is not part of the core design produced by the WG.

======

As I see it, the discussion about the three technical member submission 
docs is about normative specifications; and discussion about the 
user-facing docs is about informative descriptions of normative 
specifications.

A possible candidate for an informative specification might be an XML 
serialization of the abstract syntax, and that can wait for another day.

======

It is clearly possible, and sometimes attractive, to have a single 
document that includes both the normative specification and an 
informative description.

======

As I see it, responsibilities are powers are as follows:

The *design* is the responsibility of the working group as a whole.

Correctly articulating that design in a concise fashion is the 
responsibility of the editor(s) of the normative specification documents.

Correctly and usefully presenting that design is the responsibility of 
the editor(s) of the documents that contain informative descriptions of 
normative specifications.

The working group chair is responsible for appointing editors of documents.

Precisely which documents come out of the working group process is 
emergent, lots of people have an effective veto, but hardly anyone uses it.
A) the chairs can stop a document by not appointing an editor
B) the working group can refuse to publish a WD
C) the W3C team (the director) can refuse a publication request from a WG


I think legitimate reasons for these are few and far between.

If there is energy in a WG to produce a document, then plausible good 
reasons *not* to do so include:

A) the potential editor does not have the appropriate personal qualities 
(i.e. they are too arrogant, and do not listen enough)
A) the timing for an informative document is too late, and may derail 
the schedule
A) overlap - each aspect of the design should (ideally) be recorded in 
precisely one normative specification.

B) the document does not correctly reflect the design
B) the document is of insufficient quality for the phase of publication 
(i.e. there are too many unaddressed editorial issues)
B) further review required

C) procedural irregularities
C) team resources

===

In phases, such as now, when the design is not finalized, it is 
important that both normative and informative docs reflect the (lack of) 
WG design, by adequately indicating the status of the design.
I think and important part of the FPWD will be for us as a WG to simply 
record which bits of the design are most likely to change, and which are 
already consensus.

The most important aspect of the sample set of reasons is that they 
leave a large area called 'editorial discretion' - the documents, as I 
see it, are fundamentally the work of the editors, and it is the editors 
who get to make the call on issues like whether the presentation is 
adequately clear, adequately useful, attractive, etc. etc.
The WG help by offering reviews. It is a foolish editor that rejects too 
many editorial review comments. [There is a good editorial style whereby 
you accept, nearly, all comments, but in your own way, so that a comment 
does cause a change, but perhaps not the change the commentator had in 
mind]. WG participants should (IMO) only insist that the editor 
addresses their comments when it concerns correctness of the statements 
about the design. e.g. if the editor misspells a keyword, then this is a 
reason for a WG participant to insist on holding up publication. If the 
editor misspells some other word, then it is *their* call whether a 
particular WD can be published with that misspelling or not.

Jeremy

Received on Tuesday, 6 November 2007 15:51:51 UTC