Re: XQL + XSL = Better (kinda like scripting)

Subject: Re: XQL + XSL = Better (kinda like scripting)
From: Tyler Baker <tyler@xxxxxxxxxxx>
Date: Sat, 14 Nov 1998 16:26:51 -0500
Paul Prescod wrote:

> Andrew Bunner wrote:
> >
> >   "How hard do you want to make it for someone to write an XSL engine?"
> >
> >   Your XSL engine would have to include an interpreter for a language that's
> > almost as complicated as C++.
>
> The complexities of Ecmascript and C++ are not even on the same order.

I really don't like the idea of adding any old scripting languages to XSL, but if
some sort of scripting is put into XSL, there will need to be some standard API
(like SAX is for XML) for how to process scripts within XSL with an external
script interpreter (such as a JavaScript interpreter).  Making XSL bloated with a
whole lot of various scripting language bindings defeats the purpose of XSL in the
first place as you might as well just use plain old PERL or plain old Javascript
instead to get the job done.  The interesting thing about the W3C from my
perspective is that it seems like it is trying less to be a standards body and
more like a technology innovator.  When standards bodies try to create new stuff,
they fail more often than not and worse yet it stagnates the industry because
standards bodies inherently encourage groupthink.  The real world users I have
worked with like XSL a lot how it is now, and would probably be disheartened if
XSL became too complex and too large for the average webmaster to work with, or
else became too complex and too large for any reasonably size ISV to write an XSL
Processor for.  If you have to include support for an entire scripting language
(or set of languages) into XSL, that raises the bar to the point that
realistically the only companies that have the staff to support such a monster are
the very obvious ones.  If this happens why should anyone but the big guys care
about XSL?

Tyler


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread