let a bug be a feature
Adding variables to XPath was a simple task. But when I was testing it, I had to switch to testing the Scheme function "x:current" (former name "x:current-node") and then found an essential problem with the namespaces.
It was easy to predict this sort of problems, but subconsciously I was ignoring it until stumbled upon it.
Consider the XML:
<root xmlns:z="http://z"> <z:part>text</z:part> </root>
The corresponding SXML is:
(root (@ (@ (*NAMESPACES* (z "http://z")))) (z:part "text")
After making "cddr" on the SXML, the result is:
(z:part "text")
The prefix "z" is unbound now. I though it was not a problem because I have a map between the Scheme nodes and the libxml tree, and it is easy to get a libxml node which corresponds to "z:part" and look up the "z" definition in the ancestors.
Now I see the problem. If we make a deep code of the SXML above, we have nothing to look up, and the prefix "z" is now really unbound.
And we really need to deep copy as a method to eliminate the "scm_to_node: bounded node can't be added to tree, adding a free copy" warning. (See explanations.)
The only solution I see is to document this problem, so making it a feature, not a bug. That's what I'm doing by this post.
User-side solution is: let the same prefixes in XML and XSLT point to same URIs, and define the prefix in the "xsl:stylesheet" element. Then all will be ok.
Technical explanation. XSLT processor (at least, xsltproc) copies all prefixes from "xsl:stylesheet" to the output tree. When our code inserts a node with a lost prefix, the lost prefix will be coincidely matched to the top-level prefix. As the URIs are the same, result is correct.