[
Lists Home |
Date Index |
Thread Index
]
> #/root/foo[1]/bar[2]
> Just doesn't work as is because it doesn't allow for namespace support
> and hence out of scope (or you put schemes in to allow binding namespace
> prefixes to URI, possible but I don't remember anybody suggesting it).
If it's a standalone XPointer, the application can make an API call to pass
a namespace context. If it's used as part of XLink, you can define the
namespaces to be those that are in scope for the link node. Both are
unambiguous, no need to pollute the XPointer expression. (XPath applications
also get the namespace prefixes from elsewhere, not from inside the path)
>> #1/2/3
> breaks as soon as an ancestor or any predecessor of those is modified
> would work for really static content, but the maintainance cost looks ...
> interesting
It's actually got a few more problems, in particular it doesn't allow
applications that deal with huge files to statically analyse the link path
to see what elements are being linked to (which is a concern to me,
seriously..)
> an horrible solution, you have to rely on something outside the document
> itself to simply make that request. //*[@id=foo] at least can work
directly
> on the document.
I'll agree with that. I don't see any problem with allowing arbitrary XPaths
(although I would keep them to a specific form, for that static
analysis...). We already have XPath implementations that do all the
complicated work, so there should be no problem with starting to use xlink
tomorrow...
Christian Nentwich
|
