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:
| I finally found time to look little bit more into your RELAX NG
| schemas for DocBook NG. Firstly I must thank you, it is really
| admirable amount of work.

Thanks.

| My study of grammar raised several questions and comments. I hope that
| they are not sounding as if I had write them after too much Kahlúas.

:-)

| All comments are about declarations found in pool.rnc.
|
| 1. Why these attributes are interleaved when attributes are unordered?
|
| db.href.attribute =
|     attribute xlink:href { text }
|   & [ dtd:defaultValue="simple" ] attribute xlink:type { "simple" }?
|   & attribute xlink:role { xsd:anyURI }?
|   & attribute xlink:arcrole { xsd:anyURI }?
|   & attribute xlink:title { text }?
|   & attribute xlink:show { "new" | "replace" | "embed" | "other" }?
|   & attribute xlink:actuate { "onLoad" | "onRequest" | "other" | "none" }?

Uhm. Interleaving sometimes seems like the natural thing to do with
attributes since they are unordered but must occur at most once.

| 2. Why fileref is not xsd:anyURI?

Oversight, I suppose.

| db.common.data.attributes =
|    attribute format { text }?,
|    (attribute fileref { text } | attribute entityref { xsd:ENTITY })
|
| 3. What about defining some restrictions for
|     width/height/contentwidth/contentheight attributes using regular
|     expressions? Currently they are defined as text.

What restrictions did you have in mind?

| 4. Create named patterns for
|       "center" | "char" | "justify" | "left" | "right"	
|     and
|       "bottom" | "middle" | "top"
|     or for whole align and valign attributes. There are used more then once.

Yeah, that's probably a good idea.

| 5. Declare named patterns for all attributes. E.g.
|
|     Currently we have:
|
|     db.classsynopsis.attlist =
|        db.classsynopsis.role.attribute?
|      & db.common.attributes
|      & db.common.linking.attributes
|      & db.language.attribute
|      & attribute class { "class" | "interface" }?
|
|     But when someone needs to add new permitted value into list he
| must redefine whole
|     db.classsynopsis.attlist. I think that following way will be more
| flexible:
|
|     db.classsynopsis.attribute.class = attribute class { "class" |
| "interface" }

Yes, that's probably worth doing.

|     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.

|     Changes like these will make grammar quite bit longer, so it is
|     question whether such changes are worth. But I think that they will
|     make customization even more easier.
|
| 6. application.class.attribute should be db.application.class.attribute

Good catch.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Thanks to words, we have been able
http://www.oasis-open.org/docbook/ | to rise above the brutes; and
Chair, DocBook Technical Committee | thanks to words, we have often
                                   | sunk to the level of the
                                   | demons.--Aldous Huxley

PGP signature