[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Implementing Conditional Text

Subject: Re: [xsl] Implementing Conditional Text
From: Graydon <graydon@xxxxxxxxx>
Date: Wed, 13 Jun 2012 07:29:09 -0400

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.

Current Thread