[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Application Design
- From: Francis Norton <email@example.com>
- To: Sean McGrath <firstname.lastname@example.org>
- Date: Mon, 13 Aug 2001 15:35:19 +0100
Sean McGrath wrote:
> James Clark himself has been known to post to this list about the application
> areas where XSL is probably not the right way to go:
While I agree with both the comments quoted, I would point out that the
editors of the XSLT spec weren't infallible, and if anything tended to
err on the side of being over-conservative about scope. For example,
restricting RTFs (Result Tree Fragment, the data type mainly returned by
complex operations) so that it could only be processed as a string, not
as a XML sub-tree, turns out to have been fairly gratuitous.
> XSLT has its uses but it is surprisingly useless in some
> common server-side scenarios.
We have found it fairly effective, though the lack of debuggers has been
a nuisance. There is a learning process, but everyone using XML needs to
learn XPath anyway (*please* don't tell me anyone is seriously
programming complex transformations by using pure DOM navigation) and
once you've go that, the rest of XSLT isn't that indigestible -
certainly no more of a leap than going from sequential to event-based
> XSLT gets complicated quickly. The side-effect free nature
> of its processing model causes much pain for developers.
> The theoretical reason for this - parallelization of execution
> of the stylesheet - seems to me to be unjustified. It puts too
> much complexity on the programmers plate for what is after
> all an optimisation feature.
Some bits are complicated, especially to do with grouping and loops. But
if people couldn't cope with declarative stuff neither SQL nor regular
expressions would have taken off. I can still remember people telling me
how complicated SQL was to learn. As Keynes said (more or less), today's
common sense is just yesterday's theories.
> Arguments against the "just use XSLT" mantra, including this
> one, will be pooh poohed by vendors who know full
> well what the limitations are but see lots of $$$ in
> debuggers, visual tools, consulting etc. etc.
I suspect that most popular programming language more complicated than
DOS batch language have an IDE or two, and a user base split between
those who understand the fundamentals and those who just know how to use