QAWG Last Call Disposition of Comments for SpecGuide

This document records the QA Working Group's (QAWG) response to comments on the Last Call Working Draft of QA Framework: Operational Guidelines Please note that the table below is for Operational Guidelines only. We will generate separate tables for the Specification Guidelines and Introduction specifications.

The full statement of each issue and its full processing history can be found in QAWG's Last Call Issues List. The issue number in the first column of the table links to that. The Resolution column has links to specific text in a Operational Guidelines editor's draft, whose purpose is to illustrate the Disposition.

The last column indicates QAWG's disposition of the issue:

The deadline for replies to this DoC document is 12pm (noon) EDT, Monday, 18 August 2003. Your reply at your earliest convenience — whether you accept QAWG's disposition of your comment(s) or not — will help us to stay on schedule for progression of Operational Guidelines. If we do not hear from you (originator) by the deadline, your default reply is "accept QAWG's disposition of comments".

If you do not accept QAWG's disposition of your comments, please provide details, including your reasons, and also what change to the disposition would be required to satisfy you.

Last update: $Date: 2003/08/27 21:11:26 $

Issue # Originator Description Resolution Status
LC-1 Alex Rousskov require a "Security Considerations" section The proposal has merit, and should be addressed by W3C, but the QAWG considers security requirements to be outside of the scope of QA Framework. Will be referred to an appropriate W3C group or team. not accepted
LC-78 David Marston Should provide a disclaimer template The suggested templates are a good idea. They would belong in Examples & Techniques (SpecET), as was done for OpsGL templates. The editors will work with Orginator to make acceptable templates, and integrate them into SpecET. accepted
LC-22 Ian Jacobs CP 2.3 placement of Checkpoint This contradiction has been removed, as a part of revision of the Introduction chapter, the addition of a "Concepts" DoV chapter, and the reorganization and consolidation of the Guidelines. See draft revised text. accepted
LC-23 Ian Jacobs CP 1.4 vague Resolved in favor of modified Alternative 2. The discussion and breakdown by category will be done in Spec Examples & Techniques (SpecET). But the Discussion of CP1.4 (now CP1.3) will mention the concept raised by comment originator (that different kinds of specification categories require different particular associated kinds of examples), and gives a brief "for example." See draft revised text. accepted with modifications
LC-24 Ian Jacobs Introduction, Sect 1.4 This has been changed as suggested. accepted
LC-25 Ian Jacobs Introduction: scope and goals Agreed, it has been deleted. accepted
LC-26 Ian Jacobs Multiple CPs - It is not applicable QAWG appreciates the utility of the "normative exclusion" concept in the complex conformance landscape of UAAG 1.0. For the few and simple occurrences of the "not applicable" usages in SpecGL, QAWG considers that it is cleaner and clearer not to introduce a new concept and terminology such as "normative exclusion". Resolved: no change. not accepted
LC-27 Ian Jacobs Typos, grammar, etc. These have all been fixed as suggested. accepted
LC-28 Ian Jacobs document organization suggestions Agreed, this has been done. accepted
LC-29.1 Ian Jacobs questions and suggestions: In general, specifications make functional requirements. In some cases, it may be necessary to make a performance requirement. How should that be handled?

20030714 telecon directed that it be resolved as indicated in ungrouped-issue proposals: if performance requirements are within the scope of the standard, and they presented the same as any other conformance requirement -- e.g., using RFC2119 keywords -- then there would not seem to be any issue. For conformance purposes, they would not need any special handling. (No changes to SpecGL.)

accepted with modification
LC-29.2 Ian Jacobs questions and suggestions: In UAAG 1.0, we realized that for some of our configuration requirements, it didn't matter whether the user agent offered the desired configuration or didn't implement the functionality in the first place. E.g., we decided that it was ok for a user agent to not support blinking at all, or, if blinking is implemented, to offer a configuration to turn it off. However, in other cases, the configurability was "just as important" as the functionality to be configured. Authors should consider these when they specify configuration options.

20030714 telecon directed that it be resolved as indicated in ungrouped-issue proposals: Since SpecGL 1.0 has not gone to such a level of detail as addressing configuration options, we are unsure how this comment would affect SpecGL. Note that we (QAWG) have decided that the scope of SpecGL 1.0 should be limited to the most critical and basic topics. This could be added to requirements for SpecGL 2.0. It could also be mentioned, possibly, in SpecET (Examples & Techniques). If Originator thinks that this topic fits under one of SpecGL's existing checkpoints, then perhaps he would be interested to make a contribution, to be put into SpecET. The SpecGL scope has been clarified to indicate the "basic and critical" scope of SpecGL 1.0. See draft revised text.

accepted with modification
LC-29.3 Ian Jacobs questions and suggestions: It might be valuable for a specification to explain how to include its requirements in another specification. This is not the same as explaining how to reference the spec, or how to claim conformance to it.

Discussed at 20030707 telecon. We (QAWG) have decided that the scope of SpecGL 1.0 should be limited to the most critical and basic topics. We think that this topic has merit, but is more advanced and detailed than we are dealing with in SpecGL 1.0. It could be added to requirements for SpecGL 2.0. Alternately or in addition, it could also be mentioned in SpecET (Examples & Techniques). If Originator thinks that this topic fits under one of SpecGL's existing checkpoints, then perhaps he would be interested to make a contribution, to be put into SpecET. The SpecGL scope has been clarified to indicate the "basic and critical" scope of SpecGL 1.0. See draft revised text.

