OASIS DocBook TC2

 View Only
  • 1.  Re: [docbook-tc] Building the DocBook TDG 5.2 book

    Posted 03-12-2019 22:38
    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 > discussion. 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. > 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? Be seeing you, norm -- Norman Walsh <ndw@nwalsh.com> To think is not enough; you must think http://nwalsh.com/ of something.--Jules Renard Attachment: signature.asc Description: PGP signature


  • 2.  Re: [docbook-tc] Building the DocBook TDG 5.2 book

    Posted 03-13-2019 21:25
    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 discussion. 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: https://lists.oasis-open.org/archives/docbook-tc/201705/msg00011.html Do any of the other TC members recall how we justified buildtarget as its own element? Bob Stayton