Subject: XSLT Draft: Modes vs. Variables From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Mon, 26 Apr 1999 21:00:35 +0200 |
I've just been through the new XSLT draft. The WG has come up with some nifty features (some of which might be related to the feedback from this mailing list ;-), with the result that I like this draft much better then the previous one (which was much better then the one before it). The standards are also reorganizing in the right direction - we now have XSLT as opposed to XSL, and the unification of the patterns with XPointer has begun. If things continue to improve at this pace, the final draft would be all we can hope for. Keep on the good work! Unifying macros and templates is neat. I would like to know, however, what the expected behavior is when a named template has a match pattern. Is the call to the template ignored unless the current node matches the pattern? Is the named template considered together with normal templates when matching for document elements? I infer from the fact this was left unspecified that the issue was not resolved yet. The new <xsl:variable> and <xsl:param-variable> are a life-saver. I was putting off writing some particularly tricky XSL transformations which really needed them; now I can forge ahead without resorting to messy workarounds. They do raise a question, though: does it make sense to replace template modes with a test attribute? I'm aware this is re-opening a discussion from half a year ago, but the situation has changed due to XSLT's variables. Think of it in the following manner: suppose that in the previous draft, variables were introduced in the new XSLT form, and there was no 'mode' attribute for <xsl:template>. People would have been forced to write: <xsl:template match="..."> <xsl:choose> <xsl:when test="{$mode}='...'"> ... </xsl:when> ... </xsl:choose> </xsl:template> Which gets the job done but is pretty inconvenient. It is also limited in that all the possibilities need to be written in one place. In this hypothetical alternate history, would the best solution have been to add a 'mode' attribute or a 'test' attribute to <xsl:template>? My own opinion is that 'test' would have been the right way to go - it is simpler to define its semantics (treat the template as if it had an <xsl:if> around all the code, except for parameter definitions), it is more powerful (tests can be for more then a simple equality) and it is one less concept in a complex system (always a good thing if you can get away with it). Looking back at my XSL sheets there were several occasions where I wanted to write: <xsl:template mode="mode1|mode2" ...> And had to factor our the common code to a macro. Using tests would have allowed me to write: <xsl:template test="{$mode}='mode1' or {$mode}='mode2'" ..> Instead. In the tricky code I have mentioned above, there are some cases where the possible handling of each element depend on more then one variable, in which case using 'test' would allow me to naturally factor a large and complex template. How about it? Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: not resetting counters in a doc, James Clark | Thread | Re: XSLT Draft: Modes vs. Variables, James Clark |
Re: Formatting Objects considered h, Paul Prescod | Date | RE: HTML is a formatting/UI languag, Didier PH Martin |
Month |