RE: DocBook Technical Committee Meeting Minutes: 20 March 2013

["Cavicchio, Rob" <rob.cavicchio@emc.com>]

Regarding the discussion about conditionalizing the <info> element, I like the approach of allowing multiple <info> elements. In general, I think that the possibility of conditions means that we should never restrict an element to a single occurrence without taking into consideration the conditional markup.


> -----Original Message-----
> From: Bob Stayton [mailto:bobs@sagehill.net]
> Sent: Wednesday, March 20, 2013 13:04
> To: DocBook Technical Committee
> Cc: docbook@lists.oasis-open.org
> Subject: DocBook Technical Committee Meeting Minutes: 20 March 2013
> 
> DocBook Technical Committee Meeting Minutes: 20 March 2013
> =============================================================
> 
> The DocBook Technical Committee met on Wednesday, 20 March 2013 at
> 1:00pm ET for 40 minutes.
> 
> 1. Roll call
> 
> Present: Loren Cahlander, Dick Hamilton, Nancy Harrison,
> Scott Hudson, Jirka Kosek, Larry Rowland, Bob Stayton
> 
> Regrets: Norm Walsh
> 
> 2. Accepted the minutes [1] of the previous meeting.
> 
> 3. Next meeting: 17 April 2013
> 
> 4. Review of the agenda.
> 
> No new items.
> 
> 5. Review of open action items
> 
>   a.  Norm to publish an XSD for 5.1 when it is finished.
>       CONTINUE
> 
>   b.  Norm to follow up on OASIS mirroring the schema directory.
>       CONTINUE
> 
>   c.  Larry to try mapping slides to assembly.
>       CONTINUE
> 
>   d.  Norm to clarify bridgehead entry in TDG to indicate
>       that bridgeheads are not numbered like sections.
>       CONTINUE
> 
>   e.  Norm to update The Definitive Guide that the
>       behavior of nested links is undefined by the standard.
>       CONTINUE
> 
>   f.  Norm to prevent link element nested within link element in
> DocBook
> 5.1.
>       CONTINUE
> 
>   g.  Norm to produce a DocBook 5.1 candidate release.
>       CONTINUE
> 
>   h.  Bob to research the TC minutes on the status of RFE 3156768
> <result>
> tag
>       COMPLETED
> 
>   i.  Norm to follow up on RFE 3491860 license tag
>       CONTINUE
> 
>   j.  Dick to investigate status of RFE 3599576 'info' wrapper element
>       COMPLETED
> 
> 
> 6.  OASIS website issues
> 
> Continued.
> 
> 7.  Publisher's and eLearning subcommittee reports
> 
> Scott reported that the Publisher's subcommittee met and
> discussed the latest draft. They accepted one new RFE
> so a new draft will be prepared. They had a request to
> change the documentation of rowheader. They expect to
> deliver the new version after these changes.  Any further
> RFEs will probably be in a following release.
> 
> The eLearning subcommittee is on hiatus until more
> members can be recruited.
> 
> 8.  Transclusion in DocBook
> 
> Continued.
> 
> 9.  DocBook 5.1 release
> 
> Continued.
> 
> 10. GSoC 2013
> 
> Dick described the Google Summer of Code program.
> We will be applying this year, and the information
> will be tracked on Dick's Wiki. [2]
> Mentors are needed, and get a stipend.
> If you want to participate, get a login from Dick
> by emailing him at hamilton@xmlpress.net.
> The application will be submitted next week.
> 
> 11.  Review of Requests for Enhancement
> 
>     To browse a specific RFE, enter the URL (on one line):
> 
>       http://sf.net/support/tracker.php?aid=XXXXXX
> 
>     RFEs to revisit for 6.0
>       1907003  biblioid content model too broad
> 
>     RFEs under discussion
>       2820947  Ability to transclude text
>       3035565  Allow sections at any level
>       3156768  <result> tag
> 
> Bob sent out an email summarizing past actions and proposing
> a content model for the result element.  The Committee
> approved.
> 
> ACTION: Norm to add result element to DocBook 5.1 schema.
> 
>       3491860   license tag
>       3593209   Add see/seealso under
> 
> This was discussed in the Publisher's subcommittee, but
> they wanted an example.
> 
> ACTION: Dick to prepare an example of "see under" index entries.
> 
>       3599576   'info' wrapper element for processing titlepage
> elements
> 
> Dick reported that the submittor wanted to conditionalize
> a group of info elements, rather than a raft of individual
> elements.  Larry suggested that a general wrapper had
> no semantic meaning, and Bob suggested that the semantics
> come from the role or condition attributes added to it.
> The TC has rejected general wrapper elements in the past
> because they greatly complicate content models, and
> the same effect can be obtained by conditionalizing
> individual elements, with less convenience.
> 
> Dick suggested adding an element for copyright page
> information as an alternative to info.
> 
> Larry proposed an alternative approach: allow more
> than one info element. Common info elements would
> be in an unconditionalized info element, and other
> conditionalized info elements would supplement it.
> 
> ACTION: Dick to propose the multiple info approach
> to the submittor.
> 
>    No New RFEs
> 
> -----
> 
> [1] https://lists.oasis-open.org/archives/docbook-
> tc/201303/msg00000.html
> [2] http://docbook.xmlpress.net
> 
> Bob Stayton
> Sagehill Enterprises
> bobs@sagehill.net
>