This document is also available in these non-normative formats: XML.
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document defines the meaning of the attribute
xml:id
as a universal spelling for ID attributes in XML
documents and defines processing of this attribute to identify IDs in
the absence of validation, without fetching external resources, and without
relying on an internal subset.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a Last Call Working Draft of “xml:id Version 1.0”. The Last Call review period ends 13 December 2004, at 23:59 EST. Please send Last Call review comments on this document before that date to the public mailing list public-xml-id@w3.org (archive).Last Call Working Draft status is described in section 7.4.2 of the W3C Process Document. To the extent possible, please provide a separate email message for each distinct comment.
This document has been developed by the W3C XML Core Working Group as part of the XML Activity. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The patent policy for this document is the 5 February 2004 W3C Patent Policy. Patent disclosures relevant to this specification may be found on the XML Core Working Group's public IPR disclosure page. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
2 Terminology
3 Syntax
4 Processing xml:id Attributes
5 Informing the Application
6 Errors
7 Conformance
7.1 Conformance to xml:id
7.2 XML Information Set Conformance
A References
B References (Non-Normative)
C Impacts on Other Standards (Non-Normative)
D Validation Technologies (Non-Normative)
D.1 With DTD Validation
D.2 With XML Schema Validation
[XML 1.0] and [XML 1.1] provide a mechanism for annotating elements with unique identifiers. This mechanism consists of declaring the type of an attribute as "ID", after which the parser will validate that
the ID value matches the allowed lexical form,
the value is unique within the XML document, and that
each element has at most a single unique identifier
Declarations in either the internal or external subset of an XML document can declare attributes to be of type ID. However, some specifications, notably [SOAP], forbid an internal subset, and processing the external subset is optional for conformant XML processors, leaving no guarantee that all consumers of the XML document will be able to successfully recognize the identifiers.
Identifiers can be declared through external mechanisms as well. Of particular interest is [XML Schemas] which provides a type "xs:ID" with the same uniqueness and validity constraints as XML. However, there are no guarantees that consumers will have the "correct" schema available, nor that they will process it if they do.
A mechanism allowing unique element identifiers to be recognized by all conformant XML processors, whether they validate or not, is desirable in making XML sub-resource linking robust.
An additional problem is that DTD-based and XML Schema-based identifiers are exposed through different conceptual mechanisms - the [attribute type] infoset property, and the [type definition] family of properties respectively. A uniform mechanism for recognizing identifiers is desirable.
This specification provides such a mechanism: it describes the
semantics of xml:id
attributes. This specification has been
designed to be a separate layer in processing and to be compatible
with existing validation technologies. Implementors are encouraged to
support xml:id
processing and to make
ID assignment the default
behavior of their processors.
[Definition: The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [IETF RFC 2119].]
[Definition: An xml:id processor is a software module that works in conjunction with an XML processor to provide access to the IDs in an XML document.]
[Definition: An xml:id error is a non-fatal error that occurs when an xml:id processor finds that a document has violated the constraints of this specification.]
Validation is the process of comparing an XML document (or part of an XML document) against a grammar or set of rules to determine if the actual structure of the document satisfies the constraints of the grammar or the rules. Some validation technologies also perform type assignment, determining not only if the document satisfies the specified constraints but also determining, for example, which (elements and/or) attributes are of type “ID”.
Although often performed together, validation and type assignment are not the same process. A non-validating XML 1.0 processor, for example, can perform type assignment using only declarations from the internal subset, without ever having any information about the structural validity of the document.
[Definition: The process of ID assignment associates an ID with an element.] This is often achieved by promoting the type of an untyped element or attribute value to a value of type “ID”, but that is not the only possible mechanism.
Per [Namespaces in XML] (and [Namespaces in XML 1.1]), prefixes beginning “xml” are reserved for use by XML and XML-related specifications. This specification licenses the use of the attribute “xml:id” for use as a common syntax for identifiers in XML with the semantics specified herein.
Authors of XML documents are encouraged to name their ID attributes "xml:id" to increase the interoperability of these identifiers on the Web.
In namespace-aware XML processors, the "xml" prefix is bound to the
namespace name http://www.w3.org/XML/1998/namespace
as
described in Namespaces in XML [Namespaces in XML] (and [Namespaces in XML 1.1]). Note that xml:id
can be still used by
non-namespace-aware XML processors.
xml:id
AttributesEach xml:id
attribute is processed in the following
way:
The attributeʼs value is normalized according to the rules
for attribute-value
normalization on attributes of type ID. For xml:id
processors operating on an infoset or some other output from an XML parser,
the value will already be normalized, but
unless the parser normalized it as a value of type ID it will still be
necessary
for the processor to trim leading and trailing space (#x20) characters
and replace sequences of space characters by a single space.
ID assignment is performed.
An xml:id
processor
must assure that the following
constraints hold for all xml:id
attributes:
The normalized value of the attribute is a valid NCName.
The declared type of the attribute, if it has one, is “ID”.
All declarations for xml:id
attributes
must
specify “ID” as the type of the attribute.
An xml:id
processor
should assure that the following
constraints hold:
The values of all xml:id
attributes and all attributes
of type “ID” within a document are unique.
An xml:id error occurs
for any xml:id
attribute that does not satisfy the
constraints.
The xml:id
processor performs
ID assignment on all
xml:id
attributes, even those that do not satisfy
the enumerated constraints.
An xml:id
processor
should update the
[references] infoset property, and/or
other appropriate referential properties to reflect the results of ID
assignment.
Many validation technologies impose the constraint that an XML
element can have at most one attribute of type ID. That constraint is
not imposed by xml:id
processing.
ID assignment may be
performed when xml:id
attributes are processed.
If ID assignment
occurs, then the xml:id processor
must report the assigned
xml:id
attributes
to the application. How this is reported is implementation
dependent.
For applications that operate conceptually on the Infoset, an
xml:id
processor can use the
[attribute type] Infoset
property:
The xml:id
processor may report the results of ID assignment in a
DTD compatible manner by setting the [attribute type] infoset property of the
attribute to ID.
For applications that operate conceptually on the PSVI, an
xml:id
processor can use the
[type definition] family
of PSVI properties:
The xml:id
processor may
report the results of ID assignment
in an XML Schema compatible manner by setting the PSVI
[type definition] property of the
attribute to xs:ID
.
For applications that operate on data models defined in other ways, the mechanisms are implementation dependent:
The xml:id
processor may
report the results of ID assignment in some other way.
The key requirement is that the application be made aware of the results of ID assignment.
A violation of the constraints in this specification results in an xml:id error. Such errors are not fatal, but must be reported by the xml:id processor to the application invoking it.
Conformance to xml:id
for applications that rely on
XML
processors using validation technologies consists in the
use of the xml:id
construct as explained in
4 Processing xml:id Attributes and by conformance to both the constraints
of this specification and the rules of the validation technology.
Conformance to xml:id
for applications that rely on
non-validating
XML
processors is defined by the recognition of xml:id
attributes as explained in
4 Processing xml:id Attributes and by conformance to the constraints
of this specification.
This specification conforms to the [XML Information Set]. The following information items must be present in the input infosets to enable correct processing:
Element Information Items with [attributes] property.
Attribute Information Items with [namespace name], [local name] and [normalized value] properties.
In addition, the following properties might be present in the output infoset:
[attribute type] properties on Attribute Information Items.
XPath 1.0: The id() function only recognizes IDs
declared in the DTD. If xml:id
processing is performed before
the document is provided to the XPath 1.0 processor, and if ID assignment is
performed by setting the
[attribute type] infoset property,
XPath 1.0 will recognize xml:id
attributes as IDs.
An erratum to XPath 1.0 would be required to allow
Schema-declared IDs to be included in the results of this function.
XPath 2.0: No change required. The id() function
recognizes both DTD- and Schema-declared identifiers, and as such
would also recognize xml:id
attributes identified with a
minimally conforming schema processor.
Fragment Identifiers and the XPointer Framework:
No change required. Barename
fragment identifiers and the element() scheme recognize both DTD- and
Schema-declared identifiers, and as such would also recognize
xml:id
attributes identified with a minimally conforming
schema processor.
DOM: To the extent that a DOM instance is constructed from
an Infoset or PSVI, no change is required. The xml:id
processorʼs
ID assignment of xml:id
attributes will be visible to the
DOM construction process.
CSS: To the extent that a CSS operates on a tree constructed from
an Infoset or PSVI, no change is required. The xml:id
processorʼs
ID assignment of xml:id
attributes will be visible to the
construction process.
This appendix describes how xml:id
processing interacts with
selected validation technologies.
DTD authors are encouraged to use xml:id
exclusively in
their DTDs to indicate element identifiers.
The following (non-normative) DTD fragment illustrates a sample
declaration for the xml:id
attribute:
<!ATTLIST someElement xml:id ID #IMPLIED >
DTD authors must not declare
xml:id
as something other than ID
.
DTD authors who declare attributes other than xml:id
as type
ID will not receive the full benefits of xml:id
processing.
Such attributes may or may not be recognized processors, including
xml:id
processors.
Validating consumers of documents using properly declared
xml:id
attributes can recognize IDs through the [attribute type] property.
XML Schema authors are encouraged to use xml:id
exclusively in their schemas to indicate element identifiers.
The following (non-normative) XML Schema fragment illustrates a
sample declaration for the xml:id
attribute:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3.org/XML/1998/namespace"> <xs:attribute name="id" type="xs:ID"/> </xs:schema>
XML Schema authors must not
declare xml:id
as something other than xs:ID
(for instance xs:string
).
XML Schema authors who declare attributes other than xml:id
as type
xs:ID will not receive the full benefits of xml:id
processing.
Such attributes may or may not be recognized processors, including
xml:id
processors.
Consumers of documents validating the xml:id
attributes
against an appropriate schema can recognize IDs through the [type definition] family of PSVI
properties.
Applications can recognize xml:id
attributes as IDs by
conceptually using a Minimally
Conforming Schema Processor processing the schema above.
Note that the effects of a Minimally Conforming Schema Processor,
processing the above schema, are approximated by simply looking for
attributes named xml:id
, ensuring the value of such
attributes has the correct lexical form (NCName),
and the value is unique within the document.