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 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. 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 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. 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 >ECMAScript. 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 '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. 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 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. 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 languages. Denis Hennessy XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Interactive XML, Paul Prescod | Thread | Re: Interactive XML, Paul Prescod |
Re: How to do XML to XML translatio, Stefan Trcek | Date | Re: Interactive XML, Michael Kay |
Month |