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">

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.

Leave a Reply