D Conformance Criteria

D.1 Introduction

D.2 Terminology

Within this specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 (see [RFC2119]). However, for readability, these words do not appear in all uppercase letters in this specification.

At times, this specification recommends good practice for authors and user agents. These recommendations are not normative and conformance with this specification does not depend on their realization. These recommendations contain the expression "We recommend ...", "This specification recommends ...", or some similar wording.

All examples are informative, not normative. In the case of a conflict between the prose of this specification and the RelaxNG schema, the prose is authoritative (for example, the prose description of some attributes has a BNF grammar for allowed values, which the RelaxNG is not able to express). Similarly in the case of a conflict between a DTD or W3C XML Schema and the RelaxNG schema, the RelaxNG is authoritative (RelaxNG can express some constraints on content models that are problematic to express in W3C XML schema, and expresses namespaces in a natural and more general way than a DTD is able to).

D.3 SVG Content Conformance

<rules xmlns='http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0'>
   <namespace ns='http://www.w3.org/2000/svg'>
     <validate schema='Tiny-1.2.rng'>
       <mode>
         <namespace ns='http://www.w3.org/2000/svg' match='attributes'>
           <reject/>
         </namespace>
         <namespace ns='' match='attributes'>
           <attach/>
         </namespace>
         <namespace ns='http://www.w3.org/1998/xml' match='attributes'>
           <attach/>
         </namespace>
         <namespace ns='http://www.w3.org/1999/xlink' match='attributes'>
           <attach/>
         </namespace>
         <namespace ns='http://www.w3.org/2001/xml-events' match='attributes'>
           <attach/>
         </namespace>
         <anyNamespace match='elements attributes'>
           <mode>
             <anyNamespace>
               <allow/>
             </anyNamespace>
           </mode>
         </anyNamespace>
       </mode>
     </validate>
   </namespace>
</rules>
        

D.3.2 Conforming SVG Stand-Alone Documents

A document is a Conforming SVG Stand-Alone Document if:

• it conforms to the criteria for Conforming SVG Document Fragment; and
• its root element is an 'svg' element in the SVG namespace.

D.3.3 Conforming SVG Included Document Fragments

SVG document fragments can be included within parent XML documents using the XML namespace facilities described in Namespaces in XML 1.1.

An SVG document fragment that is included within a parent XML document is a Conforming Included SVG Document Fragment if the SVG document fragment, when taken out of the parent XML document, conforms to the criteria for Conforming SVG Document Fragments.

In particular, note that individual elements from the SVG namespace cannot be used by themselves. Thus, the SVG part of the following document is not conforming:

<?xml version="1.0" standalone="no"?>
<ParentXML xmlns="http://ns.example/">
   <!-- Elements from ParentXML go here -->
   <!-- The following is not  conforming -->
   <z:rect xmlns:z="http://www.w3.org/2000/svg"
             x="0" y="0" width="10" height="10"/>
   <!-- More elements from ParentXML go here -->
</ParentXML>
      

Instead, for the SVG part to become a Conforming Included SVG Document Fragment, the document could be modified as follows:

<?xml version="1.0" standalone="no"?>
<ParentXML xmlns="http://ns.example/">
   <!-- Elements from ParentXML go here -->
   <!-- The following is conforming -->
   <z:svg xmlns:z="http://www.w3.org/2000/svg"
          width="100px" height="100px" >
     <z:rect x="0" y="0" width="10" height="10" />
   </z:svg>
   <!-- More elements from ParentXML go here -->
</ParentXML>
    

D.4 SVG Writer Conformance

D.4.1 Conforming SVG Generators

A Conforming SVG Generator is a program which:

• always creates at least one of Conforming SVG Document Fragments, Conforming SVG Stand-Alone Files or Conforming SVG Included Documents.
• does not create non-conforming SVG document fragments of any of the above types.

SVG generators are encouraged to follow W3C developments in the area of internationalization. Of particular interest is the W3C Character Model and the concept of Webwide Early Uniform Normalization, which promises to enhance the interchangability of Unicode character data across users and applications. Future versions of the SVG specification are likely to require support of the W3C Character Model in Conforming SVG Generators.

D.4.2 Conforming SVG Authoring Tools

Conforming SVG Authoring Tools must meet all the requirements of a Conforming SVG Generator. Additionally, a Conforming SVG Authoring Tool must conform to all of the Priority 1 accessibility guidelines from the document "Authoring Tool Accessibility Guidelines 1.0" [ATAG] that are relevant to generators of SVG content. (Priorities 2 and 3 are encouraged, but not required for conformance.)

D.4.3 Conforming SVG Servers

Conforming SVG Servers must meet all the requirements of a Conforming SVG Generator. In addition, Conforming SVG Servers using HTTP or other protocols that use Internet Media types must serve SVG stand-alone files with the media type image/svg+xml. Also, if the SVG is compressed with gzip or deflate, Conforming SVG Servers must indicate this with the "Content-Encoding: gzip" or "Content-Encoding: deflate" headers, as appropriate.

D.5 Conforming SVG Readers

D.5.1 Conforming SVG Interpreters

An SVG interpreter is a program which can parse and process SVG document fragments. Examples of SVG interpreters are server-side transcoding tools (e.g., a tool which converts SVG content into modified SVG content) or analysis tools (e.g., a tool which extracts the text content from SVG content). An SVG viewer also satisfies the requirements of an SVG interpreter in that it can parse and process SVG document fragments, where processing consists of rendering the SVG content to the target medium.

In a Conforming SVG Interpreter, the XML parser must be able to parse and process all XML constructs defined within [XML10] and [XML-NS].

There are two sub-categories of Conforming SVG Interpreters:

