Re: Proposal for RFE 2100736: initializer should allow constants

[Norman Walsh <ndw@nwalsh.com>]

Norman Walsh <ndw@nwalsh.com> writes:
> I took an action a while back to make a specific proposal for this RFE.

Today, the TC discussed this proposal.

> I think the most straightforward thing to do is to allow initializer
> to contain the db.markup.inlines:
>
> db.markup.inlines =
>    db.tag
>  | db.markup
>  | db.token
>  | db.symbol
>  | db.literal
>  | db.code
>  | db.constant
>  | db.email
>  | db.uri
>
> So you'll be able to say things like
>
>   <initializer><constant>NULL</constant></initializer>
>
> if you want. Some of the markup inlines seem entirely reasonable for
> initializers: token, symbol, literal, code, constant, and uri. Others,
> less so: tag, markup, email 
>
> We could arrange to forbid tag, markup, and email, but I'm not sure
> it's worth the effort. I think a plausible, if unlikely, case could be
> made for allowing email and perhaps even tag as initializers. And if
> you do that, on what grounds would you forbid markup?
>
> So that's my proposal: allow db.markup.inlines in initializer.

The TC was convinced that it should also allow mathphrase, so here's
my concrete proposal:

   db.initializer =
      element initializer {
         db.initializer.attlist,
         (db._text | db.markup.inlines | db.mathphrase)*
      }

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | The formula 'Two and two make
http://www.oasis-open.org/docbook/ | five' is not without its
Chair, DocBook Technical Committee | attractions.-- Dostoevsky

PGP signature