[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: [xsl] Enabling extension to counting of instances
Subject: Re: [xsl] Enabling extension to counting of instances From: Eliot Kimber <ekimber@xxxxxxxxxxxx> Date: Fri, 08 Jan 2010 15:57:59 -0600 |
On 1/8/10 3:21 PM, "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Enabling extension to cou, G. Ken Holman | Thread | [xsl] Trying to select sibling node, Ylvisaker, Steve |
Re: [xsl] Enabling extension to cou, G. Ken Holman | Date | Re: [xsl] Enabling extension to cou, Dimitre Novatchev |
Month |
Keywords