- From: Sandra Martinez <sandra.martinez@nist.gov>
- Date: Thu, 25 Jul 2002 09:34:51 -0400
- To: Lofton Henderson <lofton@rockynet.com>
- Cc: www-qa-wg@w3.org
David, The following are comments or observations encountered while working on the review assignment for the specifications guidelines. I am using the WD recommendation for Namespaces in XML 1.1 as the basis for my review. The first two were discussed in yesterday's meeting. · Section 1.6 When doing the review I was distracted by the list of guidelines in relation with the dimensions of variability lists that follows. · Checkpoint 1.4: A priority 1 checkpoint that I was not able to address in a precise manner. The checkpoint calls to illustrate [“each” behavior or requirement in the specification by short and precise examples]. The namespaces in XML 1.1 specification contains examples in almost every section, but not for every single behavior or requirement. · Checkpoint 10.1 and 10.2: If the priority is to have a conformance clause no matter where in the specification then checkpoint 10.1 should be kept separate. · Relationship between checkpoint 5.4, 10.1, 10.3 was distracting. Checkpoint 5.4 is a priority one that also address the conformance clause, how it should be easily identifiable and how the reader should be able to find all aspect of the conformance requirement from the table of content the table of content is a priority 2 in checkpoint 10.3. · Checkpoint 10.3: The informative verbiage in this checkpoint confuses the meaning of table of contents, what exactly are we looking for in this checkpoint? Cordially, Sandra At 12:35 PM 7/24/2002 -0600, Lofton Henderson wrote: >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. > Sandra I. Martinez National Institute of Standards and Technology 100 Bureau Drive, Stop 8970, Gaithersburg, Md. 20899 (301) 975-3579 sandra.martinez@nist.gov
Received on Thursday, 25 July 2002 09:40:13 UTC