Re: alternating tags in a list?

[Tyler Baker <tyler@xxxxxxxxxxx>]

Toivo Lainevool wrote:

> ---Guy_Murphy@xxxxxxxxxx wrote:
> > I agree whole heartedly. Extrapolating the arguement of we don't
> need to
> > impliment that in XSL because you can do it with DOM elsewhere would
> > quickly paint XSL into a corner considering that we can do
> everything that
> > XSL will do with the DOM elsewhere. In which case why do we need XSL.
> >
> > "We can do it with the DOM elsewhere" isn't isn't a valid arguement
> for not
> > doing something in XSL. The point of XSL should surely be that it be
> an
> > ideal language for transforming and rendering XML, if you point to
> > something else to use instead then you've shot XSL in the head.
> >
> > Now I am in favour of XSL, I am in favour of finding solutions for XSL
> > performing tasks like alternating tags etc.
> >
> > I am also in favour of allowing access to ECMAScript where
> available, I
> > don't see why developers should be prohibited from esaping to
> ECMAScript if
> > it's their prefered option because of a virtuous ideal. This also
> allows
> > people to approach the learning curve of XSL in a gentler manner when
> > comming from procedural backgrounds.
>
> What's the difference between "do it with DOM elsewhere" and "escaping
> to ECMAScript"?  Don't both of these just allow you to do things that
> XSL wouldn't allow you to?  Making ECMAScript _the_ choice for XSL
> somehow seems wrong.  Couldn't you use ECMAScript on your XML after
> XSL is done with it to do those little extras you couldn't get done in
> XSL?

Good point.  A lot of people who use Java Servlets could make the argument
to embed Java itself in the XSL spec because Java is cross-platform, runs on
web-servers as well as web browsers, and is a full-featured programming
language.  Of course then you could make the argument why on earth you need
XSL in the first place and not just Java.

If ECMAScript is embedded in XSL, I will recommend to my clients to avoid
XSL altogether as it will become too complex to support.  If you want to
kill XSL's momentum just bloat it with all sorts of stuff that only 1% of
the people out there may actually use.  The speed at which XSL has developed
has been so slow and secretive that much of the momentum is already gone.
Make XSL into some behemoth that only a few vendors will have that staff to
support, then you will likely kill all interest in XSL altogether and throw
it into the same coffin as OpenDoc.

Tyler


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list