Re: Interactive XML

Subject: Re: Interactive XML
From: "Denis Hennessy" <denis@xxxxxxxx>
Date: Tue, 30 Jun 1998 10:55:18 +0100
>> It depends what you're trying to use XSL for. As a client-side 'style
>> formatter', ECMAScript is probably fine but I think a much more
>> use of XSL is as a server-side dynamic generator of HTML pages which are
>> browser neutral (or more likely, browser sensitive).
>This use is outside of XSL's mandate. I think that a slight XSL extension
>should be able to support it, but there is no sense in which this is
>"standard XSL's job." Check the requirements spec. Generation of arbitrary
>HTML pages is not "formatting." That's transformation.

Like it or not, server-side XSL processing is going to account for a sizable
portion of the xsl 'application-space'. Once sites commit to providing data
via XML, it's the obvious fallback for clients that don't have XSL support.
Almost nobody can afford a rigid 'make them upgrade' (let them eat cake ;-)
approach to customers with old browsers.

>> 1. ECMAScript has no mechanism for handling errors. Microsoft have added
>> proprietary try...catch statement in their JScript engine in IE5 which
>> badly needed.
>ECMAScript has no error handling, but a particular environment could
>provide it, as the browser environments do today. The same can be done for

Obviously, proprietary extensions could fix any problem but allowing
alternate languages fixes it in a portable way.

>Sure, I would prefer a language with more structured exception handling,
>but I'm not going to throw out the baby with the bathwater and move to a
>language that is either a) too complicated or b) too static or c)
>unstandardized. That pretty much leaves us with the choices of Scheme and

Nobody's suggesting abandoning ECMAScript. Having the option to use Java as
an alternate language would add a lot of value.

>> 2. There is no mechanism in the scripting model to pass external
>> into the embedded script. For example, a server-side formatting
>> would be much more flexible if it could access a 'browser capabilities'
>> object, for example.
>This is not true. Every HTML-embedded JavaScript program has access to a
>browser object that has full access to "browser capabilities." ECMAScript
>was specifically designed a) to make this possible and b) to make this
>highly convenient. Java was not. The same can be done for XSL.

Firstly, the browser capabilities object is only available to JavaScript
programs executing in the context of a browser (i.e. not on a server).
Secondly, the browser capabilities object is only an example of what is
useful here. Imagine a user preferences object describing whether the user
wants frames or not, what fonts and colors to use, ...

>> 3. This is perhaps more a wish than a flaw: I would really like to be
>> use scripts to influence which rules fire in addition to using scripts in
>> actions.
>This has nothing to do with ECMAScript. I think that it is a bad idea, but
>ECMAScript could support it more naturally than Java or any other
>standardized language I can think of other than Scheme.

You're right. It's a separate issue but I think it would enable more
powerful (and more concise) stylesheets.

>I'm not particularly a fan of ECMAScript, but the complaints people have
>with it seem mostly specious. XSL is exactly the type of environment
>ECMAScript was designed to be used in. Since there is only one other
>language (that has already been deemed unacceptable) that is even vaguely
>applicable, I don't see the point in complaining about ECMAScript.

The point is that there some problems with ECMAScript when used for XSL
processing and it's valuable to discuss it openly to see if the problems can
be solved with either some extensions to the framework or by allowing other

Denis Hennessy

 XSL-List info and archive:

Current Thread