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