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

["Paul Tyson phtyson@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

> On Apr 11, 2023, at 15:06, G. Ken Holman g.ken.holman@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> o;?At 2023-04-11 19:46 +0000, you wrote:
>> 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?
>
> Actually, no. I think a sosofo is more like a sequence constructor.
>
> 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.
>
I learned DSSSL many years ago from Ken. I keep a paper copy of the spec on my
bookshelf. The style language and transform language both worked on grove
input. A transform specification emits  create-specs and
transform-grove-specs, which could then guide the creation of groves which
could be serialized however you wanted. A style spec emits sosofos, which
could then be typeset and emitted in the page description language of your
choice.

So I would say RTFs hark back to (result) groves, and xsl-fo to sosofos.

bPaul

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