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:]
Sent: Friday, July 29, 2005 6:35
AM
To:
Subject: RE: [dita] Inverse
conditionals: was: RE: [dita] New DITA Issues
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:
<prop att="product"
val="extendedprod" action="exclude"/>
That is an inverse conditional, as far
as I'm concerned. So for Paul's example, he could use:
<step
audience="Customer1">Only for customer 1</step>
<step
audience="NotCustomer1">Default for most folks</step>
and for most customers DITAVAL would
contain:
<prop att="audience"
val="Customer1" action="exclude"/>
<prop att="audience"
val="NotCustomer1" action="include"/>
For customer 1, the include/exclude
would be inverted. Isn't this an inverse conditional the way Paul is
describing?
Chris
