[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Implementing Conditional Text

Subject: Re: Implementing Conditional Text
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 13 Jun 2012 16:37:19 -0400
Re:  Implementing Conditional Text
At 2012-06-13 20:20 +0000, Craig Sampson wrote:
Thanks for all the responses. We're taking the advice and implementing this using a span like element for inline text situations and condition attributes on div like elements where we will permit conditional content. We're going to keep processing-instructions for setting the conditions since our users want to be able to define and switch conditions on and off at any point in a document.

While I, like others, have always implemented conditional text by using attributes, I've had the flexibility of changing the DTD or having another DTD with the additional attributes.


From a processing side I think there are inherent challenges working with the nesting of conditional sections and the use of different PIs to start and to stop the condition portions. From an authoring side I think there are inherent risks that the author isn't going to wrap content properly and will break element boundaries.

At 2012-06-12 20:39 +0000, you wrote:
We are not allowing the conditional text to break existing element boundaries or to be nested within other conditions so the following example should represent what we're trying to do:

<topic>
<p>Mary had a little <?condStart normal:true?>lamb<?condStop normal:true?><?condStart special:true?>pony<?condStop special:true?>...</p>

May I suggest a compromise? Treating the processing instruction like an attribute of its parent element, much like I would use an attribute for the same, but doing so without needing to change the DTD. If I were responsible for either authoring or processing, I think I would be more comfortable with:


<topic>
<p>Mary had a little <span><?cond normal:true?>lamb</span>
<span><?cond special:true?>pony</span>...</p>

From the authoring side, the author is dealing with single processing instructions and they can be placed anywhere as an immediate child of the parent element. The scope is perfectly clear-cut and unambiguous: the scope of the parent element.

From the processing side, the stylesheet is simply looking for any child conditional processing instructions for every element. If two are placed in conflict you can decide which one has precedence. But you never have to deal with spans, trying to find the "starting" PI and the "ending" PI.

In this way, the PI is treated simply as attributing the parent element with conditional properties. Just like I would use an attribute, but no changes to the DTD. And, to boot, any conditional processing stylesheets would be vocabulary agnostic: you could create a single conditional processing environment for all of your XML vocabularies.

I hope this is helpful.

. . . . . . . . . . . Ken

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Oct 2012
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.