DocBook Technical Committee Meeting Minutes: 9 May 2018
=============================================================
The DocBook Technical Committee met on Wednesday, 9 May 2018
(11am PDT, 12noon MDT, 1pm CDT, 2pm EDT, and 8pm CEST)
1.
Roll call
a.
Attendees: Richard , Scott Hudson, Larry Rowland, Robert Stayton
b.
Regrets: Bill Burns
2. Accept the minutes [1] of the previous meeting (11 April 2018)
3. Next meeting: 13 June 2018
4. Review of the agenda.
5. Review of open action items
a: Bob to update Docbook.org to reflect Errata 01 once the schema is available on the site for download.
b. Jirka will prepare a new release to incorporate <formalgroup> (5.2).
c. Bob to follow up with Jirka to determine why the namespace was lost (issue 88).
d. Bob to fix the catalog as part of the 5.1 Errata 01.
e. Larry to repost examples of <transform> usage in assemblies. COMPLETED.
f. Larry to create a candidate for the necessary schema changes to add XInclude support for Assemblies for DocBook 5.2. CONTINUED.
6. Issue 71: Parts can be done using RDFa, but some require structural changes. Jirka pointed out an issue that there is no definitive RDFa vocabulary, which will make portability more difficult. This will
need to be addressed. There is no obvious solution to only use RDFa.
Larry: There are not parent/child relationships for copyrights and licenses. They are more peer elements that would occur in info.
Bob: We do have legalnotice, which is like a license.
Larry: Part of the issue is that legalnotice does not have a rich structure.
Larry had posted markup examples to the list previously.
Bob: Including more rich markup in legalnotice (content model to resemble section) might help this? common block.
Larry: Yes, but might need a class attribute to indicate that it is a license as opposed to some other legalnotice. Licenses may have sections.
Dick: This could get complex enough to warrant an article model. What if you could include the legalnotice element inside of some element structure to indicate that it is a license? (include in article or
appendix, for example).
Dick had several pages of copyright notices and used legalnotice to point to where the license information resided (in a later appendix). Rather than creating a full structure, use by reference.
Larry: Make legalnotice a block structure to help the current issues. Add a class attribute or attribute value to article, appendix, section, etc. Open source could have many, many licenses that have to apply
to a product.
ACTION: Larry to re-post legalnotice examples to help with the classification.
7. Issue 100: Fix namespaces and catalog for 5.1 errata.
One issue is that the changes proposed for assemblies is too big for an errata, so should be included as part of 5.2. (consensus).
8. Social media presence for DocBook
Purpose: To raise awareness of actions (votes, calls for information, etc.)
No update.
9. Schematron namespace has a different namespace. There is no way to rescind an Errata (which is now incorrect).
Proposal: create a 5.0.1 release that is compliant with the new namespace.
Jirka is willing to create and test 5.0.1 version. Would need to create a candidate specification and move this through the release process.
5.1 has its own issues.
Bob: made a motion to create a 5.0.1 version. Dick: seconds. Vote: unanimously approved.
ACTION: Bob to create the draft specification to get the process started.
10. Assemblies
Originally, there was confusion about the use of the grammar, transform and name attributes. Proposed intentions:
Grammar was to identify a particular set of content. A matching grammar should also appear on the transform to convert the content appropriately.
name is used to identify a particular set of content, with a matching transform to some non-standard output.
grammar = inputs to normalize to DocBook
name = outputs from DocBook to a non-standard format
ACTION: Bob to work with Jirka to incorporate these changes.
Larry: I thought there was more issue with doc than schema? name and grammar should be mutually exclusive. You shouldn't have both a name and a grammar because they serve different purposes.
Bob: If we create a transform that converts DITA to DocBook, you could have a grammar="DITA" and a name="DITA"
Larry: The same transform couldn't be used to convert DITA to DocBook. It adds a layer of confusion to add both.
Dick: Could imagine that a grammar is DITA, but a name that is specific to a specialization of DITA that the transform applies to.
Larry: Those should be 2 separate transforms. There is no advantage to having both name and grammar specified.
DECISION: set name OR grammar, but not both on both transform and resource.
We talked about type as an attribute (mime type example for grammar was confusing).
Bob: is it useful?
Larry: it was a red herring. It just adds more confusion.
DECISION: do not use mime type.
In the samples, there was a resourceref that was pointing to a structure? We have not documented such a case.
Larry: I think it was to say that resources don't necessarily have to be an external resource. The idea being that a structure could be defined as a resource that could be used in another part of the structure.
It was intentional in the example, but not sure if it is supported in the schema.
ACTION: Add structure as a resource discussion to agenda for next time. Should a resourceref be allowed to point to a structure id?
11. 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):
6 Add buildtarget element (added to v5.2b05 by Jirka)
49 Support multiple image resolutions (implemented in 5.2b02 by Jirka)
54 Add XIncludes to Assembly Schema (accepted)
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
94 Allow subfigures (accepted)
99 Add <endorsement> to <info>
100 DocBook 5.1 catalog.xml uses incorrect version
NEW:
102 Add
"interface" value to systemitem class
Bob: proposed. Larry: seconded. Accepted.
Links:
[1] https://lists.oasis-open.org/archives/docbook-tc/201804/msg00007.html
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.