Re: [xsl] I love programs that output programs

["ajbufort@xxxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

I have great interest in, and experience with, dynamic transform creation.



Ibll add to this thread that it can get tricky if a transformation starts
out ingesting plain text and then transforms it to XML, and THEN expects to
continue processing that result within the same transform.  If it is a huge
file, it would likely not be practical to stick the result in a variable and
then run further transformations against that variablebs contents in that
same transform.  In addition, there are other gotchas to storing the output in
a variable for re-processing later, depending on the data and its encoding.
And if you output the file as XML first, and THEN want to try to re-ingest it
and process it within the same transform, you will run across the Saxon
protective measure of prohibiting ingesting a file you have just output within
the same transform.  Admittedly, to get around this at times, I will output
the XML to a file during a transform, programmatically re-name it via the same
transform, and then continue processing.  (This has worked well enough for me
to use more than once, though Ibd rather avoid it in favor of better options
when I deem it desirable.)  There are other ways to get around it as well, but
youbd do well to remember that the prohibition is there for a reason, so
donbt get so creative that youbll shoot yourself in the foot.



Transforms that generate transforms are fun to write and work well for me, but
these are meant to be run only once, with the resultant transform or set of
transforms then being the code that is altered and worked from after that.  If
the initial transform is meant to be run more than once/regularly, then I
fully concur with Dimitre b multi-pass is your way and your friend.  I also
concur that it can often be a case of bgood luck to thatb in terms of
getting others to understand what youbve written if you have half-a-dozen or
more modes youbre working.



In the aerospace domain Ibve worked in for many years during my career,
itbs a given that the transform sets are going to be multi-modular,
multi-modal, and quite complex (as in
Ibll-need-that-FO-area-tree-as-well-to-run-modes-against-that complex, for
example). p	  Ibve learned that project organization can also be your
friend in that case, though there are many ways to skin that cat in terms of
simplifying things.  One way is to isolate templates involving the same mode
within their own file, but this might be undesirable depending on the nature
of your project, its modal passes, and its templates.  Other ways might make
more sense.  As an architect who has led teams as well as being a developer, I
have often struggled with this in terms of making the code and project
organization work well for everyone.  My lesson learned b you can never make
everyone happy.  But you can create well-working setups and defensible
positions.  Same for dynamic code construction and organization. p




-Tony



Anthony J. (Tony) Bufort

Owner, AJB Consulting

Renton, WA USA





From: Dimitre Novatchev dnovatchev@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Saturday, January 18, 2025 11:23 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] I love programs that output programs



> As Dmitre notes, itbs easy to write things that are hard to read, so
>   you do have to be careful not to overdo it.

In my practice I have done something more practical and convenient than
writing an XSLT transformation ( a set of stylesheets)  that generates another
XSLT transformation (another set of stylesheets) that generates yet another
XSLT transformation (yet another set of stylesheets), ..., and so on, ... , ad
finitum  ...



What is significantly more pragmatic, convenient, readable and doable is to
write:

*	Just one set of stylesheets/templates.
*	Generate as the result of each pass new data (XML).
*	Have all templates that must transform DataN.xml into DataNPlusOne.xml, be
in the same mode, let us call it "passN".

This really works well, much better than generating XSLT code again and again,
though even this better approach has its limits: when I wrote such a 5-6 pass
transformation, there was no one that could understand what this was doing,
but me ...









On Fri, Jan 17, 2025 at 9:46b/PM Liam R. E. Quin liam@xxxxxxxxxxxxxxxx
<mailto:liam@xxxxxxxxxxxxxxxx>  <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx
<mailto:xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> > wrote:

On Fri, 2025-01-17 at 20:22 +0000, Roger L Costello costello@xxxxxxxxx
<mailto:costello@xxxxxxxxx>
wrote:
> Hi Folks,
>
> Recently I was reading Brian Kernighan's new book on AWK,

Awksome! I hadn't known there was one.

One of the first complex text processing programs i wrote was to read a
bunch of text files, identify all of the references, and produce a sed
script that would replace them with calls to a "refer" database (refer,
written by Mike Lesk at Bell labs in the Unix group, was the
inspiration for bibtex).

Coincidentally the source code for refer was pretty weird, and i
remember
        main(argc, argv)
         int argc; char **argv;
        {
          . . .
          if (argv[0] < 16000) {
              ...
          }
        }
which to anyone who knows C was a little startling.

Programs that produce programs can be super useful.

Ibve done a bit with generating XSLT on the fly with XSLT, and then
running it with fn:transform(), which can be super powerful.

Although much of the need to do that is reduced by XSLT shadow
attributes, there are still cases where itbs helpful. An example might
be reading a namespace name from an input document, and writing XSLT on
the fly to remove it without affecting others. Therebs other ways to do
that, but hey, itbs fun :)

As Dmitre notes, itbs easy to write things that are hard to read, so
you do have to be careful not to overdo it.

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








--

Cheers,

Dimitre Novatchev

---------------------------------------

Truly great madness cannot be achieved without significant intelligence.

---------------------------------------

To invent, you need a good imagination and a pile of junk

-------------------------------------

Never fight an inanimate object

-------------------------------------

To avoid situations in which you might make mistakes may be the

biggest mistake of all

------------------------------------

Quality means doing it right when no one is looking.

-------------------------------------

You've achieved success in your field when you don't know whether what you're
doing is work or play

-------------------------------------

To achieve the impossible dream, try going to sleep.

-------------------------------------

Facts do not cease to exist because they are ignored.

-------------------------------------

Typing monkeys will write all Shakespeare's works in 200yrs.Will they write
all patents, too? :)

-------------------------------------

Sanity is madness put to good use.

-------------------------------------

I finally figured out the only reason to be alive is to enjoy it.



XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>

EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/3322603>  (by
email <> )