RE: Enlightenment via avoiding the T-word

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

As Tim Bray said near the beginning of this thread, since I didn't
participate in XSL, I can't really complain.  But...

> -----Original Message-----
> From: James Clark [mailto:jjc@jclark.com]
> Sent: Thursday, August 30, 2001 4:06 PM
> To: Fuchs, Matthew; 'Rick Jelliffe'; 'xml-dev@lists.xml.org'
> Subject: 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.  

Ah, but I've always supported both flat and nested.  In other words, there
could also be a global template matching "name", or a global for person/name
instead of the nested version.  It's only an order of evaluation issue, but
the nesting makes it much easier to support common information.  Programmers
generally don't have a problem with this.

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.
> 

I suspect there is often a tradeoff between "locally easy/globally hard" and
"globally easy/locally hard".  Modes probably fit into the former category
and nesting perhaps into the latter.  Modes seem easier to start, but
becomes progressively harder to scale.  Nesting may seem hard, at first, to
people not used to such programming languages, but once you get the hang of
it, its built-in modularity makes things much easier to scale.  And of
course, when I was working with SOX, I included dispatch by type as well.

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

I've would think the opposite is true, actually.

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

I suspect many cases of override become unnecessary in the nested model.

> > 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.
> 

Yeah, probably.  I just don't get the either/or requirement that always
shows up.

Matthew