OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]