What's the rationale behind result tree fragments?

Question

XSLT 1.0 adds an additional data type to those provided by XPath 1.0: result tree fragments.

This additional data type is called result tree fragment. A variable may be bound to a result tree fragment instead of one of the four basic XPath data-types (string, number, boolean, node-set). A result tree fragment represents a fragment of the result tree. A result tree fragment is treated equivalently to a node-set that contains just a single root node. However, the operations permitted on a result tree fragment are a subset of those permitted on a node-set. An operation is permitted on a result tree fragment only if that operation would be permitted on a string (the operation on the string may involve first converting the string to a number or boolean). In particular, it is not permitted to use the /, //, and [] operators on result tree fragments.
— https://www.w3.org/TR/xslt-10/#section-Result-Tree-Fragments

To me, this seems pointless. I cannot understand why anybody would want to do this! Result tree fragments just seem like a rubbish version of node-sets, requiring two intermediate variables and a language extension to allow a programmer to work around this seemingly arbitrary limitation.

To further pile on the uselessness of result tree fragments, here's the compatibility shim I stole put together to replicate exsl:node-set in MSXSL:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:exsl="http://exslt.org/common"
                xmlns:msxsl="urn:schemas-microsoft-com:xslt"
                exclude-result-prefixes="exsl msxsl">
  <!-- exsl:node-set -->
  <msxsl:script language="JScript" implements-prefix="exsl"><![CDATA[
    this['node-set'] = function (x) {
      return x;
    }
  ]]></msxsl:script>
</xsl:stylesheet>

This literally just returns the result tree fragment unchanged, suggesting that MSXSL doesn't even bother with implementing result tree fragment as a different type and just treats it identically to a node-set, further suggesting that there's no real point to it in the first place!

Why do result tree fragments exist?

• What is the use-case?
• Why were they added?
• Why not just use a node-set?

Answer 1

I wasn't on the Working Group at the time, but the following exchange might shed some light. In April 2001, during the development of XSLT 1.1, I asked the WG:

Can any one try to explain to me why there is a perceived problem with the "result tree fragment as node-set" facility as defined in the XSLT 1.1 WD? I keep hearing that it won't work with the XPath 2.0 type system, but I can't see why.

I can see us wanting to change it so that the data type is "node" rather than "node-set", but apart from that, I fail to see what the problem is.

Is it perhaps that someone has in mind doing away with the root node of the temporary tree, and making the value of the variable instead be the sequence of nodes that are currently modelled as children of this root? If so, why would that change be useful?

James Clark replied:

Is it perhaps that someone has in mind doing away with the root node of the temporary tree, and making the value of the variable instead be the sequence of nodes that are currently modelled as children of this root?

Yes.

If so, why would that change be useful?

(a) So instructions can return nodes without copying them.

(b) So that you can use instructions to return things other than nodes.

Explaining things more than this would require me to explain how I hope to see XPath, XSLT and XQuery all fitting together. At this point, let me just say that I think we need to harmonize element construction in XSLT and XQuery. This will naturally lead to their being much less of a gulf between expressions and instructions. I think it will turn out to be just as awkward and inappropriate for xsl:variable to automagically copy and wrap in a root node the value produced by instantiating its content as it would be for it to do this to the value produced by evaluating the expression specified in the select attribute.

I think the WG invented the concept of "result tree fragments" because they wanted to keep options open for the future. They had ideas how the language would evolve, and they thought that making xsl:variable create a full blown node with full navigation capability would restrict the options for the future.

In retrospect I'm convinced it was a mistake, because it didn't actually achieve this objective. When we abolished RTFs in 2.0, we still found it necessary, for backwards compatibility reasons, to have the bizarre rule that xsl:variable always constructs a document node if there is no "as" attribute.

It's worth noting that no-one in the WG ever imagined that people would still be using XSLT 1.0 twenty years later. 1.0 took about two years to develop and the WG fully expected that within two years, it would be completely superseded by a later version. They were therefore very willing to put restrictions in the language if they kept options open for the next version.