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:]
Sent: Friday, July 29, 2005
11:03 AM
To: Chris Wong;
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:]
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
