Re: Application Design

[Paul Tchistopolskii <pault12@pacbell.net>]

> > 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:
> 
> 1. People had to learn HTML and JavaScript because there were no
> alternatives.
> 2. Learning HTML and JavaScript lead directly to XML and DOM.
> 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.
> Even if XSLT become universally available in browsers, JavaScript and DOM
> combination will be the preferred method of implementation.

You're talking 'client side'. I agree.

Rgds.Paul.