Notes for September 14, 2007
Meeting Time: 2:00 PM Eastern
Phone number +1 712 432-7300
PIN: 25693#
once in, press *3 to hear a replay of the conference call. You will be asked for a filename. It is 20070914 The recording will be available for about 30 days.
Action: Jennifer look at TEI and DocBook, if she has time in order to try to identify structures that we might use. These should be familiar to conversion services already, and using them will promote standards harmonization.
Action: Need a volunteer to help with DocBook; Jennifer is running out of time.
Action: Need a volunteer to take the ToC in HTML, put it into DTBook and identify where DTBook is not adequate to the task.
Action: Matt draft the content Model. Done. See a representation of Matt's email posting at the end of this document.
Decision: Use recursive list for the ToC, with nesting list structures, to support software processing and the building of a node set, especially from the main ToC. The position, within the nested set of entries, would be machine-readable. While a flat structre would be more readable by humans, using nested lists will permit more consistent machine-manipulation.
Decision: ToCs should be available, at minimum, in both front and bodymatter. Supplemental ToCs, such as those that begin chapters, cannot simply be autogenerated from the main ToC because sometimes, the main ToC has extra content, such as a paragraph, in it.
The process to which we agreed was to list the elements, as Matt has done. then, the idea was to try to take a real ToC, such as the one Susan J. marked up in HTML, and try to fit it into DTBook, to see where DTBook is not sufficient.
Further, what we might want to do is to take one of Susan J.'s sample documents and see where the current DTBook vocabulary proves inadequate for handling the ToC. For the example of the ToC with comments in the CSS, go here: http://www.dotlessbraille.org/mathtoc2.htm.
What is necessary is to have some sample content representations, posted in the braille Work Area, to which we can point when we go to the Maintenance Committee with our recommendations.
Such a base set is included at the end of this docment.
Though the idea of auto-generating a ToC was not discussed at length, the sense seems to be that autogenerating the ToC may not be possible. In order to do this, the document would have to be more predictable than documents seem to be in terms of content arrangement. During the length of our call, the range of book examples, with different kinds of ToCs and different prospects for supplemental ToCs sprinkled throughout a book would make this difficult to achieve. Software could take a first pass, at least,.
We discussed the pros and cons of a flat ToC vs. one with nested levels. If you have a flat structure, and just levels as numbers (not nested), it would be hard to make a node-set. With a flat structure, there would be no relationships provided by the semantics.
We discussed the location of the main ToC, as well as a range of other possible supplemental ToCs, such as a table of contents consisting of photos, or the like. ToCs could be included throughout a book, such as in "bodymatter" as supplemental ToCs that begin each chapter, but may differ from the main ToC. One will have to be identified as the main Toc.
This topic was not discussed at llength. It seems too early to tell.
Once we establish requirements, it will be valuable to meet with braille software developers every few months to keep them up-to-date and request input. Braille software developers' experiences and opinions will inform our decisions, even as we recognize that they want to focus on the final results of the project.
This timeline should be decided upon, soon. Recommend for decision during the next conference call.
We intend to try to meet every two weeks on Friday mornings. The next call is slated for Friday, September 21 -- this week. the meeting times will be:
If there is no reason for a call, we will postpone until the next scheduled time.
Matt posted a draft to the list on Saturday, september 15, 2007.
As discussed Friday, I'm going to list off the major structural elements that we are discussing at this point. I'm not going to touch on the full content model, as it is assumed at this point that existing elements within DTBook can be used to round out what is not referenced here.
For simplicity, I'll break this email up into two sections: the first will be a barebones tag set showing the hierarchy of new elements being proposed (with no content to clutter) and the second will be a tag-by-tag explanation of each.
<toc>
<toctitle></toctitle>
<tocpart>
<hd></hd>
<tocentry>
<tocmain>
<pageref refid=""></pageref>
</tocmain>
<tocsub></tocsub>
</tocentry>
</tocpart>
</toc>
toc
- purpose: marks the point of a table of contents for proper formatting by braille software.
- frequency: zero or more instances anywhere within the front, body or rear matter of a document.
- notes: TBD whether and how the main table of contents for the work needs to be identifiable if multiple instances are allowed.
toctitle
- purpose: specify the title for the toc ("Contents", "Table of Contents", etc.).
- frequency: zero or one instance within a toc.
- notes: could also be used within a tocpart, but would lose meaning as the heading for the toc. Could also be dropped in favour of the existing hd tag so long as only one instance is allowed at the root level of a toc.
tocpart
- purpose: divide up a table of contents into logical parts by heading; possibly combine multiple tables of contents into one toc element.
- frequency: zero or more instances with a toc.
- recursive element
- notes: without a tocpart and heading, there would need to be a heading element to distinguish a division heading in a toc from a regular entry for formatting. Using a tocpart would encapsulate all the entries that belong to that part.
tocentry
- purpose: define entries in the table of contents.
- frequency: one or more tocentry elements must appear in a toc or tocpart
- recursive element
tocmain
- purpose: indicate the primary entry line for the entry (containing the page number).
- frequency: one tocmain element must appear in every tocentry.
tocsub
- purpose: separate all subentry information from the main line.
- frequency: zero or one instance with a tocentry.
pageref
- purpose: indicates a reference to a page within the document.
- frequency: one instance with a tocmain, may additionally be used multiple times in subentry
- notes: the pageref's refid will contain the id of the page being referenced. pageref is an element that would have wider applicability. It would also be useful in indices and where a link to a page is needed.