Re: Interactive XML

[Paul Prescod <papresco@xxxxxxxxxxxxxxxx>]

Kent Fitch wrote:
> 
> 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.

If you are distributing these massive programs over the Web just to format
your XML documents then you are in big trouble already. Nevertheless,
ECMAScript and Scheme have roughly equivalent feature sets and it is
demonstrably the case that people are delivering production applications
in DSSSL, (which uses Scheme for an expression language).

Furthermore, before there was a DSSSL, most large-scale SGML processing
was done in Omnimark, Perl, Balise and TCL... These are not very
structured languages! Omnimark is sufficiently expensive that people DO
take the time to investigate alternatives before they buy it...and Java is
just not an alternative.

Let me suggest that the very nature of document processing is inherently
more amenable to dynamically typed language. The majority of document
processing is about poking around the tree asking "what are you?" Static
typing doesn't help much there!
 
> 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!

I haven't seen any evidence that the "bulk" of the task requires a full
software engineering language, especially a strongly typed one.
 
> >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.

That is not the same thing as textual embedding. JavaScript was designed
to be used at the expression and/or function level (just like Scheme).
Java was designed ONLY to be used at the class level. Java is so rabid
about this that there is no "main function" in Java: it must be a method
of a class. Java is so restrictive that there is no way to make functions
outside of classes at all! Java is so bloody restrictive that it is
essentially impossible to pass around method pointers without wrapping
them in classes.

That's great for Java's application domain. It is terrible for stylesheet
processing.
 
> I dont think Java is any of these, and rather than "move to" why not
> "add as an option"?

Options cost. They cost in training, support, language definition,
implementation complexity and popularity.
 
> I would have thought it easy to present the same object model of the
> browser environment to both EcmaScript and Java?

Sure. That's what DOM is about. But Java does not make it as *convenient*
to get access to the "containing environment" as JavaScript does.
JavaScript allows you to play fast and loose with the "this" pointer so
that you don't even know that the information you are playing with comes
from an object in the environment.
 
> 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.

I think that DSSSL shows that a language with roughly ECMAScript's
features can scale up to answer the problems of real-world development.
Java would not do any better.

 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