[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Application Design
- From: Robin Berjon <email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 13 Aug 2001 13:25:14 +0200
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"
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
> 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
I just wish people would stop trying to have XSLT do everything. Otherwise
it'll just become yet another HTML.
Robin Berjon <email@example.com> -- 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.