Subject: Re: Interactive XML From: "Kent Fitch" <kent.fitch@xxxxxxxxxxxx> Date: Tue, 30 Jun 1998 12:24:03 +1000 |
Paul Prescod <papresco@xxxxxxxxxxxxxxxx> wrote: >> I agree with "dismally inadequate" - the escape to a "scripting language" >> is provided as a way to perform unanticipated processing to meet >> specialist needs (hopefully the common stuff will be provided in core >> XSL). As such, the "scripting language" needs to be general purpose and >> powerful, including features programmers are now starting to take for >> granted such as exception handling, strong typing and inheritance. > >This is not true. Stylesheet creation is not general purpose programming. >It is more akin to other types of special-purpose programming: database >apps (VB, Powerbuilder, Python), text processing (Perl, Python) and so >forth. I would be quite annoyed if I had to treat small extensions to my >stylesheet as if they were large software engineering projects: declaring >types, declaring variables, declaring exceptions, etc. I wish it were true, and at the start, I suppose it is; and then you show the users the output and they say - "That's great, except could you...". And before you know it, the script gets bigger and more complicated, and unless you are using the right tools you end up with an unstructured, unmaintainable mess. Things that are "simple" or "normalized" with inherititance and secure and predictable and recoverable with error handling and strong type checking become complex and unreliable. I've done a lot of scripting with EcmaScript and I love it for what it does well. Now maybe we are misusing XSL; maybe we should be preprocessing the XSL thru something like SAXON and just get the XSL to do the "finishing touches"; I honestly dont know! >> Although some will argue that using a language such as Java will >> discourage casual script writers which may be happier with EcmaScript, I >> suggest that it is important that a widely understood and implemented >> language such as Java be at least a scripting option: JVM's will soon be >> everywhere - why not use them? > >This paragraphs seems to be quite a fallback from your previous one. First >it was "ECMAScript is all wrong" and then "well, maybe Java is not quite >right, but it is really easy to implement." I think that XSL should be >completed with an ECMAScript automation language for now, because it is >much closer to the right thing than Java is. Stylesheet developement is >not general purpose programming. If you want to use Java for XML >processing, there is a rich and robust set of tools that allow you to do >that ALREADY. I dont think EcmaScript is "all wrong" at all! I think it is a good *option*, and that Java is another good *option*, and I would like XSL to allow me to escape to either. But your last statement is quite valid, ie, we could preprocess the XML thru Java and take the output from that thru XSL. But I would rather we didnt have to do this, and cant see why it helps to not allow Java as a processing language. If Java implementations were rare, expensive, buggy then I would understand, but they are not. >ECMAScript is also designed explicitly to be embedded. Java is not. A Java >program is defined as a series of Java classes. Are you going to put a >class in each XSL rule??? That doesn't seem right. Oh, I "embed" java applets in HTML all the time. They even have access thru the applet environment to some model of the environment they are running it. Paul Prescod replying to Denis Hennessy: > 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 I dont think Java is any of these, and rather than "move to" why not "add as an option"? > ... 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. I would have thought it easy to present the same object model of the browser environment to both EcmaScript and Java? > 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. If it is deemed that the "escape to script" function is for implementing only simple processing, you are completely right. It is on this point that I am confused, and I dont see why, given the availability of JVM implementations, an "escape to EcmaScript or Java" isnt a better option. Kent Fitch Ph: +61 2 6276 6711 ITS CSIRO Canberra Australia kent.fitch@xxxxxxxxxxxx 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: Language choice (was: Re: Inter, Brandon Ibach | Date | RE: Interactive XML, Pawson, David |
Month |