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

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

> There was an XML editor that used XSLT and XSL-FO internally - Serna maybe??
- which i think attempted this optimization.

***WARNING: Not a vendor commercial but perhaps food for thought ***

We have a long time customer that uses a similar approach to things but this
is vendor specific really.
He is one of the most accomplished individuals using our software.
And he does ... menus for restaurant chains.
Those that know me know that I am always customer/use focused.
Meaning, our software has things in it because people need it, not because
it's cool or we should.
I know ... controversy.

I thought ... who the heck would use XSL FO to do menus?
He proved me wrong ... first in not knowing the business where chains have
regional menus, inventory based wine lists, local beers ... so it truly is
variable content.
But a brand ... so everything needs to look the same ... whether you are in
Miami, California, Aruba ... in terms at least of layout.

He built a system like the old days we had for newspapers. Positional/chunked
box layouts but those chunks are FO result tree fragments.
Some from the database or inventory of the wines, regional information, etc.
Right down to the storefront. Brand -> Region -> Sub-region -> City

All sits atop XSL FO. Can formulate result tree fragments that are included
***just like an image*** into the dimensional boxes (but that may be a RenderX
thingy cause we can do that).
Can alarm you on overflows ... can balance columns can do so much more.
Tweak something and view, and set up to quickly "format" only the "chunk" that
changed.

A highly specialized and targeted application.

All possible and using mostly everything in XSL + XSL FO.

Kevin

-----Original Message-----
From: Liam R. E. Quin liam@xxxxxxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, April 11, 2023 2:03 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] XSLT result tree fragment, with XSLT 3.0 and xsl:variable

On Tue, 2023-04-11 at 17:49 +0000, Michael Kay michaelkay90@xxxxxxxxx
wrote:
>
> [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

There was an XML editor that used XSLT and XSL-FO internally - Serna maybe?? -
which i think attempted this optimization.

The idea that you can't inspect the output also lets an implementation use a
different representation, perhaps a lighter-weight one, for result trees. E.g.
you don't need to support sibling or parent axes.

But it was for sure overly onerous!

liam

--
Liam Quin, https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text
Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org