so

Dynamic profiles

Volume 4, Issue 35; 08 Jul 2020

Composing documents based on run time parameter values.

The DocBook stylesheets have long supported the notion of profiling. Profiling allows you to write things like this:

<para>In this fictitous paragraph about profiling
we imagine that we’re talking about command line
options. Options are introduced with the
<phrase os="windows">/</phrase>
<phrase os="mac;linux">-</phrase> character.</para>

Then, when you publish the document, if you select os=windows, the result will be as if this was your document:

<para>In this fictitous paragraph about profiling
we imagine that we’re talking about command line
options. Options are introduced with the
<phrase os="windows">/</phrase>
 character.</para>

Conversely, if you select os=linux when you publish the document, the result will be as if this was your document:

<para>In this fictitous paragraph about profiling
we imagine that we’re talking about command line
options. Options are introduced with the

<phrase os="mac;linux">-</phrase> character.</para>

It is not a complete or comprehensive solution to the problem of producing multiple variants of a document, but it is inexpensive and entirely serviceable for small-to-medium amounts of text.

Following on the observations I made about xsl:evaluate the other day, it occurred to me that I might want to profile based on dynamic properties of the stylesheet. Perhaps I want to publish some annotations only if the JavaScript annotation support is enabled, or perhaps I want to publish some text only if XLink extended link support is enabled.

Enter “dynamic profiles”:

<para><phrase condition="$flag">This will only appear
if the <parameter>$flag</parameter> is true.</phrase>

<phrase condition="$annotations=javascript">This will
only appear if annotations are published with JavaScript.
</phrase>

<phrase os="win;$flag">This will only appear if the
document is published for Windows and the
<parameter>$flag</parameter> is true.</phrase>
</para>

In the interest of performance, security, and legibility, I’m not proposing to support arbitrary expressions.If you really need to have a dynamic profile based on some arbitrary condition, you can do it by making a customization layer that stores that computation in a variable and then testing that variable in your dynamic profile. You can use a variable name by itself, $flag, which tests if that variable “is true”, or you can use a simple comparison, $var=value which tests if (the string value of ) $var has the value value. (If $var is a list, it’s an existential test.) You also don’t get boolean operators or any other fancy magic.

An element with dynamic profiling will be published if none of it’s profile expressions evaluate to false. This is slightly different from the ordinary (static?) profiling semantic which publishes the element if any of it’s values match. I think that’s the right thing.

Oh, and there are switches to control whether or not this happens at all (by default, it does not) and, if it does, what profiling attributes it applies to.

Please provide your name and email address. Your email address will not be displayed and I won’t spam you, I promise. Your name and a link to your web address, if you provide one, will be displayed.

Your name:

Your email:

Homepage:

Do you comprehend the words on this page? (Please demonstrate that you aren't a mindless, screen-scraping robot.)

What is eight plus seven?  (e.g. six plus two is 8)

Enter your comment in the box below. You may style your comment with the CommonMark flavor of Markdown.

All comments are moderated. I don’t promise to preserve all of your formatting and I reserve the right to remove comments for any reason.