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

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook] Allow <info> as root element?


Hi,

On 30.11.22 14:02, Norm Tovey-Walsh wrote:

That true, this would be possible. However, that wouldn't be DocBook anymore.
Additionally, you increase your maintenance efforts if you have to create a
DocBook variant just for customize the start elements.

Okay, but conversely, the position that the markup for every possible
documentation scenario must be in standard DocBook doesnât scale. It
means DocBook just gets larger and looser until out of the box it has
very few constraints.

Yes, it's always a balancing act between restricting the schema and to make it
flexible enough.

I don't suggest nor endorse adding all and everything as start element.
However, maybe in the light of topic-oriented writing there might be elements
which could be useful to add like <info>.

I can fully understand that you don't want to change this. As another
alternative would be to offer two variants: the normal, DocBook schema and a
schema suited more for assembly and topic-oriented writing.

This is not that unusual. We already have "official" DocBook variants: dbits,
Publishers, Simplified, ... It would be just another customization more suited
for topic-oriented writing. The "DocBook Topic schema" could follow a more
relaxed approach for start elements. That would keep the normal DocBook schema
intact, but would offer another alternative.

Would that be a solution?


For most non-trivial documentation tasks, I end up with a bit of custom
markup and a bit of custom stylesheet processing. Sometimes I do that by
making an actual schema customization, sometimes with Schematron, and
sometimes by leveraging the new âlocal-conventionsâ transformation in
xslTNG[1].

I suppose, that's probably the way to go. Or we could go the variant approach
as described in the last paragraph. :)


Sometimes I would appreciate some more hooks to ease customization. ;)

Such as?

I don't remember exactly what was missing, as it has been some time since I
worked on our DocBook customization.

As far as I remember, I wanted to remove the xml:id attribute on certain
elements. Obviously you have to adapt the respective .attlist pattern.
Certainly there is no general pattern for that. Perhaps not the best example.

Maybe a better one and I vaguely remember now is that DocBook is basically
grouped into division, block, and inline elements. However, you can't
customize, let's say, all inline elements as the patterns aren't grouped that
way in the schema.

For example, if I want to forbid xml:id on all inline elements but keep the
other groups untouched, I can't do that with one single line. I have to go on
each and every inline element and adapt the .attlist pattern. It's not
difficult, but a bit cumbersome.

This is our DocBook customization:

https://github.com/openSUSE/geekodoc/blob/main/geekodoc/rng/2_5.2/geekodoc-v2.rnc


--
GruÃ/Regards
  Thomas Schraitle



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]