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

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