Re: Interactive XML

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
>> 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
>> 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
>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
>stylesheet as if they were large software engineering projects:
>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
>> everywhere - why not use them?
>This paragraphs seems to be quite a fallback from your previous one.
>it was "ECMAScript is all wrong" and then "well, maybe Java is not
>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
>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
>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
> but I'm not going to throw out the baby with the bathwater and move to
> language that is either a) too complicated or b) too static or c)
> unstandardized. That pretty much leaves us with the choices of Scheme
> 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."
> 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
> 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
> 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:

Current Thread