[
Lists Home |
Date Index |
Thread Index
]
Joe English wrote:
> Or it could use the target document's namespace context.
> That is, the QNames in the XPointer must be lexically identical
> to the QNames in the target document.
In the XPath 1.0 data model, these two aren't the same thing. Specifically,
the actual prefix used in an element name is not preserved, which is to say
it can't be determined when more than one prefix is available in the
namespace context.
For example, given the following context node:
<a:foo xmlns:a="http://example.com"; xmlns:b="http://example.com"/>
The XPath name() function may return either "a:foo" or "b:foo". The actual
QName "may" be preserved but is not a part of the data model, so this isn't
possible in general. For XPointer to match QNames, it would have to change
not only the semantics of path expressions but the underlying data model as
well (specifically, exposing the element or attribute's [prefix] property).
That said, you could still use the document's namespace context as you said
originally without changing the data model. That means that either "/a:foo"
or "/b:foo" would work in this case. But writing applications that depend on
an unknown source document to use certain prefixes is probably not a good
thing, especially if that document uses multiple namespaces. XPath 1.0 could
have worked this way, because the data model provides the necessary
information. While the in-scope namespace declarations are significant in
the data model, the language is not biased toward treating them as
significant. Name tests always test for expanded-names, not QNames. The
name() function is the only place where prefixes are exposed apart from the
namespace nodes themselves.
Evan
|
