While we are on the topic of conditionals:
why isn’t the content model of the selection attributes NMTOKENS?
From: Michael
Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Thursday, July 28, 2005 8: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