On 12/06/2012 21:39, Craig Sampson wrote:
We plan to use processing-instructions (PIs) entered by the authors
that would indicate which conditions were on or off. These PIs would
be inserted near the top of the documents. There would be additional
PIs identifying the beginning and end of conditional text strings.
We would use a XSL transform to preprocess these documents and
convert the PIs into pseudo elements that could then be processed in
a second XSLT preprocessor would keep or discard the strings based
on the conditions set in the PIs at the top of the document. The
resulting document would not have any of the PIs or pseudo elements
just the content that was kept.
We want to use PIs so we don't have to dirty up our DTD with
conditional elements that would be allowed everywhere.
Like Michael Kay, I'd use attributes here.
I can't think of any way to eliminate the conversion to pseudo
elements which solves the problem of identifying and controlling the
I'm not sure what you mean by a pseudo element. If you are using XSLT
for the conversion i assume you mean convert to real elements?
But there doesn't seem to be anything in what you describe that demands
having an intermediate form at all. Why can't your "final" processing
query the PIs (or attributes) directly?
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:
Attribute markup would naturally enforce the restriction to element
<topic> <p>Mary had a little<?condStart normal:true?>lamb<?condStop
<p>Mary had a little <span type="normal">lamb</type><span
In the example if the PIs at the top of the document set "normal" to
"true" and "special" to "false" then Mary had a little lamb. If
both conditions are set to true then Mary will have both the lamb
and the pony.
Can anyone poke holes in this solution or suggest a better way to
google plus: https:/profiles.google.com/d.p.carlisle
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>