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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL with scripting, Tyler Baker | Thread | Re: XSL with scripting, Oren Ben-Kiki |
New deadline for XTech '99 presenta, Jon Bosak | Date | Re: xsl:apply-imports?, James Clark |
Month |