W3C home > Mailing lists > Public > www-qa-wg@w3.org > January 2005

SVG11 / SpecGL review assignment

From: Lofton Henderson <lofton@rockynet.com>
Date: Sun, 02 Jan 2005 12:40:02 -0700
Message-Id: <>
To: www-qa-wg@w3.org

Review of SVG11:  http://www.w3.org/TR/SVG11/ ,
according to the emailed text ICS of SpecGL

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.
>YES/NO/Not Applicable: Explain why?

In normative Appendix G:

>2.1.A: Define the scope.
>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.
>YES/NO/Not Applicable: Explain why?

YES.  The classes of product are clearly and precisely defined in the 
Confo. clause (& its TOC):
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.
>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,

>3.1.A: Define the terms used in the normative parts of the
>YES/NO/Not Applicable: Explain why?

YES, there is a glossary with lots of terms here,

>3.1.B: Create conformance labels for each part of the conformance model.
>YES/NO/Not Applicable: Explain why?

YES, the Conformance Clause defines types of conformance, along with its 
definitions of the CoPs:

>3.2.A: Use a consistent style for conformance requirements and explain
>how to distinguish them.
>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,

>3.2.B: Indicate which conformance requirements are mandatory, which are
>recommended and which are optional.
>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.
>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:
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:

>4.1.C: If the technology is subdivided, then address subdivision
>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 

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.
>YES/NO/Not Applicable: Explain why?


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.
>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
>YES/NO/Not Applicable: Explain why?

(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
>YES/NO/Not Applicable: Explain why?

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.
>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.
>YES/NO/Not Applicable: Explain why?


>1.2.B: Provide an Implementation Conformance Statement proforma.
>YES/NO/Not Applicable: Explain why?


>1.2.C: Require an Implementation Conformance Statement as part of valid
>conformance claims.
>YES/NO/Not Applicable: Explain why?


>2.1.B: Provide examples, use cases, and graphics.
>YES/NO/Not Applicable: Explain why?

(Copious and helpful examples throughout.)

>2.3.B: Do systematic reviews of normative references and their
>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.
>YES/NO/Not Applicable: Explain why?

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.
>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.
>YES/NO/Not Applicable: Explain why?

(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
>YES/NO/Not Applicable: Explain why?


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":

>4.2.A: Make sure there is a need for the optional feature.
>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.
>YES/NO/Not Applicable: Explain why?

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.
>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.
>YES/NO/Not Applicable: Explain why?


>4.3.C: Warn implementers to create extensions that do not interfere
>with conformance.
>YES/NO/Not Applicable: Explain why?

(Extensibility chapter doesn't warn against extensions altering 
standardized functionality.)

>4.3.D: Define error handling for unknown extensions.
>YES/NO/Not Applicable: Explain why?


More generous might be "partial".  You'd get a partial answer if you read 
these two...
but the case of a not-understood, properly-formed extension is not addressed.

>4.4.C: Explain how to avoid using a deprecated feature.
>YES/NO/Not Applicable: Explain why?

(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.
>YES/NO/Not Applicable: Explain why?

(There are no obsolete features in SVG11).

>4.5.A: Define an error handling mechanism.
>YES/NO/Not Applicable: Explain why?


>5.A:   Define an internal publication and review process.
>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.
>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.
>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.
>YES/NO/Not Applicable: Explain why?


>5.E:   Use formal languages and define which from prose and formal
>languages has priority.
>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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:38 UTC