OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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.
-----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)




<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]
Sent: Friday, July 29, 2005 6:35 AM
To: dita@lists.oasis-open.org
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?



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]