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

["Dave Pawson dave.pawson@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Mike, don't forget the history of XSL?
DSSSL provided a functional approach (totally convinced me it was
beneficial).
XSL *included* xsl-fo originally (DSSSL history)  - how did this
impact the design?
I can't remember the name (Ken H, can you help?) but DSSSL had a name
for RTF's (rather strange IIRC)


It was only when users realised we could use 'parts' of XSL (XSLT)
that we clamoured for
the XSL / XSLT split to build HTML?


regards

On Tue, 11 Apr 2023 at 18:48, Michael Kay michaelkay90@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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)
>
>


--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.