Re: alternating tags in a list?

Subject: Re: alternating tags in a list?
From: Paul Prescod <paul@xxxxxxxxxxx>
Date: Thu, 17 Dec 1998 15:49:10 -0600
Ray Cromwell wrote:
> 
>   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?

That will not satisfy most people pushing for scripting. They will say it
satisfies them until they actually try it and then they will scream bloody
murder and point out that ASP is easier to use (which it will be).

Even so, it hinders scalablity by crippling static analysis (in theory
only where scripting is actually used, in practice probably everywhere).
It hinders portability by depending on scripting languages when there are
environments where they are not appropriate.

>   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.

I don't know what you are saying here. A stateless scripting language
cannot *reduce* the memory usage of an XSL implementation. It can only
increase it. Furthermore, a scripting language cannot write output to a
stream if it is going to work within the XSL data/execution model which
has no such concept.

>   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?

You should drop down to the scripting language! Nobody denies that. You do
the 95% of the work in XSL and you do the other 5% in a pre- or
post-process using some scripting language and an XSL-like framework. This
is drop-dead simple (and common) and does not require scripting in XSL.

Let me paraphrase your statement above: "To my horror, I find that I can't
modify the existing Python script to do what I need so I have to rewrite
the entire thing from scratch in C++." You would never make such a
statement: you would let Python do the 95% that it is good at and do the
other 5% in C++. We do exactly the same thing in the text processing
world, but our "integration API" is the DOM (or the grove, or the text
stream), not some language-specific binding API.

Presumably you do not usually argue that scripting languages should
implement all of the features of systems programming languages: you use
the right tool for the right job and integrate them through any one of
several channels. The same holds for XSL and scripting languages. Think of
it as a Unix pipe: you don't embed C++ in Python or Perl if the problem
can be solved through a pipe.

How do you add scripting to a SQL query? You don't send JavaScript along
with the SQL (I hope not!). You define a stored procedure external to the
query. Why is that? Because SQL is designed to be scalable, portable and
optimizable. The stored procedure stuff is system specific and
hard-to-impossible to optimize.

> 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.

The analogy is not good. The amount of effort required to write this
Javascript stuff as a post-process is *roughly the same* as implementing
it in XSL directly if you have a decent Javascript framework (and only a
little harder if you have only the DOM). This is ALWAYS true. XSL provides
nothing "inline" that it cannot provide by annotating the output tree.

I have this feeling that people do not trust that this is the case, even
though they can't think of any *particular* problem that cannot be
decomposed in this way. Why not give XSL a chance as it is and then judge
whether the post-process solution is really so onerous *after trying it
for a few months*.

---

>   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.

Using the JVM is cheating. It already does all of the hard work for you.
Try adding Perl to your mix. But that's neither here nor there. The point
remains that there is no single cross-platform API for embedding scripting
languages into arbitrary applications written in arbitrary languages. It
must, in general, be done by hand for each language.

And if there were such a framework, its would allow the development of the
language-independent application proposed by Didier PH Martin: an XSL-like
scripting application framework. It would make it even LESS necessary to
embed scripting in XSL! Until that tool arrives, however, we just have to
implement an XSL-like framework for the major scripting languages ... a
few weeks of work each.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

"Sports utility vehicles are gated communities on wheels" - Anon


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


Current Thread