Re: Application Design
On Monday 13 August 2001 11:24, Sean McGrath wrote: > "XSLT is better at down translations that up translations; if your > transformation is going from a less-structured form to a more-structured > form, XSLT may not be a good choice" > http://www.biglist.com/lists/xsl-list/archives/199908/msg00210.html That's very true, but I feel it goes with it being the specialized language it is. Probably the only way you can turn less structured into more structured is by making serious use of document(). Otherwise, XSLT has no way of accessing external data, and thus cannot add much to what it is processing. If it were given the ability to fetch from a wider array of input sources, it'd immediately become more complex. Like Al Snell I've pondered the possibility of using extension functions that would run some SQL and autoconvert the output. At a simple level, it's not hard to do, especially as there are already many packages that can take care of the translation to XML part for you. However I don't believe that XSLT is the place to put all those features into. It is a nice and simple enough (in a sufficient number of cases, when it does get hairy, think twice) language that does its job well. There are walls and there are dragons, and one needs to know them. I'd be happy to hear about a language in which that is not the case. > Most non-textbook XML transformations I am involved with require > either a) PCDATA based manipulations and b) external > integration e.g. dbms, web services etc. Insofar as they are possible > with XSLT they are complex and read-only at best. In many cases > they are just not possible at all. That's why I use the pipe model as much as possible. Most of the transforms I get to do become much simpler with at least two style sheets in a row rather than a single hairy one. This also makes it easy to insert a non-XSLT processor in the middle, for instance any kind of SAX processors, that will do transforms on some parts that XSLT isn't good at (eg PCDATA). Just as well, integration with DBMS, web services, and so forth happen (usually in my case) before the transformations. It is often much simpler to dump the data structure output by the app to XML in some automated way (I tend to use XSP. I don't know how it is in Cocoon, but in AxKit writing taglibs is trivial as it only requires some simple knowledge of SAX, and in many cases not even that as you can declare "tag signatures" and how they'd map onto functions to call). That's much simpler than writing directly to the desired output format. After that, I let XSLT take care of all those dirty tree transformation things, which honestly would be a pain to write in other code. I just wish people would stop trying to have XSLT do everything. Otherwise it'll just become yet another HTML. -- _______________________________________________________________________ Robin Berjon <robin@k...> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com ----------------------------------------------------------------------- There's too much blood in my caffeine system.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format