OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: DOCBOOK-APPS: Re: conditionalization of XML

On Fri, Oct 11, 2002 at 04:41:41AM -0400, Eric S. Raymond wrote:
> 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.

  But then you put the burden on someone else. And an underspecified,
underreviewed mechanism is the hell of the maintainer's

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

 Doesn't cover a hell of issues, 2mn read just pops up tons of unspecified
behaviour or serious problems. Heck, even the "condition=" syntax is only
given in the example ....

- well formedness breakage, your description is done at the
  serialization level, it has 0 garantee on the level of XML well-formedness

  <?if condition='html'?>
  <?elif condition='pdf|ps'?>

  What gives ??? A further XML well formedness error ? In that case it's
  better left external. Otherwise you'd have to start to give a description
  in terms of the infoset, or similar like XInclude does.

- malformed preprocessor commands
    <?elif cond='pdf
  unlatched <?else?> or <?fi?>, etc, etc ...

  what is handled, and how ?


Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC