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: DocBook Technical Committee Meeting Minutes: 12 December 2018


DocBook Technical Committee Meeting Minutes: 12 December 2018

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

The DocBook Technical Committee met on Wednesday, 12 December 2018

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

1.             Roll call

    1. Bob, Larry, Scott

Regrets: Sabine Ocker

2.          Accept the minutes [1] of the previous meeting (14 November 2018) 

3. Next meeting: 09 January 2019

4. Review of the agenda. 

5. Review of open action items

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

                                                XIncludes seem to be working successfully. Sample sent to the mailing list. ACTION: all to test and provide feedback. Add to agenda for next meeting.

b.       Bob/Jirka to include Assembly proposals in 5.2:

                                                                                       i.      Jirka provided samples, Bob still needs to test. 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

**Bob clarify according to minutes: Add @name to transform and @transform to resource. Need to reflect changes (after test) to the documentation.

d.       Bob to follow up on the synopsis RFEs to request more clarification.

                                                                                       i.      Jirka followed up with requestor, who provided further use case. Bob to follow up. COMPLETED.

Bob pushed back on requestor (see comments on https://github.com/docbook/docbook/issues/108 ).
We would need to add a programming extension to the schema (not included by default, similar the publishing extensions). Syntactic markup may be needed in the future. Extension would meet the user needs. TC is amenable to creating this extension.  Larry: Need to make sure that such extensions are not specific to any one language, but apply to more than one language. ACTION: Add as agenda item for next meeting.

6. XInclude support for Assemblies for DocBook 5.2. 

            All need to test.

 

7. Legalsection vs section - Norm (via list) suggested adding it to db.nopara.blocks.

Possibly by creating a new pattern, maybe âdb.notice.blocksâ. Reluctant to allow section in legalnotice (don't allow block content after a regular section). What about enumeration? Suggest making it behave like simplesect.

            Bob: How does this fit into the structure of DocBook?
            Larry: If we add legalsection as a valid child of legalnotice, and give it the same content model as legalnotice, so that anything in a legalnotice could fit in a legalsection (Same as section, where once you start adding sections, you can't add other blocks). If legalsection is made valid whereever a section is valid (following the same rules), then legalsection is allowed in all of the cases where we need them with the complexity of legal content. Having legalsection as a valid sibling of section would then allow for reuse of opensource content, when a license has to accompany that reuse. legalnotice stays in info, but legalsection would be allowed as a sibling to section (as part of the section hierarchy). Some of Larry's samples have 80-90 licenses that they have to document due to use of open source components! This proposal meets the needs.

            Bob: adds one element (legalsection), and modifies structure of another (legalnotice). Fairly easy to handle, even with assemblies! Legalnotice model would need to add legalsection as allowed at end of legalnotice.

            Larry: Still need a few @class enumerations needed for legalnotice + an otherclass override extension. ACTION: Larry to send list of enumerations.

ACTION: All look at legalnotice model and proprose any changes.

 

8. Social media presence for DocBook

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

Scott to post link to final files (when available); Scott to update OASIS public page with final files. COMPLETED

Bob updated DocBook.org references, including zip files.

  

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 CLOSED

 

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

 

107 namespacesynopsis - should use generic <info> rather than introduce <namespacesynopsisinfo>. (Tentatively accepted for 5.2)

108 enumsynopsis (Tentatively accepted for 5.2)

109 typedefsynopsis (Tentatively accepted for 5.2)

110 macrosynopsis (Tentatively accepted for 5.2)

 

NEW:

none.

  

Links:

[1] https://www.oasis-open.org/apps/org/workgroup/docbook/email/archives/201810/msg00010.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

 

/Users/scott.hudson/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_2139744458

 

This document contains only administrative, uncontrolled data under U.S. International Traffic in Arms Regulations.



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