Lists Home |
Date Index |
Evan Lenz wrote:
> 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.
Good point; scratch the lexical match idea.
> 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.
In my opinion, trying to locate something in an unknown
source document is a "query", not a "pointer", so this
problem could reasonably be deemed out of scope for XPointer.
By my understanding of the XPointer requirements document --
please correct me if I'm wrong -- all the use cases for XPointer
involve having the pointed-into document around at the time
the XPointer is created. So the namespace environment is available.
Sure, changing namespace prefixes could break existing XPointers,
but that's to be expected according to [C.2 "Robustness requirements"]
since that's a change to the logical information structure.