Re: Interactive XML

Subject: Re: Interactive XML
From: Paul Prescod <papresco@xxxxxxxxxxxxxxxx>
Date: Tue, 30 Jun 1998 10:49:12 -0500
Denis Hennessy wrote:
> 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.

That's all very well and good. But the W3C does not really spend much
effort standardizing things on the server side. You want the ODMG or OMG
or something. The W3C is primarily concerned with the stuff that flys
across the Web.

XSL can easily be extended for server-side development, but I see no
reason that the *official* standard should spend much energy on it.
> >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.

There is nothing "proprietary" about extending ECMAScript to make it fit a
certain problem domain. ECMAScript was *designed* to be extended in this
way. The spec. has a whole chapter on how to go about it.
> Nobody's suggesting abandoning ECMAScript. Having the option to use Java as
> an alternate language would add a lot of value.

You have that option. Just not within the standard XSL documents that fly
across the wire from client to server.

> Firstly, the browser capabilities object is only available to JavaScript
> programs executing in the context of a browser (i.e. not on a server).

That object is available whereever a host makes it available. That can be
a browser OR 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, ...

Great. So the host provides more objects. ECMAScript can do this easily.
> 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.

I don't think that anybody has presented evidence that there are really
problems with ECMAScript in this context. Most of the problems people are
raising are non-existent.

Let me qualify my statements with this observation: I am completely in
favour of XSL-like languages that use Python, Java and every other cool
language under the sun. I am *against* the idea that the data that flies
across the Web should be in any arbitrary language, or even in "ECMAScript
or Java." There should be a single XSL language, and it should use
ECMAScript. The other XSL-like languages would be cool tools for use on
the server side, or on the intranet, but should be clearly differentiated
from the standard.

 Paul Prescod  -

Three things trust above all else: Your knowledge of your craft
That someone turns a profit, and that you will get the shaft

 XSL-List info and archive:

Current Thread