Re: Implementing Conditional Text

The OP's terms "publications XML", "source documents" and "author" convey
(to me) the image of an authoring system like docbook, where all of
the output is already in the input. So, there isn't an "output format"
where alternatives would be placed.

-W



On 13/06/2012, Graydon <graydon@xxxxxxxxx> wrote:
> On Wed, Jun 13, 2012 at 08:10:15AM +0100, Michael Kay scripsit:
>> On 12/06/2012 23:16, Graydon wrote:
>> >On Tue, Jun 12, 2012 at 08:39:28PM +0000, Craig Sampson scripsit:
>> >As a general rule, conditional text such as you are describing is
>> >a property of an output format, rather than a property of the
>> >content.
>> That might be your experience, but I think it's an
>> over-generalization. For example, you might well use conditional
>> text to generate insurance policies, where the variation reflects
>> what options the customer has purchased, where they are located, and
>> so on.
>
> It could well be an over-generalization.  It might also be lack of
> clarity in the response!
>
> I took Craig's requirement to be for output where there are a places in
> the text where the output should say "lamb" or "pony" or both.  _In the
> specific case of "word or other word" patterns_ I do find conditionals
> work best encapsulated in the output; the content might well have
> something like:
>
> <conditional name="lamb-or-pony"/>
>
> in it, because getting all the possible variations into the XML content
> is unpleasant and once you have to translate the content you're almost
> certainly going to run into different rules for prepositions, plurals,
> or word order somewhere that tip at least some of the conditionals from
> unpleasant to ghastly.  (Trademark terms can work like this, too; these
> have a nasty habit of changing, and you may well want to be looking up
> the current precise text and text formatting at output time, rather than
> trying to make sure every instance in the content is precisely correct.)
>
> There are certainly other patterns -- like the audience-specific outputs
> I mentioned, or the per-customer-customization example you give above --
> where you'd represent the conditional text in the XML content.  Though
> even there I think it's a very good idea to get all the complexity in
> once place; it's when half the rules for something are in the XML and
> the other half are in the XSLT-or-other output processing that the
> result gets unreliable.
>
>
> --
> Graydon Saunders        XML tools and processes for information delivery.
> graydon@xxxxxxxxx