previous   next   contents   elements   attributes   properties   index  

30 April 2002

Appendix G: Conformance Criteria


Contents

This appendix is normative.

G.1 Introduction

In order to ensure that SVG-family documents are maximally portable among SVG-family user agents, this specification rigidly defines conformance requirements for both of these and for SVG-family document types. While the conformance definitions can be found in this appendix, they necessarily reference normative text within this document and within other related specifications. It is only possible to fully comprehend the conformance requirements of SVG through a complete reading of all normative references.

G.2 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) Specification) including SVG's DTD (see Document Type Definition) and also:

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.

G.3 Conforming SVG Stand-Alone Files

A file is a Conforming SVG Stand-Alone File if:

G.4 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.

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 SVG Document Type Definitions (DTD).

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"?>
<!DOCTYPE SomeParentXMLGrammar PUBLIC "-//SomeParent" 
  "http://SomeParentXMLGrammar.dtd">
<ParentXML>
  <!-- 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 file could be modified as follows (the example below shows the use of Stylable SVG):

<?xml version="1.0" standalone="no"?>
<!DOCTYPE SomeParentXMLGrammar PUBLIC "-//SomeParent" 
  "http://SomeParentXMLGrammar.dtd">
<ParentXML>
  <!-- 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>

G.5 Conforming SVG Host Language Documents

It is possible to modify existing document types and define wholly new document types using both modules defined in this specification and other modules. Such a document type is "SVG Host Language Conforming" when it meets the following criteria:

  1. The document type must be defined using one of the implementation methods defined by the W3C. Currently this is limited to XML DTDs, but XML Schema will be available soon. The rest of this section refers to "DTDs" although other implementations are possible.
  2. The DTD which defines the document type must have a unique identifier as defined in Naming Rules that uses the string "SVG" in its first token of the public text description.
  3. For each of the W3C-defined modules that are included, all of the elements, attributes, types of attributes (including any required enumerated value lists), and any required minimal content models must be included (and optionally extended) in the document type's content model. When content models are extended, all of the elements and attributes (along with their types or any required enumerated value lists) required in the original content model must continue to be required.
  4. The DTD which defines the document type may define additional elements and attributes. However, these must be in their own XML namespace.

G.6 Conforming SVG Integration Set Documents

It is also possible to define document types that are based upon SVG, but do not adhere to its structure. Such a document type is "SVG Integration Set Conforming" when it meets the following criteria:

  1. The document type must be defined using one of the implementation methods defined by the W3C. Currently this is limited to XML DTDs, but XML Schema will be available soon. The rest of this section refers to "DTDs" although other implementations are possible.
  2. The DTD which defines the document type must have a unique identifier as defined in Naming Rules that uses the string "SVG" NOT in its first token of the public text description.
  3. For each of the W3C-defined modules that are included, all of the elements, attributes, types of attributes (including any required enumerated lists), and any required minimal content models must be included (and optionally extended) in the document type's content model. When content models are extended, all of the elements and attributes (along with their types or any required enumerated value lists) required in the original content model must continue to be required.
  4. The DTD which defines the document type may define additional elements and attributes. However, these must be in their own XML namespace.

G.7. SVG Family Module Conformance

This specification defines a method for defining SVG-conforming modules. A module conforms to this specification when it meets all of the following criteria:

  1. The document type must be defined using one of the implementation methods defined by the W3C. Currently this is limited to XML DTDs, but XML Schema will be available soon. The rest of this section refers to "DTDs" although other implementations are possible.
  2. The DTD which defines the module must have a unique identifier as defined in Naming Rules.
  3. When the module is defined using an XML DTD, the module must insulate its parameter entity names through the use of unique prefixes or other, similar methods.
  4. The module definition must have a prose definition that describes the syntactic and semantic requirements of the elements, attributes, and/or content models that it declares.
  5. The module definition must not reuse any element names that are defined in other W3C-defined modules, except when the content model and semantics of those elements are either identical to the original or an extension of the original, or when the reused element names are within their own namespace (see below).
  6. The module definition's elements and attributes must be part of an XML namespace. If the module is defined by an organization other than the W3C, this namespace must NOT be the same as the namespace in which other W3C modules are defined.

G.8. SVG Family Document Conformance

A conforming SVG family document is a valid instance of a conforming SVG Host Language Document.

G.9 Conforming SVG Generators

A Conforming SVG Generator is a program which:

Additionally, an authoring tool which is a Conforming SVG Generator conforms 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.)

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.

G.10 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:

A Conforming SVG Interpreter must parse any SVG document correctly. It is not required to interpret the semantics of all features correctly.

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

G.11 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] 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 higher order concept is that of a Conforming High-Quality SVG Viewer, with sub-categories Conforming High-Quality Static SVG Viewer and Conforming High-Quality Dynamic SVG Viewer.

Both a Conforming High-Quality Static SVG Viewer and a Conforming High-Quality Dynamic SVG Viewer must support the following additional features:

A Conforming High-Quality Dynamic SVG Viewer must support the following additional features:

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

If the user agent includes a CSS2 capability, a Conforming SVG Viewer must support CSS styling of SVG content and must support all features from CSS2 (Cascading Style Sheets, level 2 CSS2 Specification) that are described in this specification as applying to SVG (see properties shared with CSS and XSL, Styling with CSS and Facilities from CSS and XSL used by SVG). The supported features from CSS2 must be implemented in accordance with the conformance definitions from the CSS2 specification.

If the user agent includes an HTML or XHTML viewing capability or can apply CSS/XSL styling properties to XML documents, 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 HTML or XHTML 'img' element and in CSS/XSL properties that can refer to raster image resources (e.g., 'background-image').

G.12 Naming Rules

SVG Host Language document types must adhere to strict naming conventions so that it is possible for software and users to readily determine the relationship of document types to SVG. The names for document types implemented as XML document type definitions are defined through Formal Public Identifiers (FPIs). Within FPIs, fields are separated by double slash character sequences (//). The various fields must be composed as follows:

  1. The leading field must be "-" to indicate a privately defined resource.
  2. The second field must contain the name of the organization responsible for maintaining the named item. There is no formal registry for these organization names. Each organization should define a name that is unique. The name used by the W3C is, for example, W3C.
  3. The third field contains two constructs: the public text class followed by the public text description. The first token in the third field is the public text class which should adhere to ISO 8879 Clause 10.2.2.1 Public Text Class. Only SVG Host Language conforming documents should begin the public text description with the token "SVG". The public text description should contain the string "SVG" if the document type is Integration Set conforming. The field must also contain an organization-defined unique identifier (e.g., MyML 1.0). This identifier should be composed of a unique name and a version identifier that can be updated as the document type evolves.
  4. The fourth field defines the language in which the item is developed (e.g., EN).

Using these rules, the name for an SVG Host Language conforming document type might be -//MyCompany//DTD XHTML MyML 1.0//EN. The name for an SVG family conforming module might be -//MyCompany//ELEMENTS XHTML MyElements 1.0//EN. The name for an SVG Integration Set conforming document type might be -//MyCompany//DTD Special Markup with SVG//EN.

 

previous   next   contents   elements   attributes   properties   index