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:]
> Sent: Wednesday, March 20, 2013 13:04
> To: DocBook Technical Committee
> Cc:
> 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 .
> 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
>
>
