- From: Lofton Henderson <lofton@rockynet.com>
- Date: Sun, 02 Jan 2005 12:40:02 -0700
- To: www-qa-wg@w3.org
Review of SVG11: http://www.w3.org/TR/SVG11/ , according to the emailed text ICS of SpecGL http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/ First the 13 Requirements, followed by the 25 GPs... >=============================== >* 13 Requirements (Normative) * >=============================== Of the 13 normative Requirements: YES -- 9; NO -- 2 (technically, SVG11 probably fails the deprecation requirements, because of a single deprecation obscurely hidden in Appendix O); can't decide -- 2 -- (I am unable to decide the answer [y/n/na] because of the way SVG11 modularizes, but leaves profile definition to other specifications (e.g. Mobile11)). >1.1.A: Include a conformance clause. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#include-conformance-clause-principle >YES/NO/Not Applicable: Explain why? YES. In normative Appendix G: http://www.w3.org/TR/SVG11/conform.html >2.1.A: Define the scope. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#define-scope-principle >YES/NO/Not Applicable: Explain why? YES (partially), the scope is effectively described in the Introduction, http://www.w3.org/TR/SVG11/intro.html#AboutSVG , lacking only the keyword "scope" and the suggested technique of a Scope entry in the TOC. >2.2.A: Identify who or what will implement the specification. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#implement-principle >YES/NO/Not Applicable: Explain why? YES. The classes of product are clearly and precisely defined in the Confo. clause (& its TOC): http://www.w3.org/TR/SVG11/conform.html Contrary to the SpecGL suggested technique, it is not dealt with in the scope definition of the Introduction (doing that would be a minor improvement, but I think the SVG Confo. clause is the important bit.). NOTE. I think the wording of this Requirement is too lax and misleading, altho' the "What means" does focus on CoP and conformance. >2.3.A: Make a list of normative references. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#ref-norm-principle >YES/NO/Not Applicable: Explain why? YES, normative (& informative) references are concisely listed here, http://www.w3.org/TR/SVG11/refs.html , and the relationships are discussed here, http://www.w3.org/TR/SVG11/intro.html#W3CCompatibility >3.1.A: Define the terms used in the normative parts of the >specification. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#define-terms-principle >YES/NO/Not Applicable: Explain why? YES, there is a glossary with lots of terms here, http://www.w3.org/TR/SVG11/intro.html#Definitions >3.1.B: Create conformance labels for each part of the conformance model. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#conf-label-principle >YES/NO/Not Applicable: Explain why? YES, the Conformance Clause defines types of conformance, along with its definitions of the CoPs: http://www.w3.org/TR/SVG11/conform.html >3.2.A: Use a consistent style for conformance requirements and explain >how to distinguish them. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#consistent-style-principle >YES/NO/Not Applicable: Explain why? YES (partially), conformance requirements come from a combination of use of RFC 2119 keywords, which is well defined, http://www.w3.org/TR/SVG11/intro.html#Terminology , and description of graphical semantics of SVG's elements and properties. The latter is not explicitly identified as normative content of SVG11, but that can probably reasonably be inferred by the conformance requirements of "Conforming SVG viewer" (etc.) in the Conformance Clause, http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers >3.2.B: Indicate which conformance requirements are mandatory, which are >recommended and which are optional. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#req-opt-conf-principle >YES/NO/Not Applicable: Explain why? YES, the use of RFC keywords, and intent to separate mandatory from optional, is well-described here: http://www.w3.org/TR/SVG11/intro.html#Terminology . Whether the specification adheres to this intent is difficult to determine -- it is 6.6MB of PDF text, so an external reviewer won't be able to determine consistent adherence to intent. >4.1.B: If the technology is subdivided, then indicate which >subdivisions are mandatory for conformance. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#subdivide-mandatory-principle >YES/NO/Not Applicable: Explain why? Uncertain of answer. SVG11 defines a modularization of SVG, http://www.w3.org/TR/SVG11/intro.html#Modularization . But mandatory modules are not addressed, and the modularization is defined for the use of other specifications, to write profiles: http://www.w3.org/TR/SVG11/intro.html#Profiling In particular, the separate specification SVG Mobile 1.1 defines Tiny, Basic, and Full profiles. That not withstanding, "Full" mentioned in the SVG11 Profiling sub-section, as being equivalent to all of SVG (i.e., the union of all of the modules). So I'm uncertain how to answer the question as stated in SpecGL, because of the partitioning of SVG11 and Mobile11. Note. Also, I don't understand this: http://www.w3.org/TR/SVG11/intro.html#ElementAndAttributeCollections >4.1.C: If the technology is subdivided, then address subdivision >constraints. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#subdiv-constraints-principle >YES/NO/Not Applicable: Explain why? Again, uncertain of answer. See above. SVG11 defines a modularization only so that it may be used by other specifications to assemble modules into profiles, e.g., Mobile11. There is, in the three SVG11 sub-sections on modularization, collections, and profiles, a little bit of speculation about how the modules might be used. But not much in the way of explicit constraints. Note. I don't think that the second example of 4.1.C relates to the topic of this point. Someone has defined a profile of XHTML+SMIL+SVG, as a document independent of any of the three standards. I don't think that reflects on subdivision constraints. >4.3.A: Address Extensibility. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#likehood-extension-principle >YES/NO/Not Applicable: Explain why? YES. http://www.w3.org/TR/SVG11/extend.html Note. SpecGL says, "1. Create a section in the specification dedicated to extensibility; 2. Call it Extensions". Why not "Call it Extensibility?" It seems silly to dedicate it to extensibility and title it "Extensions". >4.4.A: Identify deprecated features. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#deprecated-feature-principle >YES/NO/Not Applicable: Explain why? NO. (?) There is a single deprecated feature in 1.1 (because it is basically 1.0 modularized, plus errata). I found it by searching PDF version for "deprecate", hidden in Appendix O. It is not "listed" or called out in some central location (such as conf. clause). >4.4.B: Define how deprecated feature is handled by each class of >product. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#degree-support-principle >YES/NO/Not Applicable: Explain why? NO. (See previous.) >===================================== >* 25 Good Practices (Not normative) * >===================================== SVG11 score on the 25 GPs: YES -- 9 NO -- 7 N/A -- 1 Can't tell -- 6 Some of the "can't tell" are because I couldn't figure out how to answer y/n/na for the particular GP. Some of the "can't tell" are because the GP is written as a process requirement. Therefore not ascertainable to an external reviewer. (Since I have been involved with SVG, I could guess an answer as an insider. But ... if it's not reflected in the spec for all to see, I put "can't tell"). >1.1.B: Define the specification's conformance model in the conformance >clause. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#conformance-model-gp >YES/NO/Not Applicable: Explain why? YES. See http://www.w3.org/TR/SVG11/conform.html. (The third bullet of this GP, opt/ext in Conformance Clause, isn't satisfied. But the others are.) >1.1.C: Specify in the conformance clause how to distinguish normative >from informative content. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#norm-informative-gp >YES/NO/Not Applicable: Explain why? NO. (Or more generously, "partial"...) RFC2119 language is specified, but not in the conformance clause. Use of normative prose for graphical semantics descriptions is not explicitly identified. Some, but not all, sections are labelled norm/inform. >1.2.A: Provide the wording for conformance claims. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#conformance-claim-gp >YES/NO/Not Applicable: Explain why? NO. >1.2.B: Provide an Implementation Conformance Statement proforma. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#ics-gp >YES/NO/Not Applicable: Explain why? NO. >1.2.C: Require an Implementation Conformance Statement as part of valid >conformance claims. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#ics-claim-gp >YES/NO/Not Applicable: Explain why? NO. >2.1.B: Provide examples, use cases, and graphics. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#use-example-gp >YES/NO/Not Applicable: Explain why? YES. (Copious and helpful examples throughout.) >2.3.B: Do systematic reviews of normative references and their >implications. >http://w3c.test.site/TR/2004/WD-qaframe-spec-20041122/#ref-define-practice >YES/NO/Not Applicable: Explain why? Can't tell. (This is written as process, therefore non-WG external reviewer can't tell. However, the evidence of compliance -- very specific normative references -- is NOT visible.) >3.1.C: Define the unfamiliar terms in-line, and consolidate the >definitions in a glossary section. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#define-terms-inline-gp >YES/NO/Not Applicable: Explain why? YES. There is a glossary, and in-line references to it (but not much in-line definition per se). >3.1.D: Use terms already defined without changing their definition. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#reuse-terms-gp >YES/NO/Not Applicable: Explain why? Can't tell. (This is written as process, therefore non-WG external reviewer can't tell. However, the evidence of compliance -- very specific normative references -- is NOT visible.) >4.1.A: Create subdivisions of the technology when warranted. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#subdivide-foster-gp >YES/NO/Not Applicable: Explain why? YES. (Word that are in glossary are linked to glossary definitions when the words are used.) Note. This would be impractical for a non-WG external reviewer to verify that it is *always* satisfied, given that the text of SVG11 is 6.6MB of PDF. >4.1.D: If the technology is profiled, define rules for creating new >profiles. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#rules-profiles-gp >YES/NO/Not Applicable: Explain why? NO. A more generous answer might be "partial yes" -- the use of modularization to write profiles is discussed and some guidance is suggested, but I wouldn't call these "rules": http://www.w3.org/TR/SVG11/intro.html#Profiling >4.2.A: Make sure there is a need for the optional feature. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#need-option-gp >YES/NO/Not Applicable: Explain why? Can't tell. (This is written as process, therefore non-WG external reviewer can't tell.) >4.2.B: Clearly identify optional features. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#label-options-gp >YES/NO/Not Applicable: Explain why? YES. SVG11 generally does a reasonable job of identifying optional features, including using the RFC2119 keyword "optional". But it would be a BIG improvement to have a central list somewhere, given the size and complexity of SVG11. >4.2.C: Indicate any limitations or constraints on optional features. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#constraints-gp >YES/NO/Not Applicable: Explain why? Can't tell. "optional" search results in 74 hits in SVG11. Not all correspond to optional features. Most are optional attributes. Spot-checking a few, I can't decide about the answer to the list of questions in this GPs Techniques. >4.3.B: If extensibility is allowed, define an extension mechanism. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#extensions-prohibited-gp >YES/NO/Not Applicable: Explain why? YES. http://www.w3.org/TR/SVG11/extend.html >4.3.C: Warn implementers to create extensions that do not interfere >with conformance. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#breaking-conformance-gp >YES/NO/Not Applicable: Explain why? NO. (Extensibility chapter doesn't warn against extensions altering standardized functionality.) >4.3.D: Define error handling for unknown extensions. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#define-error-gp >YES/NO/Not Applicable: Explain why? NO. More generous might be "partial". You'd get a partial answer if you read these two... http://www.w3.org/TR/SVG11/extend.html http://www.w3.org/TR/SVG11/implnote.html#ErrorProcessing but the case of a not-understood, properly-formed extension is not addressed. >4.4.C: Explain how to avoid using a deprecated feature. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#workaround-gp >YES/NO/Not Applicable: Explain why? N/A. (There is only one suggestion of deprecation, in Appendix O, and this GP seems N/A to that case.) >4.4.D: Identify obsolete features. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#obsolete-gp >YES/NO/Not Applicable: Explain why? N/A. (There are no obsolete features in SVG11). >4.5.A: Define an error handling mechanism. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#error-handling-gp >YES/NO/Not Applicable: Explain why? YES. http://www.w3.org/TR/SVG11/implnote.html#ErrorProcessing >5.A: Define an internal publication and review process. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#practice-principle >YES/NO/Not Applicable: Explain why? Can't tell. (This is written as process, therefore non-WG external reviewer can't tell.) >5.B: Do a systematic and thorough review. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#review-gp >YES/NO/Not Applicable: Explain why? Can't tell. (This is written as process, therefore non-WG external reviewer can't tell.) >5.C: Write sample code or tests. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#write-sample-gp >YES/NO/Not Applicable: Explain why? YES (partial). Examples can be seen in text. Test suite is publicly available, and tends to have one test per major feature. Note. With other bits of this GP's Techniques, "can't tell" is the only possible answer for a non-WG external reviewer -- bits of the GP are written as process, therefore not externally and independently verifiable. >5.D: Write Test Assertions. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#write-assertion-gp >YES/NO/Not Applicable: Explain why? NO. >5.E: Use formal languages and define which from prose and formal >languages has priority. >http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#formal-language-gp >YES/NO/Not Applicable: Explain why? YES (partial). Other than DTD, there is some BNF for particular bits of functionality. There is no definition of how to resolve conflict between DTD, BNF, and prose (i.e., which has precedence). ### end ###
Received on Sunday, 2 January 2005 19:40:30 UTC