• Conforming Static SVG Interpreters must be able to parse and process the static language features of SVG that correspond to the feature string "http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-static" (see Feature strings).
• In addition to the requirements for the static category, Conforming Dynamic SVG Interpreters must be able to parse and process the language features of SVG that correspond to the feature string "http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-dynamic" (see Feature strings) and which support all of the required features in the SVG DOM described in this specification.

A Conforming SVG Interpreter must parse any SVG document correctly. It is not required to interpret the semantics of all features correctly. It needs only check the syntax of attribute values on elements in the SVG namespace, and element content models in the SVG namespace that it knows about from the profile it implements (SVG Tiny 1.2).

Note: A transcoder from SVG into another graphics representation, such as an SVG-to-raster transcoder, represents a viewer, and thus viewer conformance criteria apply. (See Conforming SVG Viewers.)

D.5.2 Conforming SVG Viewers

An SVG viewer is a program which can parse and process an SVG document fragment and render the contents of the document onto some sort of output medium such as a display or printer; thus, an SVG Viewer is also an SVG Interpreter.

There are two sub-categories of Conforming SVG Viewers:

• Conforming Static SVG Viewers support the static language features of SVG that correspond to the feature string "http://www.w3.org/TR/SVG11/feature#SVG-static" (see Feature strings). This category often corresponds to platforms and environments which only render static documents, such as printers.
• Conforming Dynamic SVG Viewers support the language features of SVG that correspond to the feature string "http://www.w3.org/TR/SVG11/feature#SVG-dynamic" (see Feature strings). This category often applies to platforms and environments such as common Web browsers which support user interaction and dynamic document content (i.e., documents whose content can change over time). (User interaction includes support for hyperlinking, events [e.g., mouse clicks], text selection, zooming and panning [see Interactivity]. Dynamic document content can be achieved via declarative animation or by scripts modifying the SVG DOM.)

Specific criteria that apply to both Conforming Static SVG Viewers and Conforming Dynamic SVG Viewers:

• The program must also be a Conforming SVG Interpreter,
• For interactive user environments, facilities must exist for zooming and panning of stand-alone SVG documents or SVG document fragments embedded within parent XML documents.
• In environments that have appropriate user interaction facilities, the viewer must support the ability to activate hyperlinks.
• If printing devices are supported, SVG content must be printable at printer resolutions with the same graphics features available as required for display (e.g., the specified colors must be rendered on color printers).
• On systems where this information is available, the parent environment must provide the viewer with information about physical device resolution. In situations where this information is impossible to determine, the parent environment shall pass a reasonable value for device resolution which tends to approximate most common target devices.
• The viewer must support JPEG/JFIF [JPEG] [JFIF] and PNG [PNG] image formats. Other image formats may be supported in addition.
• Resampling of image data must be consistent with the specification of property 'image-rendering'.
• The viewer must support alpha channel blending of the image of the SVG content onto the target canvas.
• SVG implementations must correctly support gzip-encoded and deflate-encoded SVG data streams. SVG implementation that support HTTP must support these encodings according to the HTTP 1.1 specification [RFC2616]; in particular, the client must specify with an "Accept-Encoding:" request header [ HTTP-ACCEPT-ENCODING] those encodings that it accepts, including at minumum gzip and deflate, and then decompress any gzip-encoded and deflate-encoded data streams that are downloaded from the server. If the implementation supports progressive rendering, the implementation should also support progressive rendering of compressed data streams.
• The viewer must support content using the "data:" protocol [RFC2397] wherever IRI referencing of whole documents (such as raster images, SVG documents, fonts and color profiles) is permitted within SVG content. This support must include use of base64 encoded content. (Note: fragments of SVG content which do not constitute an entire SVG document are not available using the "data:" protocol.)
• The viewer must support the following W3C Recommendations with regard to SVG content:
  • complete support for the XML 1.0 specification [XML10].
  • complete support for "Namespaces in XML 1.1" [XML-NS], including inclusion of non-SVG namespaces within SVG content. (Note that data from non-SVG namespaces are included in the DOM but are otherwise ignored from the point of view of rendering and interaction.)
• All visual rendering should be accurate to within one device pixel to the mathematically correct result at the initial 1:1 zoom ratio. It is suggested that viewers attempt to keep a high degree of accuracy when zooming.
• 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.

Although anti-aliasing support is not a strict requirement for a Conforming SVG Viewer, it is highly recommended for display devices. Lack of anti-aliasing support will generally result in poor results on display devices.

Specific criteria that apply to only Conforming Dynamic SVG Viewers:

• In Web browser environments, the viewer must have the ability to search and select text strings within SVG content.
• In interactive environments, the viewer must have the ability to select and copy text from SVG content to the system clipboard.

The Web Accessibility Initiative [WAI] is defining "User Agent Accessibility Guidelines 1.0" [UAAG]. Viewers are encouraged to conform to the Priority 1 accessibility guidelines defined in this document, and preferably also Priorities 2 and 3. Once the guidelines are completed, a future version of this specification is likely to require conformance to the Priority 1 guidelines in Conforming SVG Viewers.

A Conforming SVG Viewer must be able to apply styling properties to SVG content using presentation attributes (see properties shared with CSS and XSL).

If the user agent includes an XHTML or SMIL viewing capability, then a Conforming SVG Viewer must support resources of MIME type "image/svg+xml" wherever raster image external resources can be used, such as in the XHTML 'img' element.

If the user agent can apply CSS/XSL styling properties to XML documents (including XHTML, SMIL, or XForms documents), then a Conforming SVG Viewer must support resources of MIME type "image/svg+xml" in CSS/XSL properties that can refer to raster image resources (e.g., 'background-image').