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

Re: alternating tags in a list?


Subject: Re: alternating tags in a list?
From: Ray Cromwell <ray@xxxxxxxxxxxxxxx>
Date: Thu, 17 Dec 1998 14:22:45 -0500 (EST)

> I think that there are two misunderstandings in this part of your post:
> 
> It isn't theorists versus pragmatists. I'm helping a company with terabyte
> databases implement a million-hits-per-day XSL delivery system. If that
> puts me in the "theorists" camp then who is in the pragmatists one? 

  Are you starting with XML or going from RDBMS -> XML + XSL ->  HTML?

  My question is, why can't XSL have scripting hooks and still
be scalable? Why not simply add the restriction that
any scripting languages used must not mutate the environment
and are restricted to only local variables, and outputing
resulting nodes?

  I don't see any inherent scalability benefit that XSL would
confer over stateless scripting languages. Indeed, XSL+XML
forces the allocation/processing of an enormous amount
live memory objects just to output HTML, whereas a
template/embedded scripting system need only store the
parse tree/byte code of a script, a temporary symbol
table and stack (thrown away after each HTTP request),
and a finite amount of pooled resources (database connections,
cursors, etc) with output being written to a stream.

> My point is that I am not familiar with any cross-platform technology that
> allows arbitrary scripting languages to be plugged into any application.
> Typically, you must either use Windows' Active Scripting stuff, or you
> must plug in each scripting language to your framework individually.
> Plugging each language in is probably the same amount of work as
> implementing the framework in each language.

  I implemented a cross-scripting language library in Java
myself that lets one evaluate Jacl (TCL), Pnuts, FESI (JavaScript),
and JPython. Once I got TCL up and running, getting the
others working was about 1 hour each.

  It's really not much different than SAX, in fact, easier.  (as long
as you don't need a shared namespace between languages. That is, call
subroutines defined in TCL from JavaScript as if they were defined in
TCL ala ActiveScripting)

> Anyhow, implementing an XSL-like pattern->action pattern is quite logical
> and should take the pressure off of XSL to be the be-all and end-all
> replacement for ASP, DOM and everything else.

 I would like something like XSL where the declarative syntax
would handle 90% of what I need to do, but let me drop down
to a stateless/functional scripting language to handle
the exceptional cases.

  Imagine someone else's XSL formatter lands on my desk one
day. A client says, "The gulf war just broke out again,
and I need you to do this new CNN-style layout to repurpose
some of our documents from the last conflict." To my
horror, I find out that I can't modify the existing
XSL script to do what I need. So do I have to rewrite
the entire thing from scratch in another XSL-like language,
or can I simply drop to a scripting language to do whats
needed in an emergency, with full knowledge of what I'm
doing?


I find this whole discussion sort of like the JNI issue in
Java. Yes it's ugly. Yes, it makes stuff less portable.
Yes, it is harder to maintain, etc. But sometimes you
absolutely *need it* Later on, you can rewrite it in
a less ugly, more pleasing manner (pure Java), or in
XSL's case - a post process step.

I hope the XSL WG doesn't do the unthinkable: force everyone
to use Microsoft's "extended standard"


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



Current Thread
Keywords