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

["G. Ken Holman g.ken.holman@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

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