[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK-APPS: Re: conditionalization of XML
Daniel Veillard <veillard@redhat.com>: > 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC