[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: alternating tags in a list?

---

---

Hi Guy,


This is right. We tested xsl with scripts written in:
- vbscript
- JavaScript
- Perscript
- Pythonscript
- MCLScript

and it worked well with all. In fact, it will work with any script engine
supporting the the IActiveScript/IActiveScriptParse interfaces. As you
noticed MCLScript is not as known as the others. We created it by
implementing the former interfaces and it worked as well with XSL. So, as
long as an interface is defined, any script language iplementer could add
value to what's already there. This is an open architecture. Any language
independant interface system would also do the job as well.

Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com

-----Original Message-----
From: owner-xsl-list@xxxxxxxxxxxxxxxx
[mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of
Guy_Murphy@xxxxxxxxxx
Sent: Wednesday, December 16, 1998 12:31 PM
To: xsl-list@xxxxxxxxxxxxxxxx
Subject: Re: alternating tags in a list?



Hi.

I believe with  the IE5b2 version of XSL you can use any scripting language
with an ActiveScripting implimentation.

Cheers
     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 12/16/98 07:12:59 PM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  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






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


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

---