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

Re: [xsl] Implementing Conditional Text

Subject: Re: [xsl] Implementing Conditional Text
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 12 Jun 2012 18:17:41 -0400


On 6/12/2012 5:00 PM, Michael Kay wrote:
A drawback of using PIs is that it will be very hard to enforce any
rules about them, because most schema technologies simply ignore them.
Even your rule that says the PIs won't cross element boundaries will be
hard to enforce. Also I doubt that XML editors are very helpful in
assisting with creation of PIs.

I agree with this. Enforcing your rules is one thing -- Schematron, for example, could help with this, although the logic would be challenging to design, specify and write -- and then processing them is another. Even building structures out of start and end markers is not trivial. Treating structures like this (PIs, empty elements or whatever) as "tags", pseudo-tags, events or what have you is an approach that has been tried -- quite a lot, even, going back into the 1990s -- and makes for an explosion of complexity in processing. Mixing what amounts to parsing logic into your transformation is cool until your head starts to hurt. And then it keeps hurting.

In many ways, in fact, the XSLT architecture, with its separation of parsing from transformation logic and its institution of "trees are everything", is a response to this, and a good one -- until it runs into that class of problems we call by the general label "overlap". (Essentially this solution is still frequently proposed and attempted for them too. Up to a point, it can even work. But staying safely and comfortably nestled in branches of the tree is so much easier.)

David says:

I'd do

<p>Mary had a little <span type="normal">lamb</type><span type="special">pony</span>...</p>

I might clutter it up even more and have

<p>Mary had a little <choice><span type="normal">lamb</type><span type="special">pony</span></choice>...</p>

This would make it easier to constrain and validate all the different options addressing different workflow requirements.

I'd also be tempted to implement with a pipeline -- even if the logic were simple enough to merge into my transformation for display -- running a "resolve the conditionals" stylesheet before I ran the rendering transformation. This way its logic would be easy to separate. maintain and reuse.

Mike also says that most conditional text tends to be at the paragraph level. In part, I think this is because once they start using it, writers find that keeping the conditionals at the block level is the easiest and most straightforward way for them to manage the explosion of complexity on their side too. Again it's a case of discovering that while the feature set is cool, it can also be costly to manage.

With modern editing tools, we might be able to help with this too. Switch between display stylesheets to control which option(s) are displayed and how.


Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

Current Thread