[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Application Design
- From: Paul Tchistopolskii <email@example.com>
- To: firstname.lastname@example.org
- Date: Sun, 12 Aug 2001 17:57:56 -0700
> > I think that the problem with XSLT is that XSLT
> > is often misleading, pretending to be more
> > 'powerful' and 'portable' than it actually is.
> I don't think 'hype' is the problem at all. The 20% part of XSLT is easy to
> learn too, so learning curve is not the problem either.
I agree. However, I wanted to say that from my point of view ,
because of the hype, there is a real problem to find out
what particular 20% of XSLT to learn and use.
> The problem is that there is no real need to learn XSLT.
I disagree. I'd say that at the moment, XSLT is the 'only'
existing *scripting* language for simple server side
processing of XML.
XSLT has some place. The place is like 'sed + grep', or
something like that. Well, 100% conformant XSLT is
a bad 'sed' and it is a bad 'grep', but with saxon:evaluate,
XSLT makes a 'real' grep and almost 'real' sed.
What are the scripting server-side alternatives to XSLT ?
- Matt's XPathScript is "perl only"
- Omnimark ... is ... well ... proprietary and too complex
- SAX / DOM are too low level for sed-alike trivial tasks
Somehing like DOMScript could be nice, but I'm not aware
of such a thing. Maybe it does exist...
XSLT is 'the only' scripting engine for trivial server-side
XML processing. It has *plenty* of problems, but for some
tasks it is better, than nothing.
> Observe that:
> 3. Learning an API like DOM is far easier to learn a new declarative
> language like XSLT.
> 4. Once you learned DOM, there is no real need to learn XSLT.
If you're talking about the client side, I agree ( in fact,
this view have been presented by Mr. Leventhal two+
years ago and I think it still remains valid.)
However, on a server side, writing a chunk of low-level DOM code
just to reorder / rename some attributes looks like an overkill.
> While DOM-based solutions are harder to implement and maintain, there are
> plenty of people available with DOM expertise. This is not true for XSLT.
> combination will be the preferred method of implementation.
You're talking 'client side'. I agree.