Status of this Document
This is a Last Call W3C Working Draft for review by W3C members and other
interested parties. It is a draft document and may be updated, replaced, or
obsoleted by other documents at any time. It is inappropriate to use W3C Working
Drafts as reference material or to cite them as other than "work in
progress." Comments on this document should be sent no later than 31 July 2002 to the public mailing list www-xml-linking-comments@w3.org (archive).
This document has been produced by the W3C XML Linking Working
Group as part of the XML
Activity. The goals of this work are set out in the XPointer
Requirements document.
There are patent disclosures and license commitments associated with
this working draft, which may be found on the XPointer IPR Statement page in conformance with W3C policy.
Even though it has not been seen before in this form, this specification
is being published as a Last Call Working Draft because it is a subset of
an earlier specification. This specification defines only the xmlns() scheme that
was defined in the XPointer
Candidate Recommendation published on 11 September 2001.
A list of current W3C Recommendations and other technical documents can be
found at http://www.w3.org/TR/
1 Introduction
The XPointer xmlns() scheme is intended to be used with the XPointer Framework [XPtrFrame] to allow correct interpretation of namespace prefixes in pointers. The use of this scheme in a pointer part allows for successful
interpretation of element and attribute names used in pointer parts to the
right when those names use namespace prefixes.
[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 [RFC 2119].]
The terms pointer, pointer part, scheme, XPointer processor, application,
error, failure, and namespace binding context are used in this specification
as defined in
the XPointer Framework specification. Note that errors defined by this specification
are distinct from XPointer Framework errors.
The formal grammar for the xmlns() scheme is given using simple Extended
Backus-Naur Form (EBNF) notation, as described in the XML Recommendation [XML].
2 Conformance
This specification normatively depends on the XPointer Framework [XPtrFrame] specification.
Conforming XPointer processors claiming to support the xmlns() scheme must
conform to the behavior defined in this specification and may conform to additional
XPointer scheme specifications.
3 Language and Processing
This section describes the syntax and semantics of the xmlns() scheme and
the behavior of XPointer processors with respect to this scheme.
The scheme name is "xmlns". The scheme data syntax
is as follows; if scheme data in a pointer part with the xmlns() scheme does
not conform to the syntax defined in this section, it is an xmlns() scheme error
and the pointer part fails.
xmlns() Scheme Syntax
S is as defined in the XML specification [XML], and NCName is as defined
in the XML Namespaces specification [XML-Names].
A pointer part with the xmlns() scheme declares a namespace prefix (NCName) to be associated with an XML namespace
(NsURIRef). Each pointer part that uses the xmlns() scheme contributes
a new entry to the namespace binding context, and serves to allow successful
interpretation of element and attribute names used in pointer parts to the
right when those names use namespace prefixes. 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 http://example.com/ns/abc namespace name:
xmlns(abc=http://example.com/ns/abc)
A pointer part that uses the xmlns() scheme never identifies a subresource
and thus always fails. However, its evaluation has a potential effect on pointer
parts to its right.
If the pointer part fails due to failure to conform to the syntax described
in this specification, it does not contribute an entry to the namespace binding
context.
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 xmlns() scheme to
redefine the xml prefix will result in no change to the namespace
binding context.
The prefixes used in pointer parts need not match the prefixes actually
used in the XML resource into which the pointer part is addressing. As an
example, assume the following target XML resource:
<doc>
<x:a xmlns:x="http://example.com/foo">
<x:a xmlns:x="http://example.org/bar">This element and
its parent are in different namespaces.</x:a>
</x:a>
</doc>Evaluation of a pointer part that refers to element x:a will fail
if the namespace binding context contains no entry that binds x to
a namespace name. The following two pointer parts allow pointer parts to the
right to refer to both the outer a element (as x:a) and
the inner element (as y:a):
xmlns(x=http://example.com/foo) xmlns(y=http://example.org/bar)