🚀 go-pugleaf

Thanks everyone for the ideas. My original question was prompted by our nagging concern that we were perhaps extraordinarily dumb.

I'm beginning to perceive conditional text as a small ex post facto adjustment that one can add to an otherwise complete and sound content structure. That is to say that conditional text doesn't seem to me to be a suitable *foundation* for a document implementation strategy.

Consider the following example: Product "A" shares some, but not all, functions with products "B" and "C"; products "B" and "C" too have their similarities and differences. Can one sit down and build a truth table for all the necessary conditions? Yes.

Having done so, *and as long as every member of the team works extremely carefully*, the group and its documents will be okay until a new feature or a new product comes along. When that happens a new condition, and a new condition table, will have to be carefully built and reviewed. I don't perceive this method of working as very productive especially if one needs to incorporate a new writer into the cabal.

What we've been able to make work is more-or-less parallel container documents that import as much modularized text-inset content as possible; product-specific content goes directly into the appropriate container document. In this model, new products get a new container document; new writers are generally less confused by the structure and the team doesn't have to be quite as careful as they would walking through a conditional text minefield.

In summary, (and if you'll forgive the strained analogy) we may be able to spice a container document meal with a small amount of conditional text, but we shouldn't use conditional text as a central ingredient.

Or so it seems...

Cheers, thanks 'gain to everyone, and Happy Holidays,
Riley