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