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


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
 
-----Original Message-----
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Thursday, July 28, 2005 11:59 PM
To: Paul Prescod
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] Inverse conditionals: was: RE: [dita] New DITA Issues


For what it's worth, we made a deliberate decision early in DITA's design to exclude inverse conditionals, which reversed direction for us at IBM from over two decades of full boolean conditional support. So this is one we can probably chalk up to a difference of opinion rather than immaturity.

Our reasoning was roughly:

- in the case you cite, it is equally likely that the new product falls into exception category. "Not x" is actually very odd metadata - it's based not on knowledge of the thing itself, but knowledge of the entire set of values, and patterns within that set. While positive conditions can be more unwieldy, they are much more robust - ie they are specific to one thing at a time, and hence insulated from changes elsewhere in the same set. For example, if a warning applies to "productA", then it applies until productA itself changes. But if the warning applies to every product "exceptProductA", then it can be rendered invalid by any product changes, or by any new product added to the mix.

- while full boolean conditions enabled individual writers to be more efficient, they caused major problems on shared content, and when content changed ownership; or even when the original author had a bad day. The positive value syntax is more verbose but also much easier to parse and easier for humans to understand.

- finally, DITA's major support for singlesourcing is not via conditional processing at all, but via maps. So in the worst case scenario, if the conditions simply become too painful to manage (perhaps as below) the author can cut losses by creating two versions of the topic, one for common use, and one for use only by the exception product. The two topics can even share common content, via conref, without interfering with each other or using complex conditions. The logic is punted to the map level, and the actual content is insulated from changes to the conditions.

The basic point here is that there is a cost for having complex conditions. Because of DITA's topic-based architecture, reuse above the topic level can be accomplished via maps,  and so the benefit of conditions in general is considerably reduced, while their cost remains the same. This led us to the current model: simple support for positive conditions only.

Michael Priestley
mpriestl@ca.ibm.com



"Paul Prescod" <paul.prescod@blastradius.com>

07/28/2005 09:13 PM

To
Michael Priestley/Toronto/IBM@IBMCA
cc
<dita@lists.oasis-open.org>
Subject
[dita] Inverse conditionals: was: RE: [dita] New DITA Issues

Here is an example of a feature I would like to see: inverse conditionals.

Let's say we make custom variants of our manuals for a dozen different customers. At any time, I may conditionalize a part for a particular customer:

<step audience="Customer1">Step 1</step>

But the other eleven may want the "default" step. So I do this:

<step audience="Customer2 Customer3 Customer4 ...">Step 1</step>

What happens when we add customer 13? Unlucky thirteen! I need to go back through all of my content and find every place where I listed ten or eleven customers when what I "really" meant was "all customers except one or two".

So the workaround we are using is to do something like:

<step audience="ExcludeCustomer1 ExcludeCustomer4">...</step>

The next step is to exclude "ExcludeCustomer1" any time you do not exclude "Customer1". And vice versa. This is obviously error prone and somewhat confusing (double negative).

Also: the exclusion pattern is totally proprietary so authoring systems won't enforce the business rule that audience="ExcludeCustomer1 Customer1"  is non-sensical. Nor will it enforce the more subtle issue that "ExcludeCustomer1 Customer2" is non-sensical because it is redundant and therefore likely suspect

So I think that the DITA spec should have a first-class feature for addressing this issue unless there is some subtlety of the spec that I've missed.

________________________________________
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Wednesday, July 27, 2005 2:57 PM
To: Paul Prescod
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] New DITA Issues


I'd personally like to see them raised. After all, it's at least theoretically possible that some of the issues you see as immaturity are secret strengths we just haven't explained properly :-) I also think it's a good idea, if they are new requirements, to log them as we think of them, so they don't get lost in the shuffle.

Michael Priestley
mpriestl@ca.ibm.com

"Paul Prescod" <paul.prescod@blastradius.com>
07/27/2005 03:25 PM
To
<dita@lists.oasis-open.org>
cc

Subject
[dita] New DITA Issues







As you would expect, the more we use DITA, the more we run into issues we would like to see improved or corrected. It isn't that its design is defective, but it is immature.
 
I'm not clear whether I should:
 
a)       Silently hold on to these for DITA 2.0
b)       Raise them as potential issues for DITA 1.1 (in what manner?)
c)       Discuss them now but defer their resolution until DITA 2.0
 
 Paul Prescod
 



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