OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Enlightenment via avoiding the T-word




> However, why couldn't XSL have taken advantage of basic principles of
> programming language design?  The way to handle locality is, again, by
> scoping.  Even if "name" is a global, if I wish to process it differently
> when it shows up in "person" from when it shows up inside "product", plus
> have a rule for default processing, one might write the code shown below
> (if XSL allowed it):
>
> <xsl:template match="x:person">
> ...information generated specific to "x:person" and not visible outside
> the template...
>   <xsl:apply-templates>
>      <xsl:template match="x:name">
>         ...name processing specific to person,
>            could recursively call generic name template
>            can access local information created by surrounding template
>         ...
>      </xsl:template>
>   </xsl:apply-templates>
> ...
> </xsl:template>

This exact syntax was proposed during the development of XSL and the XSL WG 
spent quite a lot of time considering it. Indeed, I believe it was even 
implemented in early versions of MSXSL.  In the end it was rejected.  As 
far as I remember, the reasons were

1. Experience with actual users indicated that they found modes much easier 
to work with than nested templates.

2. It was felt that it was easier to create a GUI for the flat style than 
the nested style.

3. With the flat style, you can use xsl:import and selectively override 
things.

> I've
> built this kind of transformation engine more than once, and find it much
> easier to use than XSL's all-global templates.

I suspect you have a somewhat different background to the average XSLT user.

James