and 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

Declarations in either the internal or external DTD subset of an XML document can declare attributes to be of type ID. However, processing the external DTD subset is optional for conformant XML processors; and some specifications, notably , forbid DTDs completely, 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 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. This specification allows authors to identify elements with IDs that can be recognized by any processor without regard to how, or if, any internal or external declarations are available.

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 type assignment the default behavior of their processors.

It has been a guiding principle in the design of this specification that the result of xml:id processing should be the same as if an appropriate declaration has been seen and used by the processor.

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 .

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.

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.

The process of ID type assignment causes an xml:id attribute value to be an ID. This is often achieved by making the type of the attribute "ID" in the infoset or post-schema-validation infoset (PSVI), but that is not the only possible mechanism.

Per (and ), 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 "carview.php?tsp=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 https://www.w3.org/XML/1998/namespace as described in Namespaces in XML (and ). Note that xml:id can be still used by non-namespace-aware XML processors.

Each xml:id attribute is processed in the following way:

An xml:id processor must assure that the following constraints hold for all xml:id attributes:

An xml:id processor should assure that the following constraint holds:

An xml:id error occurs for any xml:id attribute that does not satisfy the constraints.

The xml:id processor performs ID type assignment on all xml:id attributes, even those that do not satisfy the constraints.

An xml:id processor should update the infoset references property, as described in Section 2.3 of , and update any implementation-specific structures used for cross-referencing to reflect the results of ID type 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.

This specification defines xml:id processing, but it is up to the application to determine when such processing occurs. Users of applications that provide facilities for modifying XML documents may reasonably expect xml:id processing to occur whenever a change is made to an ID value.

When ID type assignment occurs, the xml:id processor must report the assigned xml:id attributes to the application. How this is reported is implementation dependent.

The key requirement is that the application be made aware of the results of ID type assignment.

A violation of the constraints in this specification results in an xml:id error. Such errors are not fatal, but should be reported by the xml:id processor. In the interest of interoperability, it is strongly recommended that xml:id errors not be silently ignored.

This specification is not extensible. There are no provisions for application designers to alter the name of the xml:id attribute, the set of attribute values that are considered IDs, the location(s) where they can occur, or make any other extensions.