Re: [xsl] Re: how can I make non-tunnelling parameters tunnel through <xsl:next-match/>?

Subject: Re: [xsl] Re: how can I make non-tunnelling parameters tunnel through <xsl:next-match/>?
From: "Imsieke, Gerrit, le-tex gerrit.imsieke@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 2 Jul 2022 05:48:40 -0000
Hi Chris,

Your workaround seems good, given the constraints of the imported templates.

As you suggested in your initial question, things would be easier if the original stylesheet authors used tunnel parameters.

If they want to improve extensibility of their stylesheets even more, they may consider computing $type and $title by transforming the context element in dedicated modes, let's call them mode="B-type" and mode="B-title". As I understood your initial post, calculating the title involves some complicated lookups that you understandably didn't want to replicate. If they outsourced this heavy lifting to a different mode, you could apply fine-grained modifications to these computations without the need to create context-dependent variants to your generic mode="B" postprocessing template.

Fine-grained adjustments are also possible in the next-match-to-variable approach that you settled for in your most recent post -- if you are able to identify the original values of $type and $title that the default mode="B" template created in the preliminary result tree, which can be difficult.

Also for memory consumption and speed of execution reasons it is preferable to do everything in a single pass -- if it is possible with minimal replication of the original code and without the need to know the innards of the next-matching templates.

On balance, I usually prefer maintainability over performance though. With respect to maintainability, you need to be aware that while next-match-to-variable-and-postprocess does liberate you from the need to know the inner workings of the imported templates, it is not necessarily invariant under modification of the underlying templates. If the output structure, generated classes, etc. change after an update to the underlying framework, your customization might need to be modified, too.

As regards the black-box, no-knowledge approach to customizing the underlying framework, one could argue that if you need to know to transform note elements in mode="B-type" and mode="B-title" in order to compute the type and the title values, respectively, you already need to know too much of the innards of mode="B". On the contrary I'd argue that mode="B-type" and mode="B-title" are part of the "extensibility API" that the initial stylesheets explicitly expose as extension hooks that permit fine-grained overrides with minimal repetition.

With these dedicated modes, in particular with modes that generate class attribute tokens, it is still often advisable to store preliminary next-match results in a variable and then to modify these results. But this often does not require fully-fledged postprocessing of whole subtrees. Often only sequences of tokens need to be filtered or augmented. See my 2020 Balisage paper [1] for examples.

Let me conclude by stating this golden rule for parameters in matching templates:

Always use tunnel parameters in matching templates. People who want to customize your stylesheets will be grateful.

You can suggest this to the DITA-OT XSLT maintainers, or refactor their code and file a pull request.

Gerrit

[1] https://www.balisage.net/Proceedings/vol25/html/Imsieke01/BalisageVol25-Imsieke01.html#sec-fix-class-att




On 02.07.2022 01:04, Chris Papademetrious christopher.papademetrious@xxxxxxxxxxxx wrote:
Hi everyone,

In looking for a workaround, I found a better solution!

Before I knew about <xsl:next-match> and the preprocessing approach, I used to copy the DITA-OTbs templates and modify them. With that approach, I tried to identify the lowest-level template to copy and modify. In my previous post, bAb and bBb were part of that lower-level DITA-OT machinery.

But with an <xsl:next-match> post-processing approach, I realized that I can wedge into processing at a higher level and let the shallow-copy moded templates match deeper inside the content where needed. In this case, itbs nice and clean to match at <note> element itself:

<xsl:template match="*[contains-token(@class, 'topic/note')]">

B <xsl:variable name="results">

B B B <xsl:next-match/>

B </xsl:variable>

B <xsl:apply-templates select="$results" mode="my-note-postprocessing"/>

</xsl:template>

<xsl:mode name="my-note-postprocessing" on-no-match="shallow-copy"/>

<xsl:template match="..." mode="my-note-postprocessing">

B ...

</xsl:template>

Ibm still curious if there is an answer to my original question, but I no longer need the answer for my final implementation.

-----
Chris Papademetrious

Tech Writer, Implementation Group

(610) 628-9718 home office

(570) 460-6078 cell

XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/225679> (by email <>)

-- Gerrit Imsieke GeschC$ftsfC<hrer / Managing Director le-tex publishing services GmbH Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 gerrit.imsieke@xxxxxxxxx, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

GeschC$ftsfC<hrer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt

Current Thread