RE: [dita] Inverse conditionals: was: RE: [dita] New DITA Issues

["Paul Prescod" <paul.prescod@blastradius.com>]

> 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.

I'm not sure what "full boolean conditionals" is (in this context) but it sounds like perhaps it is more advanced than just inverses. One can imagine "productA AND productB UNLESS ConditionC". I'm not asking for that.

> - in the case you cite, it is equally likely that the new product 
> falls into exception category. 

Remember that in the situation I am describing, there is a standard configuration and there are customer-specific variants. By definition, the standard configuration is what you get until you ask for a variance for some reason. Sometimes you do know what is most likely or at least safest. That's the theory behind defaulted attributes in XML, defaulted parameters in Java, defaulted templates in XSLT etc.

> "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. 

There are not really positive and negative values. There are requests to exclude elements. As a standard body, we cannot know whether the decision to INCLUDE or EXCLUDE is more conservative in a particular case. For example:

<p audience="AllExceptMichael">We're having a surprise party for Michael. Keep it a secret!</p>

In this case, the inclusion of new party members is the more rational choice because we know that as long as the person is not Michael, this paragraph will apply to the person. It might defeat the purpose of the publication if a new member didn't get the message.

Of course this example is silly for all sorts of reasons but the point is that that context is key.

> 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.

Even in your case, it is probably safer to WARN by default than to leave out the warning by default. I don't know what you mean by "rendered invalid by product changes". There is no validity: either the warning is printed or it isn't. You and I sitting on this mailing list don't know whether it was supposed to be printed or not. We don't know whether the positive or inverted formulation was safer.

- 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. 

I think you might still be arguing against something I am not proposing. Keep in mind that I am not asking for Boolean conditions. I'm asking for the option of inverted conditions.

> - 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. 

We must have different ideas about what is easy to understand and manage! We discourage our customers from making such complex uses of conrefs because keeping the change impacts in your head can be quite difficult. As an authoring vendor, I am also concerned that this mechanism discards all of the advantages of our conditional processing user interface. Comparatively, we can manage inverted conditions easily.

> 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. 

I would expect that the topic oriented model makes topics reusable in many more contexts and therefore more prone to conditionalization at the word or phrase level.

Anyhow, the heart of the use-case is that there is a standard text and there are variants. The standard text is by-definition good enough until a change is asked for. DITA increases my risk of delivering wrong content because what will happen if I don't go back and re-conditionalize everything is that the use will simply lose text:

<p customer="1">Variant 1</p>
<p customer="2">Variant 2</p>
<p>customer="3 4 5 6 7">Standard variant</p>

Customer 8 will get nothing. They will simply lose a concept.

Furthermore, my inverse conditionals make the system LESS brittle in three ways:

<p customer="1">Variant 1</p>
<p customer="2">Variant 2</p>
<p>customer="AllExcept1 AllExcept2">Standard variant</p>

Reason 1: If I search my document for every occurrence of "AllExcept1", "AllExcept2", etc., then I know everywhere that my new customer was included implicitly. I can then review those and decide that it was done correctly. But in the standard model I have to investigate every conditionalized phrase which is just not likely to happen.

Reason 2: I can think ahead to the introduction of new customers and apply my inverse conditionals thoughtfully.

Reason 3: I can do something like this:

<p customer="1">Variant 1</p>
<p customer="2">Variant 2</p>
<p>customer="AllExcept1 AllExcept2"><b outputclass="warning">[WARNING! NEED TO CONDITIONALIZE FOR NEW CUSTOMER!]</b></p>

How do I do that in the standard model?

 Paul Prescod