[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Interactive XML
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 - 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|