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

["Kevin Brown kevin.brown@xxxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Exactly. Sequence of Flow is different ... it was/is a sequence constructor.
> I recall DSSSL coding being labourious in the verbosity of the sosofo. XSLT
is so much more efficient by the manifest syntax.

Again, this is so true. IMHO that was the "greatness" and "downfall" of
DSSSL.
Many/most/(ok all) vendors would have huge issues trying to implement in a
useable manner.
I know this is not the goal of standards but still ... I digress.

While Ken my not recall this, I can remember sitting at dinner in Miami Beach
with him having nearly this same conversation many, many moons ago.

Kevin Brown
RenderX

-----Original Message-----
From: G. Ken Holman g.ken.holman@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, April 11, 2023 1:06 PM
. To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] XSLT result tree fragment, with XSLT 3.0 and xsl:variable

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.

. . . . . 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:09C"b,B/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 |