Re: Defining sets of attributes that apply to an element depending on an active profile

Norm Tovey-Walsh <[email protected]> Fri, 16 Jul 2021 13:53:28 +0100
Newsgroups	gmane.text.docbook.misc
Message-ID	<[email protected]>
David Cramer <[email protected]> writes:
> 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. 

That seems like a reasonable approach. I can certainly appreciate that
duplicating the actual content is less than optimal.

> 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>

DocBook 5.2 has a “meta” element that would be more appropriate than
bibliomisc, but otherwise it looks plausible. Two issues come to mind.

First, how often do you need to do this on elements that don’t have an
“info” block? If it’s almost never then maybe you can just duplicate
content for those few cases. If it’s fairly common, then …

Second, it’s a slight abuse of the markup. Semantically, what that
markup says is that those bibliomisc elements should be profiled. I’d be
a little worried about mixing this “preprocess” effectivity markup with
“real” effectivity markup:

     <para>
         <info>
             <bibliomisc arch="yankee" revision="a0"/>
             <bibliomisc arch="hotel;foxtrot" revision="b0"/>
         </info>
         I don't want to type this
         <phrase condition="2">twice</phrase><phrase condition="3">three
         times</phrase>, and I don't have to.
     </para>

You could certainly write preprocessing stylesheets to do the right
thing, but you’re potentially going to confuse authors.

You could address both of these issues with slightly different markup:

     <para>
         <info>
             <bibliomisc role="effectivity">arch="yankee" revision="a0"</bibliomisc>
             <bibliomisc role="effectivity">arch="hotel;foxtrot" revision="b0"</bibliomisc>
         </info>
         I don't want to type this
         <phrase condition="2">twice</phrase><phrase condition="3">three
         times</phrase>, and I don't have to.
     </para>

But that’s kind of ugly and forces you to microparse the content of the
elements. I guess you could use namespaced attributes instead, but I’m
not sure it’s worth the effort.


>     <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>

That looks like a slippery slope to me. I bet you lunch at Kerbey Lane
that authors will start to ask for this in more places and eventually
you’ll have a proposal for:

  xml:id="xpath(if(…) …)"

and you’ll get caught in a bind because the expression isn’t an NCName
so the document won’t even be valid before the transformation. You
probably want to validate after this transformation anyway, but for
authoring purposes, you might want your editor to at least be checking
for valid ID values!

The short answer to your question, by the way, is “no, I’m not aware of
anything like this that’s been done elsewhere.” Managing authoring
complexity looks like a challenge no matter how you approach it.
(I’d be tempted to propose some sort of stand-off markup, but that
really makes the authoring environment harder setup.)

Good luck!

                                        Be seeing you,
                                          norm

--
Norman Tovey-Walsh <[email protected]>
https://nwalsh.com/

> A superstition is a premature explanation that overstays its
> time.--George Iles
signature.asc (application/pgp-signature, 832 B)