[SVGT12 Comment] QA Review - 20040813 version

Hi,

This is my review of
Mobile SVG Profile: SVG Tiny, Version 1.2
W3C Working Draft 13 August 2004
http://www.w3.org/TR/2004/WD-SVGMobile12-20040813/

Against:
QA Framework: Specification Guidelines
W3C Working Draft 30 August 2004
http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/

The QA Framework Specification Guidelines has been largely reorganized 
to be easier to adopt and follow. It's now a practical document which 
invites you to go through a certain number of questions. My review has 
the intention to help you to push further the quality of your document.

There is an Implementation Conformance Statement that will help you to 
check if you are following the principles of QA Spec Guidelines. Only 
The principles are mandatory, though the more good practices you 
follow, the better the quality of your specification document will be.
http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/specgl-ics

Yes ICS-001-Pr: Include a conformance clause
Yes ICS-002-GP: Define the specification conformance model in the 
conformance clause
Yes ICS-003-GP: Specify in the conformance clause how to distinguish 
normative from informative content.
	Comment: Though it can be improved. There's no way to know if you rely 
only on the RFC 2119 or if there others subtleties. For example, you 
use terms like "support", or "do not support".
No  ICS-004-GP: Provide the wording for conformance claims.
No  ICS-005-GP: Provide an Implementation Conformance Statement (ICS) 
proforma.
No  ICS-006-GP: Require an Implementation Conformance Statement (ICS) 
as part of valid conformance claims.
Yes ICS-007-Pr: Define the scope
Yes ICS-008-GP: Write simple, direct statements in the scope.
	Comment: Would it be better if you had a scope section and a little 
bit more detailed.
No  ICS-009-GP: Use examples or use cases to illustrate
	Comment: There is only example. Maybe more example could help. Though 
we understand it's a profile. Maybe a link to the appropriate example 
in the specification each time it's necessary
Yes ICS-010-Pr: Identify who or what will implement the specification
	Comment: A more detailed description would be good.
Yes ICS-011-Pr: Define the terms used in the normative parts of the 
specification
	Comment: Are you sure all your terms are defined. For now, it is 
necessary to go the core technological specification.
Yes ICS-012-Pr: Create conformance labels for each part of the 
conformance model
	Comment: You could give a more explicit conformance label for each 
class of product.
Yes ICS-013-GP: define the terms in-line, and consolidate the 
definitions in a glossary section
	Comment: ok, if the terms are already defined in the core 
specification.
Yes ICS-014-GP: Re-use existing terms, and don't redefine them
Yes ICS-015-Pr: Use a consistent style for conformance requirements and 
explain how to distinguish them
No  ICS-016-Pr: Explain which conformance requirements are mandatory, 
which are suggested and which are optional
	Comment: It's not clear enough when something is required or not.
N/A ICS-017-GP: Subdivide the technology to foster implementation
	Comment: this document is already the result of subdividing a 
technology
Yes ICS-018-Pr: If the technology is subdivided, then indicate which 
subdivisions are mandatory for conformance
Yes ICS-019-Pr: If the technology is subdivided, then address 
subdivision conditions or constraints
N/A ICS-020-GP: Define rules for creating profiles
	Comment: This is a profile. Though it can be good in SVG to explain 
how to create profiles.
Yes ICS-021-GP: Determine the need for each option. Make sure there is 
a real need for the option.
Yes ICS-022-GP: Indicate any limitations or constraints
No  ICS-023-GP: Address the impact of the option
	Comment: Have you think about it? I put a "No" here just to encourage 
you to address the issue.
No  ICS-024-GP: Make options easy to find. Use tags to label options.
N/A ICS-025-Pr: Address the extensibility topic inside specification.
	Comment: It's a profile
N/A ICS-026-GP: Define the extension mechanism
N/A ICS-027-Pr: Prevent extensions from breaking conformance
N/A ICS-028-GP: Define error handling for unknown extensions.
N/A ICS-029-Pr: Identify each deprecated feature.
N/A ICS-030-Pr: Define how to handle each deprecated feature
N/A ICS-031-GP: Explain how to avoid using a deprecated feature
N/A ICS-032-GP: Identify obsolete features
No  ICS-033-GP: Define an error handling mechanism
	Comment: Is there an error handling mechanism in SVG. If yes is it 
still consistent with this profile. If the aswer is yes to these two 
remarks, you can switch to yes.
*   ICS-034-Pr: Do quality control during the specification development.
	Comment: Only you can answer that question.
*   ICS-035-GP: Do a systematic and thorough review.
*   ICS-036-GP: Write sample code or tests.
	Comment: has it been done?
N/A ICS-037-GP: Write Test Assertions.
  	Comment: this is a profile.



* KD-001: There's a typo, which makes it difficult to find conformance 
;)
	Appendix F. SVG Tiny Confirmance Criteria

* KD-002: 
http://www.w3.org/TR/2004/WD-SVGMobile12-20040813/#sec-structure
	"""The following is an example of an SVG document fragment embedded 
within an XHTML 1.1 document:"""
	Hmm... It's not an XHTML 1.1 document, but a XHTML Family document 
defined with the rules of XHTML Modularization.


-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***