Notes on SpecGL discussions [DRAFT]

Here are some notes on the informal SpecGL discussions that we had today 
(7/24) in lieu of the normal telecon.

Participants:

KD: Karl Dubost
LH:  Lofton Henderson
DM: David Marston
SM: Sandra Martinez (for 1 hr).
JM:  Jack Morrison (for 1 hr).

Please check these and let me know if I have gotten anything wrong or 
omitted anything.  Apologies in advance -- my notes are dreadful quality.

Notes
-----

Sec 1.6:  DM suggested that we not go into detail of an "Associations 
Matrix" at this time.  The next public draft (~20 August) should be for the 
purpose of getting response and comment on the dimensions-of-variability 
organization.  General agreement.

KD:  some general comments about problems spotted while writing Spec Extech 
first draft.  E.g., "choose whether or not to have levels" is not how 
things happen or are done in W3C.  DM and SM had some comments about it as 
well.  Seems to be some agreement that we need to look at and adjust the 
verbiage, and maybe even the wording of the checkpoints.

One particular problem.  When you aren't going to use profiles (for 
example) -- "no" to CK3.1 -- then it should be made clearer that 3.2, 3.3, 
... are "Not Applicable" and need not be satisfied.

KD will circulate his draft Spec Extech work to the QAWG -- there are 
embedded comments about difficulty in applying the checkpoints.

[LH to SM:  will you also summarize the problems/questions you found so far 
in doing your SpecGL review assignment?]

KD raised issue about the many "TOC entry" checkpoints -- it is unclear 
what you should do and how, in order to satisfy.  It is made worse because 
there are several styles of TOC -- high level ('h2' only), versus 
detailed.  Many specs have both.  But not all specs.  E.g., QA Framework 
only has high level.  Similar for WAI.  Agreed that these checkpoints need 
clarification.

DM suggested.  High-level should point to "Conformance", and "Conformance" 
should then point to individual items (e.g., deprecated features, 
extensions, profiles, etc).  The pointer could be to a single "catalog" -- 
for example a table of discretionary items -- that in turn points to the 
specific items around the spec.

We then went through a number of comments of DM and SM, from the list of 
"@@" issues:

CK1.2:  postpone till Kirill (originator of wording) is back.

CK1.3:  (SM) "each behavior or requirement" is too vague to 
implement.  Agreed that we need to elaborate and clarify wording here.

CK2.3:  fair amount of discussion around this one.  Agreed is that table 5 
is wrong pointer (this is "Rules for Profiles" -- what minimally goes into 
a valid profile -- not minimal profile rules on some product.)  Agreed that 
SVG example is not optimal -- it is called profiles but looks a lot like 
levels.

[JM and SM left somewhere around here.]

CK3.4:  We discussed the proposition that the meaning is, "For each 
profile, define the minimal required features/support for each class of 
product".  Agree about first part -- "for each profile" -- but there was 
some resistance to the second part, "for each class of product 
(CoP)".  Open question:  if not "CoP", then what is the object of 
"requirement"?  Digression, discussion and no general convergence 
about:  is CoP a fundamental dimension that should be used to organize the 
other dimensions?  I.e., any useful subspace of the 8 dimensional DoV space 
involves the CoP dimension?

GL4:  DM agrees that the Modules definition from SMIL, circulated by LH, 
would be useful in the verbiage of GL4, but with the "namespace" stuff 
removed.  The profiles-modules relationship is also interesting.  DM is 
going to supply some proposed modules-levels verbiage.

CK4.4:  When Zakim kicked us off, we (LH-DM-KD) were disagreeing about 
whether levels-contain-modules or modules-contain-levels -- what is good 
and what is bad?  We apparently have some divergence in our respective 
models of modules.  DM is going to dig up some examples which differ from 
the XTHML-SMIL-SVG lineage (of modularization, that is).  (Note we 
previously agreed with the SMIL statement, in the context of its rules for 
profiles, that "modules are atomic" and profiles can't subdivide modules.

End-of-call.

Respectfully submitted,
-Lofton.

Received on Wednesday, 24 July 2002 14:32:56 UTC