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

On Tue, 11 Apr 2023 at 20:22, G. Ken Holman g.ken.holman@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Dave, are you thinking of sosofos?
Specification of a sequence of flow objects?

Yes!
  Do you think that was the origin of RTF's?

In fact, in DSSSL I think *everything* is a
sequence constructor. I cannot think of any DSSSL
syntax where the result tree was manifest in the
syntax as result markup/nodes. In XSLT a result
tree fragment is expressed most often as the
desired result manifest in input markup, though
of course one can use instructions to dynamically build parts of the
fragment.

I recall DSSSL coding being labourious in the
verbosity of the sosofo. XSLT is so much more efficient by the manifest
syntax.

regards

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

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

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

> > > too closely associated with template rules and named template. The

> > > name "sequence constructor" was my invention.
> > >
> > > Michael Kay
> > > Saxonica
> > >
> > >
> > > > On 11 Apr 2023, at 16:05, Mukul Gandhi
> > mukulg@xxxxxxxxxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>

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

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