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