The 'id' and 'xml:id' Attributes in SVG 1.2 Tiny

Preface

This document recommends that the SVG 1.2 Tiny specification be changed to recommend to authors and generators that they continue to use 'id' for normal content, to use 'xml:id' only for generic XML processing tools, and to transform content between usage scenarios. This document further recommends that the specification state that a file using both 'id' and 'xml:id' in the same document be considered non-conforming SVG 1.2 Tiny content, and that the specification should not include the statement that 'id' id going to be deprecated. Further observations are found in the conclusion.

Introduction

The 'id' attribute, and in particular the IDness of 'id' (that is 'id' being of type ID), is a crucial part of SVG. More than any other common Web format, SVG relies upon the relationship of ID and IDREF in its markup, where it is used to apply visual effects such as gradients and filters, create copies of elements via the 'use' element, apply and target animations, target linking to fragments, and many other uses. This functionality depends upon the 'id' attribute having a value that is unique within the document, and being composed according to certain conventions.

In SVG 1.2 Tiny, the 'xml:id' attribute was added to make SVG more portable with generic XML processing tools, including XPath, XPointer, and XInclude, which need to know the IDness of an attribute for any given language. This was well-motivated, with a sound rationale documented in a TAG finding that provided the background and the possible solutions. However, it has unintended consequences for SVG's usage in common scenarios that reopen the question of exactly how it is to be integrated into SVG 1.2 Tiny.

Currently, the SVG 1.2 Tiny specification gives preference to 'xml:id', recommending that authors use 'xml:id' for new content, as in the excerpts quoted below:

And:

These requirements increase the burden on implementors and authors.

Controversy

Several commenters on the SVG 1.2 Tiny specification asked that 'xml:id' be removed from the specification. However, it has been implemented interoperably by multiple User Agents, and it does solve an existing use case, fitting into the XML ecosystem.

Comparative Support for 'id' and 'xml:id'

The 'id' attribute is widely supported in all existing SVG user agents, both authoring tools and viewers. By contrast, 'xml:id' is supported in only a small number of viewers, and only 'id' is output from authoring tools.

The 'xml:id' attribute is not popular among implementors, even those who have already implemented it. Mobile vendors, in particular, report that it complicates their code and causes a performance hit. Developers on the WebKit project have announced that they do not intend to implement 'xml:id'. This leaves authors in an awkward position with regards to authoring content.

From discussions with vendors, it seems that there is little content using 'xml:id' found in everyday usage. Since most popular SVG authoring tools are graphical editors, not XML tools, there is little incentive for them to transition to the new 'xml:id' syntax if it cannot be viewed in all User Agents. Similarly, if these authoring tools cannot open files using 'xml:id', then that content is unlikely to propagate and is harmful to the SVG ecosystem.

Uniqueness

The uniqueness of an attribute of type ID has two primary sorts:

1. a value that is unique within a document
2. the exclusivity of an attribute of type ID on an element (that is, an element can have only one attribute of type ID)

XML DTD provides a mechanism to ensure these previous requirements, but it is not an essential part of the XML language per se. Since SVG 1.2 Tiny doesn't have an official DTD, these requirements do not necessarily apply to SVG. By convention, however, these rules are followed, and nothing else in SVG assumes otherwise. RelaxNG doesn't provide a mechanism for checking IDNess.

In terms of utility for authors and end-users, the first sort of uniqueness (uniqueness within a document) is very useful, and must be preserved. The value of the second sort (the restriction against having two attributes of type ID on an element) is less clear, and may even be detrimental. Having multiple attributes of type ID would allow for a rich expression of relationship; however, this is not currently used in SVG, and is therefore not germane to this discussion.

Validation

While validation does not necessarily include checking for the uniqueness of an 'id' value with a document, that is a major benefit for authors. Currently, support for 'xml:id' in validators is limited (if available at all). Having ambiguous identity for attributes, because of 'xml:id' and 'id', is undesirable. There are ways to solve this, using Schematron and a SAX filter. Henri Sivonen, having implemented both 'xml:id' and another alternative, the preemptive assignation of type ID to any 'id' attribute, reported problems with SVG's approach.

Relative Constituency

Since some implementors are reluctant to implement 'xml:id', and even those who are willing may not do so for years, the transition path for authors using 'xml:id' is unclear. However, as noted before, there is a real-world use case for 'xml:id' (or another "universal id attribute" mechanism, such as staking a claim on any attribute 'id'), for general XML processing, which seems to conflict with the use of SVG in most existing SVG User Agents. This issue will not be solved in the SVG 1.2 Tiny timeframe. Since there is a conflict, it should be solved in a way that best serves the largest number of consumers. In the case of SVG, which is primarily a presentation technology, this would seem to be authors and users in the browser/viewer environment, rather than those using generic XML processing tools. There is an accessibility component to this, in that Accessibility Technology vendors tend to implement rather slowly, and users often cannot afford to upgrade frequently even when features are implemented, and so users needing those tools will be among the last to be able to use content created with 'xml:id'.

Transformation

In order to facilitate creating content that can be used in both scenarios (that is, in all existing desktop browsers and authoring tools, and in XML-toolchains) one solution would be to recommend that 'id' is used exclusively for common authoring content, and when that content is being prepared for consumption by a generic XML process, an XSLT stylesheet should be used to convert the 'id' attributes to 'xml:id' attributes (and vice versa). This allows the same content to be used with little overhead and no risk. Such transformation is unlikely to present a problem for those using an XML processor, while it would be more difficult for those used to authoring simple Web content; therefore, it is recommended that the original content uses 'id' preferentially.

Below are two example XSLT stylesheets, one to convert an SVG file using 'id' to contain 'xml:id', and the other to do the reverse. Sample files using 'id' and 'xml:id' are also available.

id2xmlid.xsl

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:template match="node() | @*">
    <xsl:copy>
      <xsl:apply-templates select="node() | @*"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@id">
    <xsl:attribute name="xml:id">
      <xsl:value-of select="."/>
    </xsl:attribute>
  </xsl:template>

</xsl:stylesheet>
    

xmlid2id.xsl

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:template match="node() | @*">
    <xsl:copy>
      <xsl:apply-templates select="node() | @*"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@xml:id">
    <xsl:attribute name="id">
      <xsl:value-of select="."/>
    </xsl:attribute>
  </xsl:template>

</xsl:stylesheet>
    

Conclusion

Based on this information, this document recommends that the SVG 1.2 Tiny specification be changed to recommend to authors and generators that they continue to use 'id' for normal content, to use 'xml:id' only for generic XML processing tools, and to transform content between usage scenarios. This document further recommends that the specification state that a file using both 'id' and 'xml:id' in the same document be considered non-conforming SVG 1.2 Tiny content. Since the 'id' attribute is unlikely to go away, the specification should not include the statement that 'id' id going to be deprecated. The SVGElement::id field may still be used to get and set the 'id' and 'xml:id' attributes alike, or a new SVGElement::xmlid field may be introduced. Since there is little strong support by desktop or mobile browser vendors, it should be considered making 'xml:id' an optional feature for that class of User Agent. These several steps would solve most of the thorniest problems.