Hi,
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.
Cheers,
Wendell
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
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
======================================================================
--~------------------------------------------------------------------
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>
--~--