Re: [docbook-tc] =?utf-8?q?=22Kahl=C3=BAa=22?= comments

[Norman Walsh <ndw@nwalsh.com>]

/ Jirka Kosek <jirka@kosek.cz> was heard to say:
| Norman Walsh wrote:
|
|> |     Or we can go even further and declare named pattern for value of
|> | attribute:
|> |
|> |      db.classsynopsis.attribute.class.value =  "class" | "interface"
|> |      db.classsynopsis.attribute.class = attribute class {
|> | db.classsynopsis.attribute.class.value }
|> |
|> |     DocBook extension will then be even more easier
|> |
|> |      include "docbook.rnc"
|> |      {
|> |        db.classsynopsis.attribute.class.value |= "abstractclass"
|> |      }
|> Uhm. Yeah. I don't know if it makes sense to go that far or not.
|
| There are several uses cases from history. Attributes that are defined
| by enumerations are time to time extended to allow new values. At the
| same time customizations of DocBook often also add new permitted
| values. If we will use design approach that I proposed, the
| customization can be used without any changes also with newer version
| of DocBook schema as it only adds new values. It doesn't contain whole
| list of permitted values which can evolve with each released version
| of DocBook and can easily go out-of-sync in customization.
|
| I think that this design approach is worth using at least for
| attributes that are defined as enumerations (usually class attribute
| on various elements).

There's no reason not to use it, I suppose. I'm convinced.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Some people will never learn
http://www.oasis-open.org/docbook/ | anything, for this reason, because
Chair, DocBook Technical Committee | they understand everything too
                                   | soon.-- Pope

PGP signature