[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] DocBook 5: Removing XLinks for Block Elements?
Hi, On Mon, 9 Feb 2015 17:36:28 +0100 Thomas Schraitle <firstname.lastname@example.org> wrote: > I fear I have to redefine all(?) patterns for block elements. > [...] It seems to me, there is no other way than redefining ALL(!) db.ELEMENT.attrlist patterns and remove db.common.linking.attributes from it. This leads to more than 250 lines(!) only to remove linking capabilities from block elements! Wow! If you don't want XLinks in division and navigational elements as well, add another 130 lines(!) to this number. Well, these are lots of lines, just to make this distinction. The customization is not difficult, it's just the amount of lines that strikes me as odd. This is unnecessarily user unfriendly. Another reason why I'm skeptical about my solution: it's a lot of repetition plus I loose any improvements when I upgrade from 5.1 to 5.2. More code means more areas of problems. ;) > We could define a db.common.block.attributes and a > db.common.inline.attributes pattern to make customization easier. > Bascially it is the same, but it would allow developers to customize > just inline or block elements in one fell swoop. I guess, there are > other use cases not only for XLink attributes. :) I would *really* appreciate any user friendly pattern which I can customize to make this change. IMHO this is an issue in the current RNG version. Adding the distinction between block and inline elements in the DocBook schema doesn't change its semantic. It's just a structural correction to make customization easier. This is what we are all about, right? ;) What's the opinion of the DocBook experts? Norm? Bob? Others? :) Thanks! -- Gruß/Regards, Thomas Schraitle