fn:root() vs. absolute path expressions

[ChristianGruen]

Is there a particular reason why the absolute slash / is defined as complicated as…

self::gnode()/(fn:root(.) treat as (document-node()|jnode())/PP

…and wouldn’t it be helpful to simplify it get rid of the treat as expression?

self::gnode()/fn:root(.)/PP

In many cases, the document node does not exist or is not really needed, and it would allow users to use the slash for nodes that would otherwise needs to wrapped into document nodes, for example:

let $as := analyze-string('abc', 'b')
return $as/fn:match[/fn:non-match]

[michaelhkay]

I think the reason this wasn't done originally is still valid: if an element E is the root of a tree, people would expect /E to select that E element, rather than selecting its children.

One could finesse it (as we did for XSLT patterns) by saying that under these circumstances the default axis is self rather than child, but the rules become even more complicated.

It's a laudable goal that selecting within an element-rooted tree should work much the same as selecting within a document-rooted tree, but having leading slash select the element root doesn't achieve that.

The root() function was invented for this use case.

[ChristianGruen]

I think the reason this wasn't done originally is still valid: if an element E is the root of a tree, people would expect /E to select that E element, rather than selecting its children.

I have never thought of it this way: /E currently returns the child element of the root node, not the (document) root itself, so if / was also allowed for a root element, I would again expect to get its child element.

I assume this thinking tries to live up to the expectations of users who are not aware of the existence of document nodes. However, as <e/>/e returns an empty sequence, it should be clear that <e/>[/e] does so, too. Instead, the latter raises an error, which (in my opinion) makes the underlying semantics even more mysterious.