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 background. 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT use cases; data-cent, Dimitre Novatchev | Thread | Re: [xsl] XSLT use cases; data-cent, Dimitre Novatchev |
RE: [xsl] Can I use a boolean varia, Wendell Piez | Date | RE: [xsl] Can I use a boolean varia, JBryant |
Month |