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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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

Subject: Re: [docbook-tc] Building the DocBook TDG 5.2 book

Other TC members are invited to add to my comments below.

On 3/12/2019 3:38 PM, Norman Walsh wrote:

Bob Stayton <bobs@sagehill.net> writes:
The formalgroup element was very specifically designed to support
subfigures 1a, 1b, etc., and the same for other formal numbered
elements like equations, examples and tables. It allows for
autonumbering by the stylesheet, titles and captions for each, as
well as automatically generated xrefs to specific subfigures. We
noted that TeX supports subfigures. This is a common use case in
technical documentation, and we could see no way to easily support
it otherwise. We did not consider any general wrapper during this
I stand by my observation: if you have a rationale for grouping formal
objects, you are a teeny, tiny step from having a rationale for
grouping informal objects. (There are no other places where thereâs a
complete lack of parallelism as far as I can recall.)

Wanting to group figures so that they can be titled as subfigures
makes sense. Wanting to group them so that they donât cross a page or
column boundary, or have a common border, or a common background all
make equally good sense to me.

Persuaded to add a group for formal objects, Iâd have argued for
db:group (and possibly group-style because I really dislike fgstyle)
where you can wrap either formal or informal objects.

I'm not seeing a use case for grouping informal elements like we have for formal elements. I don't find the argument for parallelism to be very compelling. We allow informal but not formal elements in cover, for example.

I think adding an element named group invites expansion into a general grouping element, which we have always avoided. That would be adding grease to the slippery slope. :-)

Norm, we always appreciate your comments and suggestions because of your long history and commitment to DocBook. Wish you were here. When you say "Iâd have argued for" it sounds like you would like to rejoin. Have you considered rejoining as an individual?

1. I think âbuildtargetâ is awfully specialized to be raised to the
level of its own inline. There are lots of things relegated to a class
value on âsystemitemâ that strike me as equally common: filesystem,
macro, server, â

How did âbuildtargetâ justify its own inline? Is it time to give up on
any sense of limiting the number of elements and just raise all the
systemitem classes up?
Any feedback on this comment?

I researched this and it seems we did not adequately record the discussion in the minutes.ÂÂ Larry sent a background email on this issue before the discussion:


Do any of the other TC members recall how we justified buildtarget as its own element?

Bob Stayton

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