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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

[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 

   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]