&abstract;

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 .

The terms pointer part, scheme, XPointer processor, and namespace binding context are used in this specification as defined in the XPointer Framework specification.

The formal grammar for the &scheme-phrase; is given using simple Extended Backus-Naur Form (EBNF) notation, as described in the XML Recommendation .

This specification normatively depends on the XPointer Framework specification.

Conforming XPointer processors claiming to support the &scheme-phrase; must conform to the behavior defined in this specification and may conform to additional XPointer scheme specifications.

This section describes the syntax and semantics of the &scheme-phrase; and the behavior of XPointer processors with respect to this scheme.

The scheme name is &schemename;. The scheme data syntax is as follows; if scheme data in a pointer part with the &scheme-phrase; does not conform to the syntax defined in this section the pointer part does not contribute an entry to the namespace binding context.

S is as defined in the XML specification , NCName is as defined in the XML Namespaces specification , and EscapedData is as defined in the XPointer Framework specification .

A pointer part with the &scheme-phrase; declares a namespace prefix (NCName) to be associated with an XML namespace name (EscapedNamespaceName with any circumflex-escaping undone). Each pointer part that uses the &scheme-phrase; contributes a new entry to the namespace binding context. If a pointer part defines a binding for a namespace prefix that already has an entry in the namespace binding context, the new entry overrides the old one.

For example, the following pointer part binds the abc prefix to the https://example.com/ns/abc namespace name:

A pointer part that uses the &scheme-phrase; never identifies a subresource and thus the XPointer processor evaluation always continues with the next pointer part. However, evaluation of the xmlns pointer part has a potential effect on pointer parts to its right.

The XPointer Framework on which this specification is based dictates that the initial namespace binding context prior to evaluation of the first pointer part consists of a single entry: the xml prefix bound to the URI http:/www.w3.org/XML/1998/namespace. Following the rules specified by the Framework, any attempt by a pointer part using the &scheme-phrase; to redefine the xml prefix will result in no change to the namespace binding context. Any attempt to bind a prefix to the namespace name https://www.w3.org/XML/1998/namespace will result in no change to the namespace binding context. Any attempt to define the xmlns prefix will result in no change to the namespace binding context. Any attempt to bind a prefix to the namespace name https://www.w3.org/2000/xmlns/ will result in no change to the namespace binding context.

The prefix used in pointer parts need not match the prefix (or lack of a prefix) actually used in the XML resource into which the pointer part is addressing. For example, assume the following target XML resource:

Evaluation of a pointer part that refers to element customer will not identify any subresources if the namespace binding context contains no entry that binds a prefix to the namespace name https://example.org/customer. The following two pointer parts allow the xpointer() part to the right to refer to the customer element (as c:customer) and the name element (as p:name):