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: Groups - Meeting Minutes 13 December 2017 uploaded

Submitter's message
DocBook Technical Committee Meeting Agenda: 13 December 2017

The DocBook Technical Committee met on Wednesday, 13 December 2017


1. Roll call
Voting members: Scott Hudson, Dick Hamilton, Bob Stayton, Larry Rowland.
Non-voting: Bill Burns

2. Accept the minutes [1] of the previous meeting (8 November 2017)
>> Accepted with no objections.

3. Next meeting: 10 January 2018

4. Review of the agenda.

5. Review of open action items

a: Larry: See if we can use Jirka's suggested RDFa vocabulary
for license links for the examples Larry identified.

b. All: Look for other example (e.g., Flickr) and try
out the license link vocabulary.

c. Bob: Ask Jirka whether schema website has been updated.
ACTION: Bob consult with Chet about using Errata for 5.0.
COMPLETED: see notes on Action d.

d. Bob: complete the errata for DocBook 5.0.
COMPLETED: Sent to OASIS for their review of the format.
Vote will occur after they approve it. Keep open until vote.

e. Jirka: Update schema for 5.2 to allow zero or more instances of
type as described in issue 91.

f. Bob: Update documentation related to github issue 93
About mismatch between docs for assembly and spec.
Found another issue, so Bob will review the entire chapter
to make sure the docs match.
CONTINUE: hold for Bob to complete review and make any changes.

g. Bob: Add agenda item to December meeting to discuss creating
a social media presence for DocBook (e.g., twitter).
COMPLETED: see item 6 below.

h. Larry: investigate LaTeX support for subfigures.
See item 7 below.

6. Discuss creating a social media presence for DocBook
>> Scott did some research, and there is no formal OASIS process. Which platforms
do we want to use, and is there any content we want to start with? Need a method
and strategy for using social media. Suggest we use OASIS email for chair. Discussed
aggregators, including Hootsuite, but it looks like we may not need one for just a few
platforms. Agreed to start with Facebook, LinkedIn (already exists), and twitter.

7. Discuss subfigures (Github issue 94)
>> There was a subfigure and subfig package in LaTeX, which are now deprecated.
Now people use the caption package. The idea is to get a reasonable model for
cross-references and TOCs. Now, you use the caption package, which enables
sub-captions, then within a figure, you use sub-floats to put elements inside a
figure. Can do the same thing with tables, because both are implemented as floats.

The idea is that by adding the correct package, you can have multiple elements inside
the figure wrapper, and its caption will show up around all of the figures and sub-captions
will show up with the correct sub-figure, and everything will end up correctly displayed in
the TOC. The deprecated packages had issues, and going to sub-floats instead of
sub-figures made things better.

In technical documentation and scholarly publications, the ability to do this is
important. Especially in scholarly pubs, but also in tech docs. Therefore, we
should handle this. Larry has not seen a need for going below a single level of

Whether we should nest figures or add a subfigure element is probably as much a
question of implementation difficulty as anything else.

Bob: Do subfigures fit into the scope of what DocBook should handle?
Group agreed that they do and that we should handle them.

Also, should we extend to example and equation?
Agreed that we should include figure, example, and equation.

Question is whether we should nest or have subfigure element? Although
formatting shouldn't drive the discussion, we can't completely ignore.

Larry: Once you get beyond one level, complexity goes way up.

How to express alignment of multiple subfigures (vertical vs. horizontal).

We have attributes on simple list for vertical vs. horizontal. We could use
a similar approach to provide hints to renderers.

How about using a wrapper, rather than a subfigure? The wrapper could contain
the attributes and would make it easier to reuse figures, since you wouldn't need
to recode if a figure changed into a subfigure.

Should the wrapper be an omnibus element that could contain any kind of
element or a mix of different elements? If you do that, what do you do in a TOC?
Might show up in the TOC for each type, but numbering would be strange.

A mixed group may be solving a problem that doesn't exist.

The TC agreed that a single wrapper element with homogeneous content
is the best way to go.

ACTION: Larry: design a content model for the wrapper element.

8. Review of Requests for Enhancement

To find a Github issue by number, enter the URL (on one line):

Open Issues (Note: items that have been accepted are still open
on Github until included in a release,
but they are not listed here):

6 Add buildtarget element

54 Add XIncludes to Assembly Schema

71 license tag

72 The DocBook websites should really be using https

78 Schema website should be updated

88 DB 5.0: @name -> title change not published on docbook.org

93 Diff between doc of resource element and Assembly schema

94 Allow subfigures

97 Missing bibliography in glossary

[1] https://lists.oasis-open.org/archives/docbook-tc/201711/msg00002.html

-- Mr. Richard Hamilton
Document Name: Meeting Minutes 13 December 2017

No description provided.
Download Latest Revision
Public Download Link

Submitter: Mr. Richard Hamilton
Group: OASIS DocBook TC
Folder: Meeting Notes
Date submitted: 2017-12-13 12:41:50

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