accepted with modification
LC-29.4 Ian Jacobs questions and suggestions: It might be valuable to explain some desirable characteristics of a specified technical requirement: Mutual independence from other requirements Expresses a minimal requirement Distinguish and label: requirements, exceptions to those requirements, necessary and/or sufficient techniques for satisfying those requirements.

Discussed and resolved at 20030623 telecon. Agreed that it is useful to discuss some attributes of well-written conformance requirements. Some verbiage has been added to the introductory text of GL7 (new number). More extensive material may be added to SpecET (contributions would be welcome!). See draft revised text.

accepted
LC-29.5 Ian Jacobs questions and suggestions: I think that more could be stated about useful ways of allowing extensibility. See, for example, how CSS (forward-compatible parsing), XML, and HTTP handle this. What should be avoided? Is the general practice of "ignore what you don't know" a good idea or a big mistake?

Resolved at 20030505 telecon, as part of the extensibility issue group resolution. This should not be covered in SpecGL, but it ought to be covered in the SpecET material on extensions. SpecET should illustrate numerous kinds of extensions -- some that have serious interoperability impacts, some that mitigate the impacts, some approaches that might be considered "useful", etc. Also, QAWG discussion sees some problems with examples such as CSS "forward compatible parsing" -- it opens up the ill-defined topic of what is an unknown extension versus what is corrupted or erroneous content. This has been added to the SpecET queue.

accepted with modification
LC-29.6 Ian Jacobs questions and suggestions: A spec should clearly indicate which illustrations (e.g., images) and examples are normative, if any.

20030714 telecon directed that it be resolved as indicated in ungrouped-issue proposals: agreed. The wording of CP13.2 has been adjusted to include all sorts of normative content. See draft revised text.

