Review implementation support - Conformance Criteria

[AmeliaBR]

• Chapter 2, Conformance Criteria, in SVG2 ED
• Compare with Appendix G of SVG 1.1
• Changes list

Status of Changes Requiring Implementation

• Animations do not run in documents processed as resource documents.

  Needs tests. I believe this matches all implementations.

• Define required processing modes for different types of SVG cross-references, with suggested processing modes for similar references from HTML/CSS. (Replaces the "referencing modes" section from SVG Integration.)

  Needs tests, at least of the SVG-specific bits (e.g., an SVG document integrated in another SVG as an <image>). Implementation should be good, since this is spec'd to match implementations. Could use the example in 2.3.1 as a manual test, for starters.

Other aspects requiring testing

This chapter includes conformance requirements for authoring tools, servers, and other software types, as well as conformance/validation requirements for SVG files.

I'm not sure how we can best test all these cases.

Many of the conformance requirements are references to other specifications (e.g., the viewer must support data URLs, the viewer must support CSS 2.1 syntax and parsing, ). I don't think we need SVG-specific tests for these, although they would be helpful for non-browser rendering environments that can only work with .svg files, not .html.

There are also conformance requirements that are only mentioned in this chapter. Specifically the precision requirements, and requirements for accessible interactivity.

Most of the requirements (including requirements to support other specs) haven't changed from SVG 1.1 except to update cross-references (although the content has been reorganized significantly). However, that doesn't mean they were ever well implemented.

In addition, the following points affect the interpretation of all other rendering tests:

• The viewer must use at least single-precision floating point for intermediate calculations on any numerical operations for conversion of coordinates. However, in order to prevent the rounding error on coordinate transformation, at least double-precision floating point computation must be used on CTM generation processing.

• All visual rendering must be accurate to within one device pixel or point of the mathematically correct result at the initial 1:1 zoom ratio.

• On systems which support accurate sRGB [SRGB] color, all sRGB color computations and all resulting color values must be accurate to within one sRGB color component value, where sRGB color component values range from 0 to 255.

More thoughts

The W3C process and testing requirements are all based on the assumption that an entire spec will be implemented by a given class of software.

But this chapter is all about dividing up all possible SVG implementations and contexts according to which parts of this spec & referenced specs that software is expected to implement.

One consequence of that is that it would be helpful to be able to annotate tests (from all chapters) with information about which processing modes & software categories it applies to.

But I'm not sure how that affects W3C process implementation expectations.

E.g., I'm not sure if any existing SVG user agents meet all the qualifications of a "Conforming High-Quality SVG Viewer", but I'm not sure that this should prevent us from defining that category of hypothetical software.

(Part of #487 Master issue)