Re: alternating tags in a list?

keshlam@xxxxxxxxxx wrote:

> >From: "Lawton, Scott" <slawton@xxxxxxxxxxxx>
> >> From: Paul Prescod [mailto:paul@xxxxxxxxxxx]
> >> My guess is that inline ECMAScript will:
> >>  * reduce the number of actual XSL implementations,
> >
> >Whatever the merits of your other reasons, I don't think this one is
> >compelling.  For better or worse, ECMAScript is already a standard and
> >browsers already implement it.
>
> Please remember that not all styling runs in browsers. And even in the
> browser arena, ECMAScript isn't the only language in play.
>
> The Right Answer would be an API that allows _multiple_ languages to be
> plugged in, if that can be done. Among other things, that increases the
> odds of being able to talk to other software systems if you need to do
> something _really_ obscenely complex in your styling (such as using the
> data to generate a reference to a dynamically-created bitmap).

I don't think this idea would be too hard to implement.  Of course this
would make your XSL not cross-platform as you would be depending on an
external language to process some of your data, but the people who will
need this functionality in all likelihood will be doing the transformations
at the server level in which case this would not affect the client at all.

In this case, escaping to another programming language for processing would
be much like calling native functions using JNI in Java.

Just have a simple function syntax where you pass parameters (this would be
where closer integration with the DOM spec could be very useful) to an
external environment and a processed node is returned.

I have no objections to this as client browsers could choose to have
JavaScript processing support, Java processing support, PERL processing
support etc. as they see fit.  At the server level, you can do whatever the
heck you want.

Tyler


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