accepted
LC-30 Ian Jacobs Profile, module, level See the comprehensive solution for the profiles/modules/levels issue group. Agreed to clarify concepts with better definitions and discussion, and to merge the three separate guidelines into a single guideline. However the 3 individual concepts will be kept as separate DoVs within the merged guideline, and will be dealt with independently in the appropriate checkpoints. See draft revised text. accepted with modifications
LC-31 Ian Jacobs general Thanks for the useful feedback. (No issue.) accepted
LC-32 Ian Jacobs 4. Definitions Since the term is not used anywhere in SpecGL, the empty definition is removed from SpecGL. (And a definition will be added to "QA Glossary".) accepted with modifications
LC-33 Ian Jacobs 4. Definitions The language has been clarified and made more specific. See draft revised text. accepted
LC-34 Ian Jacobs Section 3.4 Conformance definition The second sentence is dropped as suggested, and the wording of the first sentence is tuned. See draft revised text. accepted
LC-35 Ian Jacobs Section 3.2 Extensibility Although CP9.3 may be redundant, the redundancy doesn't hurt here. Not every reader is going to logically connect the dots, as has the commentor. Therefore QAWG believes that CP9.3 should remain as is. not accepted
LC-36 Ian Jacobs Section 3.1 Normative sections SpecGL uses a focused definition of normative -- normative stuff is directly connected to conformance requirements -- that is narrowly applied. By this definition and its application, things like Glossary definitions ("5. Definitions") are not normative. SpecGL has clarified what's normative in "Normative parts" in "4. Conformance". Also, in "1.6 Usage of terminology", it is clarified that defined terms, when used in SpecGL, have the meanings given in the definitions. See draft revised text. accepted with modifications
LC-37 Ian Jacobs CP 9.3 Although CP9.3 may be redundant, the redundancy doesn't hurt here. Not every reader is going to logically connect the dots, as has the commentor. Therefore CP9.3 should remain as is. not accepted
LC-38 Ian Jacobs CP 9.1 and 9.2 combine Agreed, CP9.1 and 9.2 have been combined (into new CP6.1). See draft revised text. accepted
LC-39 Ian Jacobs CP 8.4 policies for discretionary choices 8.4 will be kept, broadened to "items" instead of "choices", and final text (derived from the new proposal) will be revised and clarified by SpecGL editors. (@@tbd@@) accepted
LC-40 Ian Jacobs GL7 add obsolete features Per LR proposed resolution: add a definition of obsolete, add a new checkpoint about obsolete features, add language to GL7 (new GL4) verbiage. See draft revised text. accepted
LC-41 Ian Jacobs CP 4.4 derived profile "Derived profile" is now defined in the new chapter "2. Concepts", and has been added to "Definitions", and that definition is linked from appropriate places in the guidelines. See draft revised text. accepted
LC-42 Ian Jacobs GL3: contradiction? regarding examples While the verbiage in GL3 is informative, versus the normative requirements of CP1.4, nevertheless the text in question has been revised, removing "possibly", to avoid any apparent conflict with "MUST provide examples". See draft revised text. accepted
LC-55 Jon Gunderson Accessibility [@@brief draft reply -- flesh this out@@] Specifying accessibility requirements is outside of the scope of the QA Framework. It more appropriately belongs in Pubrules. This proposal will be referred to Comm team. not accepted
LC-84 Jonathan Marsh Group dimensions of variability This has been addressed with the new chapter -- "2. Concepts" -- and with an expanded DoV discussion in one of its subsections. With these improvements, restructuring to segregate the DoV guidelines into their own document sections is thought to be unnecessary. See draft revised text. accepted with modifications
LC-85 Jonathan Marsh Self-sufficient guidelines and checkpoints Resolved per proposal in email. Agreed that these are good principles. While it is beyond our resources to completely rewrite the document with these in mind, we have tried to apply them going forward with the editing and revision of SpecGL. accepted with modifications
LC-86 Jonathan Marsh Spelling, grammar, and style In the final WG-only SpecGL draft preceding the published version, we will make a review for grammar and spelling [MS & LR]. With our mix of authors, there is not much that we can do about different styles, other than to ensure that everything is grammatically correct. accepted with modifications
LC-87 Jonathan Marsh Abbreviations We believe that we are doing references correctly (per "Manual of Style"), but we see that we have omitted the brackets "[]" on the abbreviations in the References section. That has been fixed. We [LR/MS] will also check style of references during grammar/spelling review (for issue 86.) (About 'bibloc', note also that we are not using xmlspec, but rather XHTML customized with some classes.) See draft revised text. accepted
LC-88 Jonathan Marsh Reformat bullet list There are no applicable guidelines on this in the W3C "Manual of Style", or elsewhere as far as the editors can determine. Being a matter of preference and taste, it was resolved to keep the current style. not accepted
LC-89 Jonathan Marsh Consolidate glossary and terminology Resolved per email proposal. It is done both ways in W3C specifications -- definitions up front versus definitions at the end -- and QAWG prefers this way for SpecGL. Also these two changes have been made: change the title of 1.6 from "Terminology" to "Usage of terminology in this document" (removing possibly confusion that 1.6 is the glossary); and, this sentence is added to 2nd paragraph, "When used in this specification, terms have the meanings assigned in 'Definitions' and 'QA Glossary' [QA-GLOSSARY]." (Making moot the question of whether definitions are normative or informative.) See draft revised text. accepted with modifications
LC-90 Jonathan Marsh Restructure DoV This has been resolved consistently with the new chapter proposal, and addressed in a new DoV sub-section in the new chapter "2. Concepts". Each DoV guideline (now GL2-GL6) links back to the subsection. See draft revised text. accepted with modifications
LC-91 Jonathan Marsh Complexity of numbering Given that the context is usually clear (or easily made clear by the usual prefix of "guideline" or "checkpoint" [x.y]), the current GL/CP numbers are considered both more convenient and sufficient; the numbering scheme is familiar from WAI specifications and has been successfully used there; and, the proposed numbering scheme would have the undersireable characteristic that every guideline would start with "2." (e.g., 2.8) and every checkpoint would start with "2." (e.g., 2.8.4). No change. not accepted
LC-92 Jonathan Marsh Examples vs. Illustrations CP1.3 has been merged into CP1.2 and the single checkpoint has been reworded as "Illustrate scope" (with examples and/or use cases); CP1.4 (now CP1.3) has been reworded as "Illustrate technical details"; and further clarifications are made in the Conformance Requirements, Rationale, and Discussion sections. See draft revised text. accepted with modifications
LC-93 Jonathan Marsh Classes vs. categories The verbiage on classes and categories has been revised consistent with the 4-point proposal in email comments. The verbiage has all been moved to a new subsection of the new chapter "2. Concepts", with individual sub- subsections for "specification category" and "class of product". The definitions of the two concepts are in "5. Definitions", and all of these bits are linked from the appropriate places in the guidelines and checkpoints. Some of the text has been rewritten to improve clarity. See draft revised text. accepted
LC-94 Jonathan Marsh Loophole in Classes and Categories Resolved consistently with proposal in email comments. The lists and verbiage have been revised and clarified, and have been moved into a new subsection of the new chapter "2. Concepts", which are referenced from GL2 and its checkpoints. We have clarified that the enumeration covers the most common cases seen in W3C technologies, that an enumerated item is to be used if it matches the specification category (SC) or class of product (CoP), and that specs should define their own item only if it is NOT matched by one of the enumerated items. We think that the intent is now very clear. It might still be possible to circumvent the requirements with devious intent, but we don't consider it productive to take further extraordinary steps in SpecGL to close all possible loopholes, in order to to prevent such intentional circumvention. See draft revised text. accepted with modifications
LC-95 Jonathan Marsh Why is conformance policy a DoV? GL3 is no longer a DoV (reducing the number of DoV from eight to seven.) All of the bits of GL3 which would have qualified it as a DoV have been changed or moved elsewhere, and GL3 is to be merged into GL10. See draft revised text. accepted
LC-96 Jonathan Marsh Priorities confusing CP3.1 is priority 2 because it is implicit (but not explicitly spelled out now in the checkpoint) that the requirements that comprise the universal-minimum set (across CoP) all occur elsewhere, in the definition of the conformance requirements for each individual Class of Product (CoP). Thus, the enumeration of CP3.1 could be derived. Because the enumeration could be difficult or obscure, it is considered important/desirable (P2), but not critical/essential (P1). This has been clarified in CP3.1. See draft revised text. accepted with modifications
LC-97 Jonathan Marsh Modules as extension points A new CP is not thought to be needed. This case -- involving modules and extensions -- is somewhat different than the Rules for Profiles case (where extensions are typically not a factor.) QAWG thinks that CP9.4, CP9.7, CP5.2 (new CP6.3, CP6.6, CP3.4) cover this adequately. Clarifying explanation has been added, per the clarification proposal. See draft revised text. accepted with modifications
LC-98 Jonathan Marsh Conformance levels The suggested checkpoint and associated normative conformance requirements are considered redundant and unnecessary. It (hierarchy) is part of the definition of "levels", and the terms in SpecGL "...have the meanings assigned in 'Definitions' and 'QA Glossary' [QA-GLOSSARY]." not accepted
LC-99 Jonathan Marsh Awkward deprecation requirements How the commentor has understood the checkpoint is not how QAWG intended it. It is not necessary to fully define the deprecated functionality, in order to meet the intent of the checkpoint. That intent is that the impact of deprecating the feature on other DoV needs to be discussed. E.g., if the spec is modularized or profiled, how does a feature's deprecation impact those DoV? CP7.3 (new CP4.3) has been modified to clarify and to avoid this confusion, and some "for examples" have been added. See draft revised text. accepted with modifications
LC-100 Jonathan Marsh Don't discourage extensibility "Extensions should not be allowed" is not in fact what the verbiage of GL9 and its checkpoints actually says. It actually says to exercise caution, and weigh the perceived benefits against negative interoperability impacts. That notwithstanding, some editorial changes have been made to further neutralize the language, without changing the substantive content. The QAWG also disagrees with the assertion that this is a "political" position. It is based on extensive experience, especially where unconstrained or careless use of extensibility has had disasterous interoperability impacts (some of these, as well as some more positive examples, will be documented in SpecET). See draft revised text. not accepted
LC-101 Jonathan Marsh Remove Checkpoint 9.6 Originator has misinterpreted what (old) CP9.6 actually required. CP9.6 said that specifications that allow extensions must contain conformance requirements that require extension-supporting *implementations* to provide a no-extensions mode. It does not say, as Originator asserts, that the specification must spell out workarounds for all possible yet-to-be-invented extensions. Based as it is on this misunderstanding, the follow-on assertion is also incorrect, "In other words, no specification that allows extensions can conform at priority three, ever." A target specification could conform (to this P3 checkpoint) if it required a no-extensions mode of conforming implementations. Finally, note the significant changes to the CP9.6 (new CP6.5) requirements on target specifications in the resolution of related issue LC-81 -- see draft revised text. not accepted
LC-102 Jonathan Marsh Consolidate G3 and G10. Considering all related guideline (GL) consolidation and reordering issues together, it was resolved to: merge (old numbers) GL3 into GL10; move current CP10.2 into GL13; move CP11.1 into GL10; merge GL11 and GL12; and reorder as GL13, GL10+GL3, GL11+GL12. See new GL7, GL8, GL9. See draft revised text. accepted with modifications
LC-103 Jonathan Marsh Distributed conformance section OK Agreed, it is indeed the intent (per Originator's suggestion, "distributed conformance section OK"), that most of the specific conformance requirements ("technical requirements") may be distributed throughout the specification. It is GL3 sorts of things (overall conformance policy) that should be in a conformance section. To remove this confusion, the words, "and specific conformance requirements" are deleted from the ConfReqs statement. See draft revised text. accepted with modifications
LC-104 Jonathan Marsh Consolidate G11 with G3/G10 Considering all related guideline (GL) consolidation and reordering issues together, it was resolved to: merge (old numbers) GL3 into GL10; move current CP10.2 into GL13; move CP11.1 into GL10; merge GL11 and GL12; and reorder as GL13, GL10+GL3, GL11+GL12. See new GL7, GL8, GL9. See draft revised text. accepted with modifications
LC-105 Jonathan Marsh G3, G10, G11, G13 Considering all related guideline (GL) consolidation and reordering issues together, it was resolved to: merge (old numbers) GL3 into GL10; move current CP10.2 into GL13; move CP11.1 into GL10; merge GL11 and GL12; and reorder as GL13, GL10+GL3, GL11+GL12. See new GL7, GL8, GL9. See draft revised text. accepted with modifications
LC-106 Jonathan Marsh Section 3.1 - Poor Defn of Normative QAWG considers that SpecGL's focused definition of normative ("5. Definitions") and its narrow application are appropriate for SpecGL. We note that it is more focused and narrowly applied than definitions in some other specifications. Agreed that are some problems in wording of section 3.1 (now 4.1), including the characterization of normative units of text. This has been revised, the lists in conformance section 3.1 (now 4.1) have been made more comprehensive, and the priorities have been added. Regarding the possibility of someone redefining the terms used in SpecGL, it has been clarified in "1.6 Usage of terminology" that defined terms, when used in SpecGL, have the meanings given in glossary. See draft revised text. accepted with modifications
LC-107 Jonathan Marsh Section 3.4 - AAA-terminology useless This is dealt with by fixing OpsGL, in the resolution of OpsGL issues 3, 60.2, 72.2, 72.3, 83. See OpsGL draft revised text of CP1.1 (as well as CP1.2, CP1.3). accepted with modifications
LC-108 Jonathan Marsh Definitions The issue has been addressed by fixing the text and "what's normative" lists in section 3.1 (now 4.1), and stipulating (section 1.6) that terms used in SpecGL have the meanings given in "Definitions" and "QA Glossary". The problem with blanket designation of sections 1 - 4 as normative is that a lot of the information is clearly informative. We think that with this resolution, SpecGL now has clear and unambiguous identification of all of its conformance-related information. See draft revised text. accepted with modifications
LC-73.1 Leonid Arbouzov Collected substantive & editorial comments: [SG-1]: Editorial (SoTD).

Resolved, it has been fixed as suggested.

 accepted
LC-73.2 Leonid Arbouzov Collected substantive & editorial comments: [SG-2]: Remove all "not applicable if..." statements.

Discussed and resolved at 20030602 telecon (DRAFT). QAWG agrees that there are some editorial problems in these clauses. As pointed out, "It" is undefined (should be "This checkpoint"). There is also inconsistent usage, e.g., some checkpoints in Guideline 9 have applicability exclusions, and some do not. In general, however, it is thought useful that there be an explicit applicability exclusion, rather than leaving the reader to interpret this (*only* if there is an applicability exclusion can the n/a box in the ICS be checked). SpecGL editors will improve the language, clarify the ambiguous statements, and apply consistent structuring, for all checkpoints that have applicability exclusions. See draft revised text.

accepted with modification
LC-73.3 Leonid Arbouzov Collected substantive & editorial comments: [SG-3]: "Enumerate all CoP" is unreasonable requirement.

Discussed and resolved at 20030418 telecon. We think that perhaps originator is confusing "all classes of product" with "all products". Nevertheless, the wording will be improved by: remove "all" from the checkpoint statement; and, change 1st bullet from "MUST list the classes of product it addresses" to "MUST list the classes of product for which it defines conformance requirements". See draft revised text.

accepted with modification
LC-73.4 Leonid Arbouzov Collected substantive & editorial comments: [SG-4]: Editorial (8.5, ConfReq, change "profiles").

Resolved, this has been fixed as suggested.

 accepted
LC-73.5 Leonid Arbouzov Collected substantive & editorial comments: [SG-5]: Editorial (Questions "NOT!" in GL9.)

Resolved, changed "NOT!" to "not."

 accepted
LC-73.6 Leonid Arbouzov Collected substantive & editorial comments: [SG-6]: Editorial (Typo in CP9.1)

Resolved. The typo has been fixed during the merger of 9.1 and 9.2 (which was the resolution of another, substantive issue.)

 accepted
LC-73.7 Leonid Arbouzov Collected substantive & editorial comments: [SG-7]: "Normative refs" requirement should be priority 1.

20030714 telecon directed that it be resolved as indicated in ungrouped-issue proposals: agreed, the priority of CP10.2 (now CP7.5) has been changed to 1.

accepted
LC-73.8 Leonid Arbouzov Collected substantive & editorial comments: [SG-8]: Add Rationale and Discussion to CP13.3 ("Use consistent terminology").

20030714 telecon directed that it be resolved as indicated in ungrouped-issue proposals: Agreed, a rationale has been added. See draft revised text.

accepted
LC-73.9 Leonid Arbouzov Collected substantive & editorial comments: [SG-9]: Improve definition of "test assertions" (GL14).

Discussed and resolved at 6/2003 QAWG face-to-face. QAWG will make the various definitions consistent across the GL documents and the QA Glossary, but otherwise will leave the definition more or less as it was in the initial verbiage of (Last Call) SpecGL GL14.

accepted with modification
LC-74 Lofton Henderson Simplify & consolidate the guidelines of SpecGL Considering all related guideline (GL) consolidation and reordering issues together, it was resolved to: merge (old numbers) GL3 into GL10; move current CP10.2 into GL13; move CP11.1 into GL10; merge GL11 and GL12; and reorder as GL13, GL10+GL3, GL11+GL12. See new GL7, GL8, GL9. See draft revised text. accepted with modifications
LC-79 Lofton Henderson SpecGL fails checkpoints 1.2 and 1.3 Use cases have been added to illustrate scope. The text already had (and still has) numerous examples to illustrate technical details. See draft revised text. accepted
LC-80 Lofton Henderson SpecGL should address the topic of CP applicability. No change. The proposed change is considered to be unnecessary, and possibly more confusing than useful. Confusing because it might be interpreted as relieving spec writers of the obligation to conform to the checkpoint. not accepted
LC-81 Lofton Henderson CP9.6 conformance requirements and rationale may be too narrow. CP9.6 requirements on target specifications will be revised. Rather than requiring that target specifications place the current specific conformance requirement on extension-generating implementations (for a no-extensions mode), CP9.6 will require that target specifications explicitly define a policy about implementation requirements for mitigation of the interoperability impacts of extensions. Such policy could, to cite three examples, include a requirement that implementations have a no-extensions mode; or could include a requirement that implementations include equivalent alternative (standard) content with any extensions; or could explicitly state that there are in fact no implementation requirements for mitigation of interoperability impacts of extensions. In addition, clarify that this applies only to producers of content. (@@tbd@@) accepted with modifications
LC-109 Lofton Henderson Is CP1.3 needed? CP1.3 has been merged into CP1.2, which is reworded as "Illustrate scope", and it clarified that use cases and/or examples can be used to satisfy the checkpoint. See draft revised text. accepted
LC-5 Marc Hadley Ck 2.2 list of classes This is fixed by qualifying the reference to read, "...define the conformance requirements for each class of product identified in checkpoint 2.1" See draft revised text. accepted
LC-6 Marc Hadley Guideline 2, typo This has been fixed as suggested. accepted
LC-7 Marc Hadley Checkpoint 1.2 Yes, examples and use cases can be in a separate document, that is referenced from the main document. This has been clarified. See draft revised text. accepted
LC-8 Marc Hadley checkpoint 1.1 Without specific suggestions for rewording the conformance requirements, or identification of specific problems in the existing wording, we are unsure what's wrong with them and how to change them. To help remove any ambiguity in the conformance requirements, we have improved their context -- better verbiage in the statement of the checkpoint itself, and supporting explanatory materials. See draft revised text. accepted
LC-9 Marc Hadley INTRODUCTION section 1.1, second bullet This has been fixed (2nd bullet of Scope section) to clarify and remove the confusion. See draft revised text. accepted
LC-10 Marc Hadley Section 7 Reviewer used the QA WG version of SpecGL that preceded the Last Call version, and not the LC version. Moot point. not accepted
LC-11 Marc Hadley CK 2.3 Category of object: clarification The verbiage on classes and categories is revised consistent with the 4-point proposal in email comments. The solution involves: define the terms and add them to "Definitions", introduce and separate the concepts better, move the main part of the verbiage of Guideline 2 (GL2) into a new subsection in new chapter "2. Concepts", and reference that verbiage from GL2 and its checkpoints. See draft revised text. accepted
LC-12 Marc Hadley section 3.4 Conformance definition The example has been updated to match the requirements. See draft revised text. accepted
LC-13 Marc Hadley Section 3.3 Conformance and TAs Before Candidate Recommendation, QAWG (MS) will develop a set of test assertions for SpecGL. (@@tbd... TA list & link from SpecGL ...tbd@@) accepted
LC-14 Marc Hadley CP 14.1 - clarify conformance requirement Yes, a separate document is allowed. This has been clarified, especially in the explanatory material of CP14.1 (new CP10.1). See draft revised text. accepted
LC-15 Marc Hadley extensions Closed (no issue). accepted
LC-16 Marc Hadley CP 8.4 clarify conformance requirement 8.4 will be kept, broadened to "items" instead of "choices", and final text (derived from the new proposal) will be revised and clarified by SpecGL editors. (@@tbd@@) accepted with modifications
LC-17 Marc Hadley CP 7.1 deprecated features There must be a single point of entry to find all deprecated features, as implied by the conformance requirement, "..in a normative section..". For example, this could be a subsection of the Conformance Clause. This could consist of a table or list of links to individual parts of the specification, where the deprecated features are actually defined in detail. This has been clarified. See draft revised text. accepted with modifications
LC-18 Marc Hadley GL 5 non-hierarchiacal modules What is meant is that hierarchy is not a necessary or even typical attribute of modules. This has been clarified in the new "Concepts" chapter, subsection on profiles, modules, and levels. See draft revised text. accepted with modifications
LC-19 Marc Hadley CP 4.4 explanation clarification The reference is to previous experience in both W3C and other venues. This previous experience has formed much of the profile-related checkpoint content. The wording is improved to eliminate the point of confusion. See draft revised text. accepted with modifications
LC-20 Marc Hadley CP 3.1 Conformance Requirements - clarify One section. As CP3.1 has been clarified in other issue discussion, its nature looks somewhat different. It is a summation of information that could be deduced from other individual requirements that are distributed throughout the specification (although the process could be difficult and error prone). Therefore only "single section" makes sense. This has been clarified. See draft revised text. accepted with modifications
LC-21 Marc Hadley CP 2.4 - relationships of DOV - clarify This has been addressed and further explained in a "DoV" subsection of the new chapter "2. Concepts", which is linked from the appropriate guidelines and checkpoints. See draft revised text. accepted
LC-4 Olivier Thereaux no definition for unconditional conformance This has been fixed by removing the empty definition from SpecGL. (It has been referred to the "QA Glossary" editors, to add a definition there.) accepted with modifications
LC-75.1 Patrick Curran Comments on SpecGL Guidelines: Guideline 1: Checkpoint 1.4 is priority 2, yet it's listed after 1.3 which is priority 3. I suggest listing checkpoints in priority order.

As part of the resolution of the larger issue group, CP1.3 has been merged into CP1.2 and the single checkpoint has been reworded as "Illustrate scope", so the issue becomes moot. CP1.4 (now CP1.3) is reworded as "Illustrate technical details". See draft revised text.

accepted with modification
LC-75.2 Patrick Curran Comments on SpecGL Guidelines: Guideline 3: The Conformance Policy is likely to appear towards the end of a Spec. I suggest ordering the guidelines as they are likely to appear in the spec. (Besides, it belongs with, and maybe could even be combined with, guidelines 10, 11, 12, and 13.)

Discussed and resolved at 6/2003 QAWG face-to-face. Considering all related guideline (GL) consolidation and reordering issues together, it was resolved to: merge (old numbers) GL3 into GL10; move current CP10.2 into GL13; move CP11.1 into GL10; merge GL11 and GL12; and reorder as GL13, GL10+GL3, GL11+GL12. SeeSee new GL7, GL8, GL9. See draft revised text.

accepted with modification
LC-75.3 Patrick Curran Comments on SpecGL Guidelines: Guidelines 4-9: This is a large number of guidelines and checkpoints to deal with something that's important, but that we wish to discourage (DOVs). Could we combine some or all of these guidelines?

Discussed and resolved at 20030421 telecon. It was decided to consolidate GL4-6 (profiles/modules/levels), into one guideline, while preserving the identities of profiles, modules, and levels as DoV. But otherwise, the other DoV checkpoints don't seem amenable to consolidation. See resolution summary of this and related DoV issues. See draft revised text.

accepted with modification
LC-75.4 Patrick Curran Comments on SpecGL Guidelines: The "or NOT!" language in guideline 9 seems a little too informal,

Resolved at 20030505 telecon. Agreed, "NOT!" is replaced with "not."

 accepted
LC-75.5 Patrick Curran Comments on SpecGL Guidelines: but more substantively, why do we wait until this guideline [GL9] to express our opinion that DOVs are undesirable.

Discussed and resolved at 20030421 telecon. A modified version of the previous per-GL DoV "excessive variability" caveat has been restored. See also resolution summary of this and related DoV issues. See draft revised text.

accepted
LC-75.6 Patrick Curran Comments on SpecGL Guidelines: Guideline 10: Checkpoint 10.2 doesn't seem to be directly related to the guideline.

Discussed and resolved at 6/2003 QAWG face-to-face. Considering all related guideline (GL) consolidation and reordering issues together, it was resolved to: merge (old numbers) GL3 into GL10; move current CP10.2 into GL13; move CP11.1 into GL10; merge GL11 and GL12; and reorder as GL13, GL10+GL3, GL11+GL12. See new GL7, GL8, GL9. See draft revised text.

accepted
LC-75.7 Patrick Curran Comments on SpecGL Guidelines: Guidelines 10 - 13: As suggested above, perhaps these could be combined.

Discussed and resolved at 6/2003 QAWG face-to-face. Considering all related guideline (GL) consolidation and reordering issues together, it was resolved to: merge (old numbers) GL3 into GL10; move current CP10.2 into GL13; move CP11.1 into GL10; merge GL11 and GL12; and reorder as GL13, GL10+GL3, GL11+GL12. See new GL7, GL8, GL9. See draft revised text.

accepted with modification
LC-75.8 Patrick Curran Comments on SpecGL Guidelines: Guideline 14: This is a key guideline - I'd like to see it earlier in the list.

Discussed and resolved at 6/2003 QAWG face-to-face. Taking the whole group of related guideline (GL) consolidation and reordering issues together, it was resolved to: merge GL3 into GL10; move current CP10.2 into GL13; move CP11.1 into GL10; merge GL11 and GL12. While test assertions are pivotal and early in the process in *Test* Guidelines, it is resolved that this is an appropriate placement in the *SpecGL* context.

not accepted
LC-75.9 Patrick Curran Comments on SpecGL Guidelines: Section 3.3: "This... document does not enumerate a list of test assertions". Haven't we agreed that our checklist is (the closest thing to) a list of assertions?

Discussed and closed at June QAWG face-to-face. The checklists are a test results reporting form. Recognizing that there are possibly multiple conformance requirements (CR) per checkpoint, a test material for the Guidelines documents would be something like a per-CR questionnaire, "How is this CR satisfied?".

not accepted
LC-77.1 Roger Gimson Collected substantive & editorial comments: [SG-1] More discussion of several DoV and their relationships.

Discussed and resolved at 20030421 telecon. Subsection 2.1 of the new chapter "2. Concepts" provides additional discussion about relationships amongst DoV. See draft revised text.

accepted
LC-77.2 Roger Gimson Collected substantive & editorial comments: [SG-2] Standard headings for (Framework GL?) documents.

20030714 telecon directed that it be resolved as indicated in ungrouped-issue proposals: Agree that this is a good principle and we will adhere to it, as best we can, recognizing that each Framework document may have some unique chapters. All documents will have the same core headings and in the same order: Intro, Guidelines, Conformance, Definitions (if applicable), Acknowledgements, References, Change History. No changes to SpecGL needed.

accepted with modification
LC-77.3 Roger Gimson Collected substantive & editorial comments: [ET-1] (Affects Intro, and all GL-ET pairs) Explain GL-ET pairing better.

Discussed at 20030714 telecon. Agreed, this is now handled by additional clarifying text in the GL document, and/or references to "QA Framework: Introduction". See draft revised text.

accepted
LC-77.4 Roger Gimson Collected substantive & editorial comments: [ET-2] (Affects SpecET and the other ETs). More E&T, in order to conform to SpecGL (GL1)!

Resolved: it is the QAWG intention that SpecET (Examples & Techniques) will have at least one example per checkpoint. This is queued for SpecET editors, but may lag slightly behind SpecGL publication (after the structure and checkpoint collection of SpecGL stabilizes.)

accepted
LC-77.5 Roger Gimson Collected substantive & editorial comments: [ET-3] (Affects SpecGL/ET, and the other GL/ET) Change GL, CP, and section numbering scheme.

Discussed at 20030407 telecon. Closed with resolution to leave numbering scheme as is. Reasons: given that the context is usually clear (or easily made clear), the shorter GL/CP numbers are considered both more convenient and sufficient; and, the numbering scheme is familiar from WAI specifications and has been successfully used there.

not accepted
LC-77.6 Roger Gimson Collected substantive & editorial comments: [ET-4] (Affects SpecET) When will SpecET be released? (!?)

The QAWG policy is that each new publication of SpecGL will be accompanied by a new version of SpecET (possibly lagging slightly behind the SpecGL publication). In this sense, it is already "released". SpecET may be updated and improved more frequently than SpecGL publications. It is for this reason that QAWG resolved to keep SpecET (as well as OpsET and TestET) in /QA/WG/ space as a Note. When SpecGL 1.0 has finally stabilized and stopped changing in /TR/, and when active work on SpecET is substantially over, then SpecET will be published in /TR/ (as a Note, since it is purely informative.)

accepted with modification
LC-2 Stephanie Troeth Grammatical error in Scope This has been fixed, by deleting "defines". accepted
LC-44 Stephanie Troeth Grammatical errors These editorial problems have been fixed, by removal of some text and correction of the rest. accepted
LC-45 Stephanie Troeth Design goal of guidelines This has been fixed as suggested. accepted
LC-46 Stephanie Troeth Ambiguity The verbiage on classes and categories has been revised consistent with the 4-point proposal in email comments. The verbiage has all been moved to a new subsection of the new chapter "2. Concepts", with individual sub- subsections for "specification category" and "class of product". The definitions are in "5. Definitions", and all of these bits are linked from the appropriate places in the guidelines and checkpoints. Some of the text has been rewritten to improve clarity. See draft revised text. accepted
LC-47 Stephanie Troeth Spelling error in Example and Techniques This has been referred to the SpecET editor to fix. accepted
LC-48 Stephanie Troeth Categories of object not previously clearly defined The verbiage on classes and categories has been rewritten consistent with the 4-point proposal in email comments. There is a new subsection dealing with "class of product" and "specification category" in the new chapter "2. Concepts". The concepts are defined there, added to the "Definitions" chapter, and the discussion is generally improved. The concepts and definitions are linked from their occurrences in appropriate guidelines and checkpoints. See draft revised text. accepted
LC-49 Stephanie Troeth Complexity in explanation The solution for the profile/module/level issue group should clarify the definition and better illustrate the "profile" concept. The given definition has long been in use in a number of venues. The verbiage has been re-organized and put into a separate "Concepts" section, which should improve clarity. When the companion material (and examples) in SpecET are completed, that should further help clarify the concepts. See draft revised text. accepted with modifications
LC-50 Stephanie Troeth Ambiguity or error? The text has been revised to improve readability and clarity. See draft revised text. accepted
LC-51 Stephanie Troeth GLs 4, 5 and 6 The definitions and illustrations of the three concepts -- profiles, modules, and levels -- have been consolidated and improved in one subsection of the new chapter "2. Concepts", as part of the implementation of the solution for the profile/module/level issue group. Some simple diagrams have been included as well. See draft revised text. accepted with modifications
LC-52 Stephanie Troeth NOT ? Agreed, "NOT!" has been changed to "not." accepted
LC-53 Stephanie Troeth Ambiguity The wording has been clarified to remove confusion. See draft revised text. accepted
LC-54 Stephanie Troeth GLs 3, 10, 11, 12 and 13 Considering all related guideline (GL) consolidation and reordering issues together, it was resolved to: merge (old numbers) GL3 into GL10; move current CP10.2 into GL13; move CP11.1 into GL10; merge GL11 and GL12; and reorder as GL13, GL10+GL3, GL11+GL12. See new GL7, GL8, GL9. It was decided to keep GL1 (about scope) as the first guideline, as it corresponds with the first thing that spec authors must address. See draft revised text. accepted with modifications
LC-61 Susan Lesch document product class A 'specification' class has been added. See draft revised text. accepted with modifications
LC-62 Susan Lesch typos These have been fixed. accepted
LC-63 Susan Lesch Table of Contents Changed as suggested. Subsections in TOC are now numbered N.M (M=1,2...), instead of just M. accepted
LC-64 Susan Lesch conformance terms Editorial glitch, fixed by inserting "any conformance concepts used in" at the beginning of the conformance requirements statement. See draft revised text. accepted
LC-65 Susan Lesch sentences and paragraphs (section 3.1) Agreed that there were problems here. The language in section 3.1 (now 4.1) has been improved for accuracy, and the "what's normative" list has been edited for completeness. The terms normative and informative have been linked to their (sec.5) definitions. See draft revised text. accepted
LC-66 Susan Lesch edition and version DoVs Per email proposal, version and edition are not DoV. DoV are concerned with conformance to a single, specific version/edition of a specification at a time. This detail has been clarified in the new "2. Concepts" chapter, sub-section 2.1. See draft revised text. accepted with modifications
LC-67.1 Susan Lesch limits of RFC 2119 key words:

Discussed again and resolved at 20030707 telecon. Resolution is: SpecGL (old CP13.1) will strongly encourage RFC2119 keywords as the most widely applicable and usually the best method, but exemptions are allowed, provided that: the spec unambiguously defines how its conformance requirements are identified (even if RFC2119 keywords are used); and, the rationale for not using RFC2119 keywords is explained in the spec.

accepted with modification
LC-67.2 Susan Lesch limits of RFC 2119 key words:

Discussed and resolved 2nd part -- guidance about RFC keyword usage -- at 20030421 telecon. Resolved: SpecGL won't try to legislate correct use of RFC2119 keywords. However, SpecET (Examples & Techniques) will mention that correct-use guidance is given in Section 6 of RFC2119, and will point to it. QAWG is concerned that quoting the particular wording of RFC2119 -- with reflects a particular perspective (communications & protocols) and orientation -- creates confusion rather than clarity, in some conformance contexts. There is also considerable disagreement (see the email dialogs about this issue) within W3C about the "correct use" assertions, and there is a significant body of current practice that is contrary to them. QAWG thinks that it would be useful to consider a joint Comm-QAWG project to draft a W3C guidance Note on this topic.

accepted with modification