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: Fri, 29 Jul 2005 16:15:33 -0400
I suspect we changed from nmtokens to
cdata for otherprops initially, to support its potentially more complex
syntax (as described in the spec). It would also be necessary to support
the complex syntax of the generalized form of a specialized metadata attribute,
as described in issue #20.
Michael Priestley
mpriestl@ca.ibm.com
"Paul Prescod"
<paul.prescod@blastradius.com>
07/29/2005 03:41 AM
|
To
| Michael Priestley/Toronto/IBM@IBMCA
|
cc
| <dita@lists.oasis-open.org>
|
Subject
| RE: [dita] Inverse conditionals:
was: RE: [dita] New DITA Issues |
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]