Groups - Meeting Minutes 13 December 2017 uploaded

[Richard Hamilton<hamilton@xmlpress.net>]

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

The DocBook Technical Committee met on Wednesday, 13 December 2017

Agenda

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.
     CONTINUED

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

  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.
     CONTINUED

  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
figures.

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):
  https://github.com/docbook/docbook/issues/NUMBER

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