Re: [xsl] XSLT use cases; data-centric todocument-centrictransformations

Subject: Re: [xsl] XSLT use cases; data-centric todocument-centrictransformations
From: JBryant@xxxxxxxxx
Date: Tue, 8 Feb 2005 13:39:01 -0600
I have done both kinds of transformations. In fact, I currently work (as a 
consultant - I have my own little business, really) at a firm that 
specializes in data warehouses for the insurance industry. I wrote two XSL 
stylesheets that create documents to describe (the descriptions are stored 
as metadata in the warehouse, by the way) the elements in the warehouse. 
One stylesheet produces an FO file that I feed to FOP and one produces 
HTML files (one per element and some other files). At the same time, I use 
XML as the storage and editing format for user guides and API guides and 
other "conventional" documents and then use two other stylesheets to 
produce PDF and HTML output for those documents. I also wrote the DTDs for 
all of it, so I have had the luxury of defining the input that I 
transform. I find that XSL supports either use case very well, provided 
one works with the language rather than trying to force it work like some 
other language. To that end, I use templates and recursion a lot and 
rarely use for-each statements. One big template with a bunch of for-each 
statements would strike me as ill-conceived whether the source of input is 
a database or a document.

> Of course, some people do write very long methods --
> I have seen a method, whose code occupied 29 printed
> pages. With such a beast the question "What does this
> method do?" becomes very difficult to answer.

Unlike most of the folks on the list, I am a writer rather than a 
programmer. I CAN program in half a dozen languages and have done so for 
varying percentages of my job for 17 years, but I always do it as part of 
helping my readers understand, not as the main task. (The exception is 
actually XSLT and XSL:FO, which I use to create my output documents these 
days.) From that point of view, I can tell you that a 29-page method would 
be very unwelcome. The only time I've seen something like that (a 36-page 
class) was from a C programmer who had been told to write his code in C++, 
so the class was basically a wrapper for a C program. Anyway, enough 

If I may suggest a slightly different rule of thumb, I prefer "Each method 
must have a goal that can be stated in one sentence." I have helped a 
development team develop a new product that included an extensive API, and 
we did very well by sticking to that rule. We did break it for classes, 
but not often. We also stuck to the class=noun, method=verb idea, and that 
helped a lot, too.

Anyway, I have wandered off topic, but "method, whose code occupied 29 
printed pages" creates a certain gut-level reaction....

Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)

Current Thread