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

Re: Interactive XML


Subject: Re: Interactive XML
From: Paul Prescod <papresco@xxxxxxxxxxxxxxxx>
Date: Mon, 29 Jun 1998 15:11:59 -0500

Denis Hennessy wrote:
> 
> 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 compelling
> 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.

> 1. ECMAScript has no mechanism for handling errors. Microsoft have added a
> proprietary try...catch statement in their JScript engine in IE5 which was
> 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
XSL.

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
ECMAScript.
 
> 2. There is no mechanism in the scripting model to pass external 'context'
> into the embedded script. For example, a server-side formatting stylesheet
> 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.

> 3. This is perhaps more a wish than a flaw: I would really like to be able
> 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.

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.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

Three things trust above all else: Your knowledge of your craft
That someone turns a profit, and that you will get the shaft
http://www.geezjan.org/humor/computers/threes.html


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



Current Thread
Keywords
xsl