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

Dave, are you thinking of sosofos? Specification of a sequence of flow
objects?

At 2023-04-11 19:12 +0000, Dave Pawson dave.pawson@xxxxxxxxx wrote:

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.

--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/s/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @US$125 (5 hours free) |
Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |

<- Previous	Index	Next ->
Re: [xsl] XSLT result tree fragment, Dave Pawson dave.paw	Thread	Re: [xsl] XSLT result tree fragment, Dave Pawson dave.paw
Re: [xsl] XSLT result tree fragment, Dave Pawson dave.paw	Date	Re: [xsl] XSLT result tree fragment, Dave Pawson dave.paw
	Month

<-prev [Thread] next->	<-prev [Date] next->
Month Index \| List Home

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