This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The original use case for the introduction of the EQName syntax was to allow users to generate a persistent path to a node that could then be fed back into the system to retrieve the original node. Such a path might take the form "http://ns1.uri/":doc[1]/"http://ns1.uri/":chap[2]/"http://ns1.uri/":section[4] Well, we did half the job: we added EQNames, but we didn't add the ability to generate the path. A function to do so can be written by users, of course, but it's not trivial. This entry proposes the addition of such a function. (Note, XQuery still has no facility to evaluate a path presented as a string in this form. XSLT 3.0 does have this capability, in the form of the xsl:evaluate instruction.)
Here is a proposed specification. fn:path($node as node()) as xs:string Summary: returns a path expression that can be used to select the supplied node relative to the root of its containing document. Rules: * If $node does not have a document node as an ancestor, an error is raised [TBA] * If $node is a document node, the function returns the string "/". * Otherwise, the function constructs a string that consists of a sequence of steps, one for each ancestor-or-self of $node other than the document node. Each step consists of the character "/" followed by a string whose form depends on the kind of node selected by that step, as follows: ** For an element node, "{uri}":{local}[{position}], where {uri} is the namespace URI of the node-name or the empty string if the node is in no namespace, {local} is the local part of the node-name, and {position} is an integer representing the position of the selected node among its like-named siblings ** For an attribute node: --- if the node is in no namespace, @{local}, where {local} is the local part of the node-name --- otherwise, @"{uri}":{local}, where {uri} is the namespace URI of the node-name, and {local} is the local part of the node-name ** For a text node: text()[{position}] where {position} is an integer representing the position of the selected node among its text node siblings ** For a comment node: comment()[{position}] where {position} is an integer representing the position of the selected node among its comment node siblings ** For a processing-instruction node: processing-instruction({local])[{position}] where {local} is the name of the processing instruction node and {position} is an integer representing the position of the selected node among its like-named processing-instruction node siblings ** For a namespace node: namespace::{prefix}, where {prefix} is the local part of the name of the namespace node (which represents the namespace prefix).
In their Joint teleconference on 2011-05-10 (the minutes of which can be found at member-only URI http://lists.w3.org/Archives/Member/w3c-xsl-query/2011May/0131.html), the XML Query and XSLT WGs decided to adopt the proposal in comment #1 without changes, adding the fn:path() function to F&O 3.0. Based on this decision, I am marking this bug RESOLVED/FIXED. Because you were present when the decision was made, I am also marking it CLOSED. If you disagree with this resolution, please re-open the bug.