[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XPointer crisis
> #/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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|