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

Hi Bob,

Oops I missed this one because I'm bad at email.

The endterm thing is an interesting trick that I didn't know was
built-in. I'll add it to the list of things I propose. Even if we don't
use it here, I'm tempted to add support for it.

Since I'm already doing lots of preprocessing, have them do something
like the following:

<para xml:id="repeat1" arch="yankee" revision="a0">This is text I don't
want to repeat</para>
<para arch="hotel;foxtrot" revision="b0"><xref linkend="repeat1"
xrefstyle="clone"/></para>

Which I preprocess to:

<para xml:id="repeat1" arch="yankee" revision="a0">This is text I don't
want to repeat</para>
<para arch="hotel;foxtrot" revision="b0">This is text I don't want to
repeat</para>

It has the advantage of being very easy for the author to understand. If
they're doing this to chapters and sections, it might make things look
odd in their source. For table <entry>s, it could be awkward/impossible,
but they're already in that situation today.

Thanks,

David

On 7/16/21 12:25 PM, Bob Stayton wrote:
>
> Hi David,
>
> I solved a similar problem of avoiding repeated text by using xref
> with @endterm.  Not sure if this approach would work for you, but in
> your case, it might look something like this:
>
> <section>
>   <info>
>     <bibliomisc xml:id="repeat1">I don't want to type this twice, and
> I don't have to.</bibliomisc>
>   </info>
> ...
> <para arch="yankee" revision="a0"><xref linkend="repeat1"
> endterm="repeat1" xrefstyle="nolink"/></para>
> <para arch="hotel;foxtrot" revision="b0"><xref linkend="repeat1"
> endterm="repeat1" xrefstyle="nolink"/></para>
>
> You would hide the repeatable content in the section info's bibliomisc
> element with an xml:id.  Then you refer to that as needed with
> profiled para elements.
>
> An xref with endterm processes the content of the element pointed to,
> not the element itself, to form the link text.  That would put the
> text contained in the bibliomisc in the para without the bibliomisc. 
> You would need to customize your stylesheet so that an xref with
> xrefstyle="nolink" does not generate the actual link, but just
> generates the link text.
>
> This approach does not require a preprocessing step, or complex
> xpaths, just a customized stylesheet and some user training about how
> to use this mechanism. 
>
> The biggest disadvantage is that it separates the text from the
> location where it is used, which might not work for you.  You could
> instead put it in a <para xml:id="repeat1" role="hidden"> next to
> where it is used.  Another stylesheet customization would not output
> role="hidden", but the xref process would still find it to generate
> the text.
>
> <para xml:id="repeat1" role="hidden">This is text I don't want to
> repeat</para>
> <para arch="yankee" revision="a0"><xref linkend="repeat1"
> endterm="repeat1" xrefstyle="nolink"/></para>
> <para arch="hotel;foxtrot" revision="b0"><xref linkend="repeat1"
> endterm="repeat1" xrefstyle="nolink"/></para>
>
> Bob Stayton
>
>
> On 7/16/2021 5:53 AM, Norm Tovey-Walsh wrote:
>
>> 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