Re: Fw: Is there a way to define groups of templates ?

Subject: Re: Fw: Is there a way to define groups of templates ?
From: Paul Prescod <papresco@xxxxxxxxxxxxxxxx>
Date: Thu, 24 Sep 1998 14:54:37 -0500
I see the issue now. I would suggest that the simplest way of solving it,
without adding features to XSL is to use macros. Then the chapter w/
general-toc mode could invoke the macro and so also could the  section w/
general-toc mode. Since the macro would not interfere with the mode, it
would allow figures to "do the right thing" for the mode. I think that
this solution is clearer to read than the one your propose.

<xsl:template match="/">
Generate global TOC:
<process-children mode="general-toc">
Generate body:
<proecss-children mode="body">
</xsl:template>

<xsl:template match="section" mode="body">
Generate detailed per-section TOC:
<process-children mode="general-toc">
Generate section body:
<proecss-children mode="body">
</xsl:template>

<xsl:template match="section" context="general-toc">
Generate the entries for the section in the general TOC:
<process-children mode="section-toc">
</xsl:template>

<xsl:template match="chapter/title" mode="general-toc">
<xsl:invoke macro="chapter-title-toc" />
</xsl:template>

<xsl:template match="chapter/title" mode="specific-toc">
<xsl:invoke macro="chapter-title-toc" />
</xsl:template>

<xsl:template match="chapter/figure" mode="specific-toc">
Will appear only in the detailed per-section TOC.
</xsl:template>

On the other hand, I see no particular problem with your solution of
allowing modes to be specified as alternatives. I do not believe it is a
slippery slope. It would just be a notational convenience for doing the
equivalent of the macro trick.

> > I think of a context as
> >just a way of qualifying a template rule. The rule does not need, and
> >probably should not have access to information about the context which
> >gave rise to its calling. It's like a function in a program asking "who
> >called me...and who called them...and who called them?" It strikes me as
> >bad design.
> 
> But if we pursue this line of thought, doesn't it follow that the XSL match
> pattern is too strong? After all, it allows me to match on elements which
> are contained in particular parents which are contained in ... and so on. 

That is asking about occurrence context: the structure of the input
document. It is not asking about runtime call-context, the sequence of
calls that gave rise to the document. The less we depend on runtime
call-context, the better. A single level of string-named modes is the
minimum amount of runtime information sharing that we can get away with
and still solve our problems. So we should implement that. Beyond that we
should be very careful. Note that I've been an advocate of being able to
pass information down the call-stack in the past. More general solutions
to the "passing information down the stack" problem would also solve your
problem:

<xsl:template match="chapter/figure" mode="toc" mode-arg="show-figures">
<xsl:if eval="show-figures">
    Will appear only in the detailed per-section TOC.
</xsl:if>
</xsl:template>

> Of course the context _might_ be unrelated to the structure, and it often
> isn't. A cross reference is a very good example, as would automatic index
> generation. This does not rule out cases where there _is_ a relation. Using
> the extended match pattern method, you can have it both ways. Using the
> simple context pattern method, you can't. Should XSL decide this for us, or
> should it support both approaches?

My point is that your solution only solves the problem for top-down
processes. If I have the exact same problem in a situation that doesn't
involve top-down processing, I am out of luck. That indicates a flaw in
the solution. The macro and "mode alternative" solutions do not have that
flaw. They don't depend on processing progessing in any particular
direction. In my opinion, that puts them more in line with the "tao of
XSL", which is designed to allow processing to progress in any direction.
Your own "mode alternative" idea IS in sync with the "tao of XSL." I'm not
sure why you discarded it.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

How many of the Congresspeople who voted for the CDA do you suppose
also voted to release the report that reads like a borderline por-
nographic dime-store romance written by a Texas preacher's son?
	- Keith Dawson, TBTF 
		http://www.tbtf.com/archive/09-14-98.html
		http://www.tbtf.com/resource/hypocrites.html


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread