MHonArc v2.5.0b2 -->
docbook-tc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [docbook-tc] =?utf-8?q?=22Kahl=C3=BAa=22?= comments
/ 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]