Re: XSL with scripting

Subject: Re: XSL with scripting
From: Ray Cromwell <ray@xxxxxxxxxxxxxxx>
Date: Tue, 22 Dec 1998 21:50:33 -0500 (EST)
> The question more importantly would be how you would support scripting and
> to what extent.  I am personally against adding scripting because learning
> entire new programming (scripting languages) to use XSL I feel defeats its
> use in the first place as a simple stylsheet language.  There are already
> lots of existing complex solutions out there that have the power you may
> need for your particular app so why not just use it instead of XSL.  For
> XSL to be successful, it needs to be broadly adopted.  Adding in complex
> hooks that everyone must support is not the way to go.  If you want to
> layer your own scripting solution on top of XSL or else build your own
> proprietary version of XSL to do your own server-processing needs, then I
> see nothing wrong with that.


  I think you have it backwards. There is no need to learn entire
"new" scripting languages. If anything, XSL is the difficult-to-learn
new language. Both JavaScript and VBScript are *standards* JavaScript
is an ECMAScript standard, supported by both browser vendors (90%+ of
the Web market), and VBScript is a defacto market standard that has
probably more programmers than Java or HTML.

  The most successful technologies leverage *existing* practices and
standards. Why can't web developers leverage their knowledge of JavaScript?

  Imagine this: Both Netscape and Microsoft's 5.0 browsers support
HTML4.0, XML, DOM, and CSS, and JavaScript can be used as the bridge
to glue or script any of those technologies together into even more
powerful solutions.

  If the browser vendors include XSL, but without scripting hooks, it
will be an abberation. Rather than being able to glue XSL together
with other technologies, it will stand alone. It may as well not even
be integrated in the browser, as it could easily be a separate plugin
like a PDF or Shockwave viewer.  But even PDF and Shockwave support
scripting hooks through the browser object model.

 I have not heard a convincing argument yet against scripting except for
the authoring/editing issue (needing to reevaluate everything)

Platform availability? There are 2 *free* LGPL C language ECMAScript engines available
with source, 1 free version written Java, 1 commercial version from Netscape,
and the one available from Microsoft. That can't be an excuse.

Ease of integration? Another bad excuse. I am by no means an expert, but
I integrate scripting into all my apps, and it usually takes less than 100
lines of code for complete integration.

Ease of use? The way I see it, more people know how to use JavaScript and VBScript
than either XML, SGML, or XSL. VBScript/JavaScript are far more understandable and
accessable, and there is more literature available for learning, and more
samples.

Furthermore, JavaScript is the defacto internet scripting language. It is expected
by any rational person, to be *the* cross-browser language for manipulating
documents and data, via DOM. I don't think the client-side XSL vendors are
going to object, given the already existing imperative to implement JavaScript.

Anyway, I have always disliked Microsoft's "embrace and extend" in standards,
but in this area, they are absolutely right, and if XSL ever takes off,
I'm sure it will include MS's scripting hooks, by shear developer demand,
and their market share.










 








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


Current Thread