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
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Paul Prescod" <paul.prescod@blastradius.com>
- Date: Thu, 28 Jul 2005 23:58:35 -0400
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]