Question: Before I cook something up myself, I'm wondering if someone
has already solved the problem described below. For example, is there a
Balisage paper I should read.
Our authors use profiling based on the arch together with other
attributes to add metadata that is reflected in the output via
formatting (background and text colors, etc). For example, the author
might have the following:
<para arch="yankee" revision="a0">Some content that only appears in the
yankee profile and has special formatting to indicate that it is related
to the 'a0' revision.</para>
So far, so good. However, sometimes this forces them to repeat content
to get the desired result:
<para arch="yankee" revision="a0">
<!-- appears in yankee profile, formatted for a0 revision -->
I don't want to type this twice, but sadly I must.
</para>
<para arch="hotel;foxtrot" revision="b0">
<!-- appears in foxtrot and hotel profiles, formatted for b0
revision -->
I don't want to type this twice, but sadly I must.
</para>
The feature request is for a way to get the formatting result they want
without repeating content. The idea I'm exploring is to give them richer
metadata and then to pre-process the content based on that metadata
before profiling. One consideration is that the solution be flexible
enough to handle future requests along the same lines. Today, it's arch
+ revision, tomorrow other users will want to bind other combinations of
attributes.
Here's a verbose, but clear approach:
<para>
<info>
<bibliomisc arch="yankee" revision="a0"/>
<bibliomisc arch="hotel;foxtrot" revision="b0"/>
</info>
I don't want to type this twice, and I don't have to.
</para>
In our build pipeline, a preprocessing xslt could replace that paragraph
with two versions in an intermediary format. The existing profiling and
formatting code takes care of the rest:
<para arch="yankee" revision="a0">
I don't want to type this twice, and I don't have to.
</para>
<para arch="hotel;foxtrot" revision="b0">
I don't want to type this twice, and I don't have to.
</para>
Alternatively (and less verbosely), I could let them write xpath and
evaluate it. For example, let's say the pre-processing xslt tokenizes
the value of @arch, creating a copy of the para for each one, then
evaluates the xpath in the revision against it. This is certainly more
concise, but not so intuitive even if you know xpath since you have to
know how it will be evaluated:
<para arch="yankee;hotel;foxtrot"
revision="xpath(if( @arch = ('foxtrot','hotel') ) then 'b0'
else 'a0')">
I don't want to type this twice, and I don't have to.
</para>
This would produce the following intermediary content:
<para arch="yankee" revision="a0">
I don't want to type this twice, and I don't have to.
</para>
<para arch="hotel" revision="b0">
I don't want to type this twice, and I don't have to.
</para>
<para arch="foxtrot" revision="b0">
I don't want to type this twice, and I don't have to.
</para>
Regards,
David
