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