Re: [xsl] XSLT result tree fragment, with XSLT 3.0 and xsl:variable

["Michael Kay michaelkay90@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

A little bit of historical context here.

In the December 1998 draft of XSLT 1.0, "result tree fragments" were not
distinguished as a separate data type. The term was used, rather loosely and
without definition, to describe the results of an instruction (any
instruction):

"A template can also contain elements that are instructions for creating
result tree fragments. When a template is instantiated, each instruction is
executed and replaced by the result tree fragment that it creates."

There was no xsl:variable defined at that stage.

In the April 1999 draft we start to see the 1.0 rules take shape. In
particular, we see two separate data types: "node-sets" for sets of nodes
selected from a source document, and "result-tree-fragments" for nodes
constructed by an xsl:variable instruction.

In the final  (Nov 1999) 1.0 specification, result tree fragments are defined
in more detail, and an equivalence to node-sets is recognized:

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. When a permitted operation is
performed on a result tree fragment, it is performed exactly as it would be on
the equivalent node-set.

Why the WG felt it necessary to impose these restrictions has always eluded
me. In a post on this list on 15 Sept 1999 Tangi Vass wrote that the main
weaknesses of the specification were (a) the non-mutability of variables, and
(b) the inability to process result tree fragments as node sets. I responded
by saying

(a) But I personally believe the benefits of [immutability] do not justify
the
restrictions it imposes, which is why I have implemented assignment (and
loops) in SAXON. [a decision I have come to regret], and


(b) I think that a function to convert a result tree fragment into a node-set
that can be further processed is a perfectly reasonable extension to the
standard and I've started experimenting to see if it can be done in SAXON.


the following day Dave Pawson asked

If reuse of result trees was possible, 90% off my problems and ugly
hacks would disappear. I would really appreciate to know the rationale
why the spec says what is says (implementation problems?)


to which Oren Ben-Kiki responded:

This was discussed in this mailing list; the main reason given was that by
limiting XSLT to a "single pass" it would be easier to implement
"incremental" XSLT processors. Such processors are deemed important for
editors etc. I don't know whether this was in fact the main reason for it -
and we wouldn't know unless some WG member confirms it.

I personally don't buy this reason because (i) even a single pass
incremental XSLT processor is very hard to do and (ii) even with the current
restricted spec it is possible to write a multi-pass stylesheet. In fact
XSLT has hit the Turing-complete limit and attempts to justify all sort of
restrictions in order to allow "automatic reasoning" of various types on it
are pretty much futile. This is not to say that incremental processors or
other form of automatic reasoning on XSLT stylesheets would not be available
in practice; it is just that such tools would by necessity be limited to
"simple enough" stylesheets.

[The idea of "incremental" XSLT processors was, I think, that if you made a
small change to the source document, the XSLT processor would be able to
make corresponding adjustments to the result document without re-evaluating
the whole stylesheet. Of course, that never happened.]

As soon as XSLT 1.0 came out, it became rapidly clear that the restriction
on result tree fragments was a great nuisance; and while the xx:node-set()
extension function provided a workaround, a new version of the spec should
combine node-sets and result tree fragments into a single data type. Making
this work in a backwards compatible way was not easy; a lot of the key ideas
came from Jeni Tennison. But a key part of the solution was a paradigm shift:
whereas
in 1.0 instructions were described as being "instantiated", which caused
things
to be "created" or "output", in 2.0, instructions were evaluated to return a
result,
thus behaving in a much more "functional" way.

Associated with this, XSLT 1.0 described a sequence of instructions as a
"template", but no-one ever used this terminology, because the term was
too closely associated with template rules and named template. The new
name "sequence constructor" was my invention.

Michael Kay
Saxonica


> On 11 Apr 2023, at 16:05, Mukul Gandhi mukulg@xxxxxxxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi Wendell,
>
> On Tue, Apr 11, 2023 at 7:09b/PM Piez, Wendell A. (Fed)
wendell.piez@xxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> The essential difference is that you were not allowed in *unextended* XSLT
1.0 to treat the fragment like a tree. In 2.0 you were invited to do so.
>
> I think, its certainly more useful as an XSLT language, to treat the
fragment like a tree by default (as you rightly wrote). This helps us solve,
more kinds of XML transformation use cases, with the standard XSLT language
(2.0 and 3.0).
>
>
> --
> Regards,
> Mukul Gandhi
> XSL-List info and archive
> EasyUnsubscribe (by email)