[xsl] Lesson Learned: Don’t write XSLT programs this way

["Roger L Costello costello@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Folks,

For years my strategy in using XSLT to solve complex problems has been this:

Identify the series of transformations that must be performed on the input
data. Create an XSLT program that performs the first transformation. Conduct
tests to ensure the program works properly. Then create a second XSLT program
that takes the output of program#1 and performs the second transformation on
it. Conduct tests to ensure the combination of program#1 and program#2
produces the correct result. Then do the same for the third transformation.
And so forth.

The result is a series of transformations applied to the input.

Seems like a reasonable strategy, right?

No, its not. Its a terrible strategy.

Consider what happens once the project is over. Sometimes I can reuse
program#1 on another project (usually the program needs a little or a lot of
modification). program#2 is specific to the output produced by program#1, so
its not reusable. program#3 is even more specific. Ditto for the other
programs. In other words, at best program#1 is reusable. The other programs
are throwaways. What a waste.

Not only are the programs throwaways, they are all tightly coupled to each
other: program#2 is tightly coupled to program#1, program#3 is tightly coupled
to program#2, etc.

Dealing with the cognitive load of a complex problem is critical. The
cognitive load must be reduced. My approach of using a series of
transformations does nothing to reduce the cognitive load. No doubt there are
people who can handle a high cognitive load. They can effortlessly handle in
their mind a bunch of complex transformations simultaneously. Im not one of
those people. I need things simple. I need a low cognitive load.

My implementation strategy results in horribly brittle, hard-to-debug, and
error-prone programs.

Recently I read about the Unix philosophy:

- Make each program do one thing well. To do a new job, build afresh rather
than complicate old programs by adding new "features".

- Expect the output of every program to become the input to another, as yet
unknown, program. Don't clutter output with extraneous information. Avoid
stringently columnar or binary input formats. Don't insist on interactive
input.

- Design and build software, even operating systems, to be tried early,
ideally within weeks. Don't hesitate to throw away the clumsy parts and
rebuild them.

- Use tools in preference to unskilled help to lighten a programming task,
even if you have to detour to build the tools and expect to throw some of them
out after you've finished using them.

https://en.wikipedia.org/wiki/Unix_philosophy

Using the command shell, combine tools in any way desired, e.g.,

scatter infile | pic | troff >outfile

When I read that I excitedly thought, Yes! That is the right way to build
applications! My, such folly in the way I been my implementing XSLT programs
all these years. The key to creating good XSLT programs -- and any program --
is to make each program do one thing well. Make each program a tool. Combine
tools using the command shell.

Lesson Learned: Dont implement an XSLT program as a series of XSLT programs.

/Roger