← Prev in month ← Prev in thread
Next in thread → Next in month →

DocBook Technical Committee Meeting Minutes: 24 October 2018

From
Scott Hudson <>
Date
2018-10-24T18:48:18+00:00
ID
Thread
DocBook Technical Committee Meeting Minutes: 24 October 2018
DocBook Technical Committee Meeting
Minutes: 24 October 2018

=============================================================

The DocBook Technical Committee met on Wednesday, 
24 October 2018

(11am PDT, 12noon MDT, 1pm CDT, 2pm EDT, and 8pm CEST)

1.        
Roll call

Jirka Kosek

Larry Rowland

Sabine Ocker

Bob Stayton

Scott Hudson

2.       
Accept the minutes [1] of the previous meeting (12 September 2018) 

Bob moves to accept. No objections. Meeting minutes accepted.

3. Next meeting: 14 November 2018

4. Review of the agenda. 

5. Review of open action items

a.   Bob to follow up with Jirka to determine why the namespace was lost (issue 88). COMPLETED.

                schema element was missing a namespace. Fixed for next release.

b.       Bob to fix the catalog as part of the 5.1 Errata
 01. COMPLETED.

c.       Larry to create a candidate for the necessary
 schema changes to add XInclude support for Assemblies for DocBook 5.2. CONTINUED.

d.       Bob
 to create a sample of structure as a resource and test stylesheet mods to see if it introduces further issues. COMPLETED.

Resource can now point to another structure, which can be resolved, allowing assemblies of assemblies!

e.         Bob/Jirka to include Assembly proposals in
 5.2: CONTINUED.

i.                     Grammar is used to identify a particular set of
 content. A matching grammar should also appear on the transform to convert the content appropriately.

ii.                   name is used to identify a particular set of content,
 with a matching transform to some non-standard output.

iii.                 grammar = inputs to normalize to DocBook

iv.                 name = outputs from DocBook to a non-standard format

v.                   set name OR grammar, but not both on both transform
 and resource

vi.                 do not use mime type for grammar

              f.   Bob to follow up with Norm on toolchain issues and documentation. COMPLETED.

Jirka creates schemas, Bob worked with Norm on stylesheet distribution and docs.

 

              g.  Larry to rework with a legalsection, Bob to provide an XSL customization. COMPLETED.

Jirka suggested using section, so this may require further discussion re: introduction of new element. ALL: review before next meeting.

h.   Larry to experiment with nesting legalsection and also with attempting legalnotice nested within legalsection.
 COMPLETED.

6. Request a Special Majority Vote to approve v5.0.1 as a Committee Specification.

No comments after public review.

"I move to approve the Chair requesting that TC Administration hold a Special Majority Ballot to approve The DocBook Schema Version 5.0.1 Committee
 Specification Draft 01, 09 July 2018, contained in http://docs.oasis-open.org/docbook/docbook/v5.0.1/csd01/docbook-v5.0.1-csd01.docx as
 a Committee Specification." Larry moved. Scott seconded.

Unanimously approved.

ACTION: Bob to fill out request form with OASIS and a formal ballot should be created by OASIS.

 

7. Other business

 

8. Social media presence for DocBook

Purpose: To raise awareness of actions (votes, calls for information, etc.)

Scott to post when v5.0.1 is fully approved.

  

9. Review of Requests for Enhancement

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

github.com/docbook/docbook/issues

 

Open Issues (Note: items that have been accepted are still open

on Github until included in a release,

but they are not listed here):

 

71 license tag

  

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

  

99 Add <endorsement> to <info>

Consider for Publishers.

 

100 DocBook 5.1 catalog.xml uses incorrect version

 

103 XML DTD of DocBook 5.1

 

NEW:

107 namespacesynopsis - should use generic <info> rather than introduce <namespacesynopsisinfo>.

108 enumsynopsis

109 typedefsynopsis

110 macrosynopsis

 

How much of this is aimed at a specific language vs. how much can be generally applied to multiple programming languages. Can existing synopsis elements be used with a class attribute,
 rather than creating new individual elements? It would be interesting to know if the content models would be different for these?

 

What about adding a class/otherclass attribute to the existing synopsis element? Would the role attribute suffice? (only works if the content models do not differ).

 

What is the use case? How would these need to be individually used from a documentation point of view? (indexing?)

 

Would the existing markup meet the use cases here? We create elements for every possible component of every programming language (and stay up to date with new language developments!)

 

ACTION: Bob to follow up on the RFEs to request more clarification.

 

Links:

[1] https://www.oasis-open.org/apps/org/workgroup/docbook/email/archives/201805/msg00005.html

[2] https://www.oasis-open.org/apps/org/workgroup/docbook/documents.php

  

Thanks and best regards,

 

--Scott

 

Voting member:

Boeing Data Standards Technical Advisory Board

OASIS DocBook TC (Secretary), Publishers SC (Chair)

OASIS DITA TC, Tech Comm SC, LwDITA SC, Learning Content SC (Secretary)

OASIS DITA Adoption TC

OASIS Augmented Reality in Information Products (ARIP) TC

 

Scott Hudson

Content Strategist, Digital Aviation Learning and Development

Jeppesen, A Boeing Company

55 Inverness Drive East

Englewood, CO  80112

303-328-6228 | Cell: 303-350-7934

 

 

This document contains only administrative, uncontrolled data under U.S. International Traffic in Arms Regulations.
← Prev in month ← Prev in thread
Next in thread → Next in month →