SVG Tiny 1.2 – 20081222

D Conformance Criteria

Contents

This appendix is normative.

D.1 Introduction

This specification defines conformance for several classes of products:

Some SVG displaying software will not display animations or other runtime modifications — for example, server side rasterizers or SVG-enabled printers. Therefore, this specification has different conformance levels for static and dynamic SVG viewers.

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 [RFC2119]. However, for readability, these words do not necessarily appear in all uppercase letters in this specification.

All examples are informative, not normative. All chapters are normative except for specific sections marked as being informative. All appendices state whether the appendix is normative or informative. 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 an EBNF 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

D.3.1 Conforming SVG Document Fragments

An SVG document fragment is a Conforming SVG Document Fragment if it adheres to the specification described in this document (Scalable Vector Graphics (SVG) Tiny 1.2 Specification) including SVG's schema (see RelaxNG schema) and also:

NVDL script:

<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/XML/1998/namespace' 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='elements attributes'>
           <attach/>
         </namespace>
         <anyNamespace match='elements attributes'>
           <mode>
             <anyNamespace>
               <allow/>
             </anyNamespace>
           </mode>
         </anyNamespace>
       </mode>
     </validate>
   </namespace>
</rules>
        

The SVG language or these conformance criteria provide no designated size limits on any aspect of SVG content. There are no maximum values on the number of elements, the amount of character data, or the number of characters in attribute values.

D.3.2 Conforming SVG Stand-Alone Documents

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

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 the Namespaces in XML 1.0 specification [XML-NS10] or the Namespaces in XML 1.1 specification [XML-NS] (depending on the version of XML used).

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:

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

<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.3.4 Conditionally Conforming SVG Tiny 1.2 Document Fragments

It is sometimes desirable to create content conforming to a larger profile, and have fallback to a lower profile. For example, some SVG content might have a switch element where one branch, protected by a conditional processing attribute that will evaluate to false in a conformant SVG 1.2 Tiny viewer, uses features not available in SVG Tiny 1.2 (pattern fills, clipped images, filter effects) and another branch has SVG Tiny 1.2 content (such as a gradient fill). The parts of the content that will be rendered by an SVG Tiny 1.2 viewer are all SVG Tiny 1.2, yet the content as a whole does not conform to SVG Tiny 1.2.

An SVG document fragment is a Conditionally Conforming SVG Tiny 1.2 Document Fragment if:

  1. All elements using a 'requiredFeatures' attribute to require a feature not defined in this specification are marked as false
  2. All elements using a 'requiredExtensions' attribute to require an extension are marked as false
  3. The document fragment is transformed to remove all elements (and their children) marked false
  4. The transformed document fragment is a Conforming SVG Document Fragment

D.4 SVG writer conformance

D.4.1 Conforming SVG Generators

A Conforming SVG Generator is a program which:

When writing elements that have an ID defined, an SVG Generator should prefer the 'id' attribute over the 'xml:id' attribute [XMLID] for content that is known to target SVG viewers, and 'xml:id' over 'id' for content that is known to target generic XML processors. An SVG Generator must not include both attributes for the same document on elements in the SVG namespace.

SVG generators are encouraged to follow W3C developments in the area of internationalization such as Character Model for the World Wide Web 1.0: Normalization [CHARMOD-NORM]. Future versions of the SVG specification may require support of that specification 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 file is compressed with gzip or deflate, Conforming SVG Servers must indicate this with the appropriate header, according to what the protocol supports. Specifically, for content compressed by the server immediately prior to transfer, the server must use the "Transfer-Encoding: gzip" or "Transfer-Encoding: deflate" headers as appropriate, and for content stored in a compressed format on the server (e.g. with the file extension "svgz"), the server must use the "Content-Encoding: gzip" or "Content-Encoding: deflate" headers as appropriate.

Note: Compression of stored content (the "entity," in HTTP terms) is distinct from automatic compression of the message body, as defined in HTTP/1.1 TE/ Transfer Encoding ([RFC2616], sections 14.39 and 14.41).

D.5 SVG reader conformance

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 a search engine (e.g. a service which indexes text, metadata, or other SVG content), 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 [XML11] and [XML-NS].

A Conforming SVG Interpreter must be able to parse and process a conforming SVG Tiny 1.1 document fragment [SVGM11].

A Conforming SVG Interpreter must conform to all applicable 'I' conformance criteria in Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD].

There are two sub-categories of Conforming SVG Interpreters:

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.)

A Conforming SVG Interpreter which indexes SVG content (e.g. a search engine) must, at a minimum, extract and process all textual data, including the content of the text content elements and descriptive elements, with attention paid to author-supplied alternate languages for purpose of presentation and translation. Additionally, it should process element types, document structure, metadata, and link data to inform the indexing. A Conforming SVG Interpreter which indexes images should categorize and represent SVG content as an image. Such an SVG Interpreter may apply heuristics to the geometric semantics of the SVG document or to the rendered image (such as performing shape-recognition) to improve indexing.

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:

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

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:

The Web Accessibility Initiative [WAI] has defined User Agent Accessibility Guidelines 1.0 [UAAG]. A Conforming SVG Viewer must conform to the Priority 1 accessibility guidelines defined in UAAG, and should conform also to Priorities 2 and 3.

A Conforming SVG Viewer must be able to apply styling properties to SVG content using presentation attributes.

D.6 Extension conformance requirements

Specifications and implementations are allowed to extend the SVG specification but in order to claim conformance the following criteria need to be met:

D.7 Non-XML encoding conformance requirements

An SVG Document Fragment, SVG Stand-Alone Document or SVG Included Document encoded using a non-XML encoding (e.g. efficient XML compression) conforms to this specification if and only if the non-XML encoding in question guarantees roundtripping from XML to the encoding and back in such a way that the resulting document when processed by an SVG user agent must always render, animate, and interact in the exact same way as the original. Note that this requires a high-level of fidelity from the encoding including, but not limited to, the ability to encode non-conforming content and content from foreign namespaces without loss, maintaining ID typing supplied by the internal subset of the formal part the Document Type Definition, and not removing non-rendered elements such as 'desc', 'title', or elements removed from the rendering tree through use of conditional processing attributes.