On 1/8/10 3:21 PM, "G. Ken Holman" <gkholman(_at_)CraneSoftwrights(_dot_)com>
wrote:
[...]
In that project I employed a technique I'd used before elsewhere for
a shared library that needed that flexibility. A number of hooks are
built in to the processing of *every* construct, because we had no
idea *which* construct users might want to tweak.
To summarize, consider the following library construct to process
<para> into an <fo:block>:
<xsl:template match="para">
<xsl:apply-templates mode="do-construct" select="."/>
</xsl:template>
<xsl:template match="para" mode="do-construct">
<fo:block xsl:use-attribute-sets="normal-stuff">
<xsl:apply-templates mode="do-attributes" select="."/>
<xsl:apply-templates mode="do-content" select="."/>
</fo:block>
</xsl:template>
<xsl:template match="para" mode="do-attributes">
<xsl:apply-templates select="@*"/>
</xsl:template>
<xsl:template match="para" mode="do-content">
<xsl:apply-templates/>
</xsl:template>
[...]
Back then I was using only XSLT 1.0 ... tunnel parameters in XSLT 2.0
might also be a conduit down which you could pass information that
could be intercepted by a user's onion-skin stylesheet.
Yes, I can see that if we were re-implementing the Toolkit XSLT processors
for scratch that this approach would be appropriate, albeit tedious to
implement the first time. The current Toolkit approach depends mostly on
simple overrides and named templates, which is sufficient for most
processing--for the post part it is a matter of specialized elements
overriding the default processing applied to their base types, rather than
augmenting the base processing.
But so far numbering seems to be the place where augmentation, rather than
overriding is necessary, precisely because, as in your case, the set of
potential extenders and extensions is unbounded and unknowable.
As for tunneling parameters, I would expect to build most or all of the
lists needed (e.g., my list of all chapter topic refs) in the root
processing and then pass them as tunnel parameters to make them available to
whatever processing needs them.
In the specific case of PDF processing, the existing implementation already
creates a temporary tree representing the original map annotated with IDs
and whatnot needed to relate topics to the topicrefs that pointed to them,
so that is there already.
Cheers,
Eliot
--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--