Subject: Re: EcmaScript, gone? From: keshlam@xxxxxxxxxx Date: Wed, 2 Sep 1998 09:59:00 -0400 |
<delurk> Back in the older versions of XSL, the ability to use EcmaScript during XSL execution was in part an "escape path", allowing us to bypass areas where XSL as it stood wasn't sufficiently versitile to clearly express our intent. I used it for things like: Retrieve an attribute value, with a default (passed in as a parameter from the XSL, not obtained from the DTD) returned if the attribute was not specified. Strip leading/trailing spaces off a string, or remove newlines, when going from an HTMLish XML where indentation and formatting weren't significant to one that did care about them. (I think some of this is now built in to XSL, but I'm not sure if all of it is.) Determine whether this was the first occurrance of a particular ID attribute, so display-if could generate boilerplate required once-and-only-once. (I _think_ the new rule language may be able to handle this particular case.) I'm afraid I haven't yet gotten around to trying to rewrite that particular set of style rules in the "new XSL", so I'm not sure whether any of those particular examples are no longer relevant... but they illustrate the point. These are examples of things which have to be done in order to handle conversions between two XML languages that were not originally designed to be a good match to each other. Since they're operations that are performed only in particular contexts of the document, and since one of them is in fact gating an XSL production, it seems reasonable to have them invoked from XSL. My (admittedly limited) understanding of behavior sheets is that they'd be applied too late to accomplish all of this. And for those of us not running in a browser environment, they would require explicitly invoking a "second compilation pass" through the additional tool. XSL may now have better built-in mechanisms for addressing some of this. Or it may be that the places I want to use it fall on the wrong side of the 90/10 rule. But I worry just slightly about closing the door to user-written extensions at a time when people are still figuring out what they want to use XML for and how they want to use it -- vide the discussion here of whether patterns should be represented as XML structure or not. (Which, for what it's worth, I have very little opinion on. It strikes me as a variant of the standard XML dilemma over whether a piece of information should be a "flat" attribute or a structured child tree, and I don't think anyone has a really good stylistic answer for that as yet. The new language does seem to do everything the old one could plus a few more things, but I honestly can't decide if it's more or less readable.) </delurk> ______________________________________ Joe Kesselman / IBM Research Unless stated otherwise, all opinions are solely those of the author. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: EcmaScript, gone?, James Tauber | Thread | Re: EcmaScript, gone?, James Clark |
Re: Just Not Getting It, carlton . e . noles | Date | Re: CSS + behavior vs. XSL (was: E, Paul Prescod |
Month |