[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Application Design

• From: Robin Berjon <robin@k...>
• To: xml-dev@l...
• 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" 
> 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. 

• References:
  • RE: Application Design
    • From: Sean McGrath <sean.mcgrath@p...>

• Prev by Date: RE: Application Design
• Next by Date: RE: Application Design
• Previous by thread: RE: Application Design
• Next by thread: Re: Application Design
• Index(es):
  • Date
  • Thread