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:]
Sent: Thursday, July 28, 2005 11:59
PM
To: Paul Prescod
Cc:
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
"Paul Prescod"
<>
07/28/2005 09:13 PM
To
Michael
Priestley/Toronto/IBM@IBMCA
cc
<>
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:]
Sent: Wednesday, July 27, 2005 2:57
PM
To: Paul Prescod
Cc:
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
"Paul Prescod"
<>
07/27/2005 03:25 PM
To
<>
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
