[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
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]