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:
| 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]