[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-tc] "Kahlúa" comments
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). -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://www.kosek.cz ------------------------------------------------------------------ Profesionální školení a poradenství v oblasti technologií XML. Podívejte se na náš nově spuštěný web http://DocBook.cz Podrobný přehled školení http://xmlguru.cz/skoleni/ ------------------------------------------------------------------
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]