This document has been announced on the SVG Mailing-List on November 22, 2004.
This is a review of the SVG 1.2 Last Call, version 27 October 2004, specification against QA Specification Guidelines, Version 22 November 2004. The review has been written by Karl Dubost, QA WG chair and W3C Conformance Manager and achieved on 23 November 2004.
The specification is so far of any kind of minimum quality criteria, that I didn't try to evaluate the Good Practices, and I have just focus on the 9 mandatory principles, only 9.
To be conformant to Specification Guidelines, you only have to fulfil all the principles, though having more points filled can only be benefitial for the technology.
|1 Specifying Conformance|
|1.1 A conformance clause is essential|
|Requirement : Include a conformance clause.||
There is no conformance clause in the document, there is no table of content items refering to the conformance clause. The only of conformance is in the introduction which we don't know if it's normative or not with the following text.
There's no link to the conformance section of SVG 1.1. In the constraints defined in the introduction, the WG mentions that there's no DTD (official is completely useless in this context, there's one or not) and at the same time, the WG does not impose the validation against the RelaxNG Schema mandatory. Then how it is possible to define a validating conforming user agent of SVG 1.2.
The RelaxNG document is not under TR/ space then subject to change, and then subject to modifications of the notion of conformance. That's bad.
|Good Practice : Define the specification's conformance model in the conformance clause.|
|Good Practice : Specify in the conformance clause how to distinguish normative from informative content.|
|1.2 Specify how to make conformance claims|
|Good Practice : Provide the wording for conformance claims.|
|Good Practice : Provide an Implementation Conformance Statement proforma.|
|Good Practice : Require an Implementation Conformance Statement as part of valid conformance claims.|
|2. Setting up Groundrules|
|Requirement : Define the scope.||
There is no scope section nor prose explaining what the specification is about. It defines in the introduction in a way which don't know if it's mandatory or not that is an extension of SVG 1.1 with no proper links to the relevant section of SVG 1.1 explaining what SVG 1.1 is about. In consequence, there's no table of content item going to the scope section.
|Good Practice : Provide examples, use cases, and graphics.|
|2.2 What needs to conform|
|Requirement : Identify who or what will implement the specification.||
Again there's no way to know who, what, etc. will implement the specification. Nothing explaining the classes of products, the context, etc.
|2.3 Normative (and non-normative) references|
|Requirement : Make a list of normative references.||
The text makes extensive references to other specifications, like xSBL, CSS3 Text Module. There is no list at all of normative references. There is a list of references, but we don't know which ones of them are normative or not, which ones have to be carefully considered to implement SVG 1.2. For example, it's not recommended to make a normative reference to a technology which is itself not normative. The references givent in the list are not dated URIs reference, which means there's no way to know which version of the specification SVG is referring to.
When a reference is cited, it doesn't follow the Manual of Style recommendation, which makes the citation accessible to the user for example when printing the document. Worse than that sometimes SVG limits the features of the referred specification without defining clearly the conformance model of SVG and with a possibility of breaking the conformance model of the referred specification. for example, in 4.14.1 The text-align property, the text uses CSS3 Text Module but limits it
Note that SVG does not allow the value "string" for this property, and that the values "left" and "right" have been removed as they do not make sense in an internationalized context.
It basically means that a SVG user agent can't be conformant CSS 3 Text Module and SVG 1.2 at the same time
|Good Practice : Do systematic reviews of normative references and their implications.|
|4. Managing Variability|
|Good Practice : Create subdivisions of the technology when warranted.|
|Requirement : If the technology is subdivided, then indicate which subdivisions are mandatory for conformance.||
We believe that SVG 1.2 is organized with modules, but there's nothing in the document which explains the structural division of this document, modules, levels and how they interact with the conformance section.
|Requirement : If the technology is subdivided, then address subdivision constraints.||
See previous comment.
|Good Practice : If the technology is profiled, define rules for creating new profiles.|
|4.2 Optionality and Options|
|Good Practice : Make sure there is a need for the optional feature.|
|Good Practice : Clearly identify optional features.|
|Good Practice : Indicate any limitations or constraints on optional features.|
|4.3 Extensibility and Extensions|
|Requirement : Address Extensibility.||
It seems for example, that SVG 1.2 discourages extensibility, but it's not sure and it's not explained anywhere. The creation of new profiles is also discouraged, but there no way to know how does it relate to the conformance of the document, which doesn't exist.
|Good Practice : If extensibility is allowed, define an extension mechanism.|
|Good Practice : Warn implementers to create extensions that do not interfere with conformance.|
|Good Practice : Define error handling for unknown extensions.|
|Requirement : Identify deprecated features.||
Are there deprecated features?
In the chapter 10, I can read that:
|Requirement : Define how deprecated feature is handled by each class of product.||
It's not explained at all. Classes of products are not defined as well.
|Good Practice : Explain how to avoid using a deprecated feature.|
|Good Practice : Identify obsolete features.|
|4.5 Error Handling|
|Good Practice : Define an error handling mechanism.|
|5. Do Quality Control|
|Good Practice : Define an internal publication and review process.|
|Good Practice : Do a systematic and thorough review.|
|Good Practice : Write sample code or tests.|
|Good Practice : Write Test Assertions.|
|Good Practice : Use formal languages and define which from prose and formal languages has priority.|