Subject: Fw: XSLT Draft: Modes vs. Variables From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Wed, 28 Apr 1999 11:18:48 +0200 |
I wrote: >> There's one crucial difference: calling: >> >> <xsl:apply-templates mode="bo-beep" select="..."/> >> >> Has no equivalent using named templates. Note that the following: >> >> <xsl:for-each select="..."> >> <xsl:call-template name="bo-beep"/> >> </xsl:for-each> >> >> Is _not_ the same thing, since there must be only one template name >> 'bo-beep' in the 'for-each' case. James Clark <jjc@xxxxxxxxxx> replied: >Huh? It would be an error if there was more than one template rule >declared as: > ><xsl:template match="node()" mode="bo-peep" >priority="[infinity]">...</xsl:template> Exactly; therefore, given the following input document: <foo> <bar>...</bar> <baz>...</baz> </foo> One can't simply translate: <xsl:template mode="foo" select="bar">...</xsl:template> <xsl:template mode="foo" select="baz">...</xsl:template> <xsl:template match="foo"> <xsl:apply-templates mode="foo" select="*"> </xsl:template> Into: <xsl:template name="foo" select="bar">...</xsl:template> <xsl:template name="foo" select="baz">...</xsl:template> <xsl:template match="foo"> <xsl:for-each select="*"> <xsl:call-template name="foo"/> </xsl:for-each> </xsl:template> Because there's no way to force the <xsl:call-template> to invoke the appropriate template according to the selected element type. Therefore _as things stand today_, the 'mode' attribute/mechanism is necessary. >The WG considered lots of different alternatives (including not having ><xsl:call-template> and <xsl:template name="..."> at all, having a >select attribute on xsl:call-template, combining xsl:apply-templates and >xsl:call-template) before settling on the current design. The current model is definitely consistent and sufficient, it is just that IMVHO it could be made simpler (more elegant?) without effecting the feature set. No offense for the WG - I'm sure they have good reasons for the decisions they made. <SideTrack> As I mentioned before, I'm a sucker for rationale documentation in standards. I'm also aware that standard organizations abhor retional documentation since they are as hard to create as the standard itself. However IMVHO rationale documentation greatly improve the quality of standards. For one thing, explaining why a certain design choice was made often gives better insights on an issue then format definitions (of course the latter is also important). It helps to steer people away from wrong interpretations. Another benefit is that it helps weed out flawed design choices. Take this one for example (I'm not saying it is necessarily flawed!). If the reason for choosing this particular combination is its effect on ease of implementation/simplicity of explaining the resulting language/size of style sheets/efficiency of XSL processors, it settles the issue (since there's a good technical reason). If on the other hand all the considered combinations are more of less technically equivalent and the choice was made according to aesthetic reasons, that would also settle the issue (after all a choice has to be made and there's no point arguing about taste). The interesting case is where the reasoning is flawed - on overlooked combination, or an effect of one of the options, which might have been a deciding factor had it been raised. Without a rationale, reviewing the standard becomes a game of trying to reverse-engineer the reasons for the design choices as a required part of suggesting improvements. A fun game, but a difficult and error prone one, so it tends to reduce the quality and quantity of the improvement suggestions. Of course all this depends on the type of standard process you prefer. For better or for worse, the W3C has chosen a pretty closed type of process. That isn't necessarily bad but it does mean that suggestions in this list and other places always face the danger of simply repeating a discussion long settled within the WG, wasting everyone's time. </SideTrack> Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSLT Draft: Modes vs. Variables, James Clark | Thread | XSL and Web Native distributed comp, Jonathan Borden |
RE: Validating XSL expressions and , Francois_Deza | Date | Re: Formatting Objects considered h, Guy_Murphy |
Month |