Daniel Veillard <[EMAIL PROTECTED]>:
> Now to be relatively specific about <?if?> as much as I can since I
> don't have any clear picture of how the selection is actually done, it seems
> to be in the line of the previously found standard extention abuses
> like #pragma foobar for Winblows C compilers or various custom PI
> that each SGML toolchains seems to have developped to tie in their
> customers in the 90's (I may get some heat for this, I don't care ;-)
You know, there's reason people keep re-inventing mechanisms for this.
It's because they need to get work done -- and getting work done often
means wanting to conditionalize documents without spending days on some
elaborate custom XSLT hack.
> I would really prefer to get DocBook fixed to allow proper conditionalization
> at the *markup* level (if the current solution is not sufficient for
> users' needs like Eric), which then will be close to trivial to handle
> correctly in the existing XSLT tools, independantly of the toolchain used.
Norm? Are you listening? Is this anything that the DocBook development
group is thinking about?
> Now if a number of people did voice in saying that's the kind of processing
> they really need, that there is a clean and public description with
> review of the suggested extension, then I would certainly be an early
> implementor of said feature.
Attribute/value pairs from the command line are matched
against the attributes associated with certain processing
instructions in the document. The instructions are <?if?> and
its inverse <?if not?>, <?elif?> and its inverse <?elif not?>,
<?else?>, and <?fi?>.
Argument/value pairs given on the command line are checked
against the value of corresponding attributes in the
conditional processing instructions. An `attribute match'
happens if an attribute occurs in both the command-line
arguments and the tag, and the values match. An `attribute
mismatch' happens if an attribute occurs in both the
command-line arguments and the tag, but the values do not
match.
Spans between <?if?> or <?elif?> and the next conditional
processing instruction at the same nesting level are passed
through unaltered if there is at least one attribute match and
no attribute mismatch; spans between <?if not?> and <?elif
not?> and the next conditional processing instruction are
passed otherwise. Spans between <?else?> and the next
conditional-processing tag are passed through only if no
previous span at the same level has been passed through.
<?if?> and <?fi?> (and their `not' variants) change the
current nesting level; <?else?> and <?elif?> do not.
All these processing instructions will be removed from the
output produced. Aside from the conditionalization, all other
input is passed through untouched; in particular, entity
references are not resolved.
Value matching is by string equality, except that "|" in an
attribute value is interpreted as an alternation character.
Thus, saying foo='red|blue' on the command line enables
conditions red and blue. Saying color='black|white' in a tag
matches command-line conditions color='black' and
color='white'.
Here is an example:
Always issue this text.
<?if condition='html'?>
Issue this text if 'condition=html' is given on the command line.
<?elif condition='pdf|ps'?>
Issue this text if 'condition=pdf' or 'condition=ps'
is given on the command line.
<?else?>
Otherwise issue this text.
<?fi?>
Always issue this text.
--
<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
