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

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

Hi Folks,

Thank you for your excellent feedback!

Upon reading some of the responses, I think my post wasnt clear. I am not
advocating for monolithic XSLT programs. I am advocating for the Unix approach
to solving problems: create independent tools that can be assembled by piping
the output of one tool (one XSLT program) to the input of another tool
(another XSLT program). Rather than dividing up a problem by the series of
transformations that must be done on the input, divide up the problem into
reusable tools. Then assemble the tools via pipes. Just as is done in Unix
development, e.g.,

scatter infile | pic | troff >outfile

Brian Kernighan has an excellent explanation of "tools" in his book "Software
Tools":

"We are going to discuss two things in this book  how to write programs that
make good tools, and how to program well in the process.

What do we mean by a tool? Suppose you have to convert a 5000-line Fortran
program from one computer to another, and you need to find all the format
statements, to make sure they are suitable for the new machine. How would you
do it?

One possibility is to get a listing and mark it up with red pencil. But it
doesn't take much imagination to see what's wrong with red-penciling a hundred
pages of computer paper. It's mindless and boring busy-work, with lots of
opportunities for error. And even after you've found all the format
statements, you still can't do much, because the red marks aren't machine
readable.

Another approach is to write a simple program to find format statements. This
is an improvement, for such a program is faster and more accurate than doing
the job by hand. The trouble is that the program is so specialized that it
will be used once by the author, then tucked away and forgotten. No one else
will benefit from the effort that went into writing it, and something very
much like it will have to be reinvented for each new application.

Finding format statements in Fortran programs is a special case of a general
problem, finding patterns in text. Whoever wanted format statements today will
want read and write statements tomorrow, and next week an entirely different
pattern in some unrelated text. Red penciling never ends. The way to cope with
the general problem is to provide a general-purpose pattern finder which will
look for a specified pattern and print all the lines where it occurs. Then
anyone can say

	find pattern

and the job is done. find is a tool. It uses the machine; it solves a general
problem, not a special case; and it's so easy to use that people will use it
instead of building their own."

/Roger