[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: alternating tags in a list?

Subject: RE: alternating tags in a list?
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Wed, 16 Dec 1998 13:33:42 -0500
mcl script
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

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


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


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.

 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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.