|I tried to send regrets, but they bounced.|
Sorry, I had a last-minute legal IPR review I had to attend to for the company. I should be able to make it next month.
The Publishers 1.1 schema is out for review, but have not received any new comments. We are ready to move forward as part of the 5.1 release.
DocBook Technical Committee Meeting Minutes: 22 May 2013
The DocBook Technical Committee met on Wednesday, 22 May 2013 at
1:00pm ET for 40 minutes.
The DocBook TC uses the #docbook IRC channel on
irc.freenode.org. The IRC channel is used for exchanging
URIs, providing out-of-band comments, and other aspects
of the teleconference, so please join us there if at
1. Roll call
Present: Norm, Loren, Jirka, Larry
Regrets: Bob, Nancy
2. Accepting the minutes  of the previous meeting.
3. Next meeting: 19 June 2013
No regrets heard.
4. Review of the agenda.
5. Review of open action items
a. Norm to publish an XSD for 5.1 when it is finished.
b. Norm to follow up on OASIS mirroring the schema directory.
Some discussion. Narrow answer: everything on the site has to go
through the 30/60 day member review process.
Norm: I don't really know what to do. I'll follow-up again with the
administrator to see what the current status of the pages is.
Jirka: If OASIS can't be flexible, maybe we have to just move all the
ancillary materials to docbook.org and only put approved standards on
the OASIS site.
Norm: Yes, I think that's one possibility. We've got the worst
situation now, where the stuff on the OASIS site is out-of-date but
looks like an attempt to have the ancillary materials there.
c. Larry to try mapping slides to assembly.
Larry: I'm having trouble getting the schema that Bob sent me work.
I'm working to get a sample from the folks who put this together over
the summer. It seems to have some unrealistic content models.
d. Norm to clarify bridgehead entry in TDG to indicate
that bridgeheads are not numbered like sections.
e. Norm to update The Definitive Guide that the
behavior of nested links is undefined by the standard.
f. Norm to prevent link element nested within link element in DocBook 5.1.
g. Norm to produce a DocBook 5.1 candidate release.
h. Norm to follow up on RFE 3491860 license tag
i. Norm to add result element to DocBook 5.1 schema.
j. Dick to prepare an example of "see under" index entries.
k. Dick to fix the DocBook5 conversion stylesheet on SourceForge.
l. Bob to review Dick's fixes to the conversion stylesheet.
m. Norm to change info from "zero or one" to "zero or more"
in DocBook 5.1.
Continued. Norm objects.
n. Jirka to prepare a proposal to support RDFa.
Jirka found that Norm has already done it. Sent a pointer to it, it's
From 14 May.
Norm: Plan is for the committee to publish that as a schema?
ACTION: Norm to pull the rdfalite schema together as a non-normative
5.1 Action "m" change info from zero or one to zero or more
Norm: I object. If you can have more than one info then why not more
than one title or more than one varlistentry or more than one
listitem? Everywhere we limit the content model to a singleton, you
could argue we should allow more than one for multi-language or
profiled documents. With the added wrinkle that info is supposed to do
... I could see the utility in producing a "multi-lingual" or
"profile" authoring schema that allows multiple choices with the
expectation that users should choose a profile and then validate
against standard DocBook. Merging is just part of a pipeline of
actions in this case.
Larry: The request was for a generic wrapper inside of info to
accommodate differences that show up between publishing a book as an
ebook or as a website or a paper version. Rather than having put
collections of elements with condition attributes on each one, they'd
asked for a wrapper.
... It seemed that allowing more than one info element and allowing
the info element to be the wrapper would be easier because they wanted
anything that can go in the info element to be in the wrapper.
... You can do this with assembly, but the request seemed to be
something that allowing more than one info element would satisfy. With
the caveat that you could shoot yourself in the foot.
Norm: Well, the processing expectation would have to be that multiple
adjacent info elements would have to be combined. I think that should
be an out-of-band process.
... I think the purpose of the schema is to define the structure of a
valid (in a technical sense) DocBook document. I don't think we want
to have multiple, sibling info elements be a valid DocBook document.
At this point in time, I think we have tools for doing pre-processing.
Use a wrapper that you delete before processing, or use multiple info
elements that you combine. But transform to DocBook proper before
Jirka: I think I agree with Norm for the reasons he outlined earlier.
Norm: The other thing is that a neutral wrapper like this is valuable
in more places and we've had requests for a generic "block" div, etc.
Loren: Isn't the customization process designed for this sort of thing?
Larry outlined some of the discussion from last month.
Larry: You could also do this with an assembly if you wanted to. I
didn't think of that last time.
Let's leave this on the agenda for next month to see what a larger
6. OASIS website issues
7. Publisher's and eLearning subcommittee reports
No report this month.
8. Transclusion in DocBook
Norm summarizes: it's going through the W3C process to get XInclude
1.1 out as a Recommendation.
9. DocBook 5.1 release
Norm is on the hook for CR1.
10. Review of Requests for Enhancement
To browse a specific RFE, enter the URL (on one line):
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
3491860 license tag
3593209 Add see/seealso under
3599576 'info' wrapper element for processing titlepage elements
3608790 Microdata or RDFa 1.1 Lite support for schema.org
No New RFEs
Any other business:
Jirka: The DocBook distribution includes ITS but we need to update the
schema to ITS 2.0. I need access to the new schema repository.
Norm: I'll take care of getting access for Jirka.
Some discussion of github vs. subversion for the repository.
Be seeing you,
Norman Walsh <email@example.com> | Curiosity will conquer fear even
http://www.oasis-open.org/docbook/ | more than bravery will.--James
Chair, DocBook Technical Committee | Stephens