[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Inverse conditionals: was: RE: [dita] New DITA Issues
I think
authoring tools will have to provide some sort of front end to conditional
processing in any case. Telling authors that they have to edit these attributes
directly probably won't fly, and hand-editing attributes is error-prone anyway.
FrameMaker has a front-end, but it's PI-based. Epic can enforce coherent
conditions using a custom profiling configuration (.pcf), and this will work
with native DITA. I would love to see how XMetal's UI will
look.
Chris
-----Original Message-----
From: Paul Prescod [mailto:paul.prescod@blastradius.com] Sent: Friday, July 29, 2005 11:03 AM To: Chris Wong; dita@lists.oasis-open.org Subject: RE: [dita] Inverse conditionals: was: RE: [dita] New DITA Issues This is exactly what we
are doing. But software other than ours will not enforce rules against
nonsensical combinations like: <step
audience=”Customer1 NotCustomer1”>…</step>
(contradictory) Or <step
audience=”Customer2 NotCustomer1”> … </step>
(redundant) DITA-aware authoring
applications should flag those nonsensical combinations and can only do so if
there is a standardized way of recognizing which conditions are inverses of
other conditions. Furthermore, the
end-user must manage the process of always excluding Customer1 when they include
NotCustomer1 and vice versa. The toolkit should do that
automatically. But anyhow, I agree
with you that the basic mechanism is already there. The only question is whether
to make it standardized and robust. Paul
Prescod From: Chris
Wong [mailto:cwong@idiominc.com] While semantically
DITA's metadata attributes are supposed to express positive conditions, the
processing itself can do inverse conditions. This is from the DITA 1.0
architectural specification as an example of DITAVAL input:
That is an inverse
conditional, as far as I'm concerned. So for Paul's example, he could
use:
and for most
customers DITAVAL would contain:
For customer 1, the
include/exclude would be inverted. Isn't this an inverse conditional the way
Paul is describing? Chris |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]