procedural proposal for SpecLite

QAWG --

[Wearing co-Chair hat, and just caught up on QA email including 60+ 
extensions/extensibility messages....]

I want to identify a procedural/schedule concern about SpecLite 
publication, and make a proposal.  I'm going to try to avoid engaging in 
any particular technical arguments, although I will give a couple of "for 
examples".

Issue.  I'm concerned lest we get too caught up in trying to resolve some 
controversial issues, and that might make it impossible to publish SpecLite 
in a timely fashion.

Background.  Recall at TP2004 we resolved to publish the whole QAF-lite 
suite on 4/29 by simplifying, subsetting, and making less 
fierce/authoritarian.  We said, to paraphrase, "Should be easy, as the 
issues are all resolved already."

Illustration.  I think some of the extensions/extensibility stuff 
particularly risks a timely publication schedule (but we need to keep the 
same TP2004 resolution in mind for *all* the functional areas).  For 
example (and this is just a convenient example, not meaning to pick on Mark)...

At 03:28 PM 5/4/2004 -0400, Mark Skall wrote:
>The text below is my re-write of the the Extension text in Spec Lite in 
>accordance with my action item AI-20040403-01.
>
>This re-writes incorporates the "Skallian hypothesis".

Clearly, for example, there is technical dissent within QAWG about this 
stuff, and it appears to introduce new concepts and/or change existing (CR) 
SpecGL content.   For example...


>D.3 Plan for extensions
>Extensions incorporate new features beyond what is defined in the 
>specification.
>Note: SpecGL specifically limits profiles, modules and levels to ways of 
>sub-dividing the specification.  This implies no new features can be added 
>to profiles, modules, levels.

This statement looks like something new, and it raises technical issues, as 
evidenced by QAWG email discussion.  It could also be interpreted as being 
at odds with statements in the consensus text from CR SpecGL, for example 
at [1]:
"An extension to a specification is a mechanism to incorporate 
functionality beyond what is defined in the specification. Extensions can 
be implemented individually (e.g., one function at a time) or by defining 
new profiles, modules, or levels that incorporate additional functionality 
beyond what is defined in the specification."

[1] http://www.w3.org/TR/qaframe-spec/guidelines-chapter#Gd-extensions

Proposal.  For FPWD SpecLite, let's postpone anything which is not directly 
traceable to resolved consensus text of CR SpecGL, if there is controversy 
within QAWG around it.  Stack them as issues to be raised against FPWD 
SpecLite.

Further, if there is dispute about interpretation of CR SpecGL, then go 
with a simple majority interpretation for now, but flag with green-box text 
that there are disagreements.

Further, it might also be good to flag the whole extensibility section with 
a green-box caveat, indicating that there are significant issues and 
discussion around the material (incl. pointers to new email threads), and 
these will be tackled by the issue process after FPWD.  (The SoTD should 
also be clear that the scope of the FPWD is "simpler, leaner, less fierce 
subset of CR SpecGL".)

This is intended as a pragmatic approach -- we are not going to get closure 
on all of this stuff in next two weeks (publication schedule).  So let's 
stick with what we had, plus what we can readily agree in Lynne's excellent 
summary [2], and flag the problem areas.

[2] http://lists.w3.org/Archives/Public/www-qa/2004May/0026.html

-Lofton.