Meeting Time: 9:00 AM Eastern
Regrets from:
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 20071123 The recording will be available for about 30 days.
ACTION: Matt post what we had so far for the Table of Contents to the Core list. Done. Note that Matt's email to the list is included toward the end of these minutes for convenience.
ACTION: Jennifer follow this up by showing the Core group what this would look like as a Requirement to be submitted. In progress as of December 4, 2007. for reference, so that others may use it, too, start by going to the Requirements Gathering Overview, and then, once familiar with the process, use the submission form linked from that page. Note that Markus suggested that the Table of Contents be submitted as one item.
Jennifer will be responsible for monitoring the comments that may be posted to an item submitted by the Braille in DAISY Working Group, and she will flag these comments for the group. If a response/clarification is needed, someone will be assigned to speak on behalf of the group and post a comment.
ACTION: One of the items discussed on the call is the need for a context break. This item has been submitted as a requirement, Introduce a separator element into DTBook. The group should review the requirement, as it currently stands, and develop a comment if it believes that the current requirement for a context break does not meet braille readers's and transcribers's needs.
ACTION: Once a decision is made that impacts the "master document" that Robert is maintaining, we should be careful to summarize it on the list.
ACTION: Seek a volunteer to study XSLFO. This part of the XSL 1.0 specification is designed to support presenting XML in other contexts, such as formatting it for printing. Note that XSL has evolved since the specification I have referenced; the designee should be sure to take all relevant references to XSLFO into account to assure best results. A number of free tutorials seem to be available.
The original message from the Maintenance Committee to this group has been included, for reference, at the end of this document. for purposes of clarity, these minutes do not precisely align with this note; I have used headings that organize the information in what may prove to be a more logical fashion.
The group is leaning toward developing a namespace specifically for braille. One of the key benefits is that the different rule-sets, such as BANA and UEB, could be taken into account in this way. Users could select the appropriate parameters, from within the namespace, that applied to their jurisdiction.
Though this topic arose throughout the call, overarching ideas are summarized for convenience in this section of the minutes.
Establishing a separate braille namespace should help to alleviate some of the difficulty this group has been experiencing in addressing all of the details necessary for braille production. the group should focus on identifying what is essential only for braille vs. what is generally necessary for all to use DAISY XML (DTBook) effectively. The group should propose everything that it can think of for braille, and then, anything that the Z3986 Maintenance Committee deems is not useful for all stakeholders should move into the braille namespace.
It was agreed that focusing on adding attributes is easier, so somewhat preferable, but the group should not shy away from adding elements if those are what is needed. George requested that the group add elements with care so that the specification would not have to expand unnecessarily and become too complicated, as a result. We would want to consider, for example, about items such as the dedication, title page, acknowledgements, etc. to see if translation software and current DAISY elements might be able to work together more effectively to provide required output formatting.
One of the benefits of the namespace approach is that software can call upon what is needed before translation, and then, it can call on what is needed after translation to support formatting requirements for different rule-sets.
Also, the derived content can integrate as and/or if needed, with the Portable Embosser Format (PEF).
One example discussed related to footnotes. These cause difficulty since, according to BANA rules, the note must appear on the next line followng the note number. But that line cannot be predicted until after translation is done. Using a braille namespace, with calls to both pre and post processing, may be able to alleviate this tricky brailling situation, but if it cannot, issues with footnotes could be raised with BANA.
Based upon the Maintenance Committee's recommendations, the group should focus on the required structures, rather than focusing on having to develop a detailed content model. We can develop our requirements using plain language. As a result, the Maintenance Committee and representatives from the Working Group will need to communicate as the Maintenance Committee fleshes out the Braille Working Group's requirements to fit them into the standard.
In addition to the Table of Contents, this group will want to submit a requirement for indices, along with other items that may surface as we examine braille rules and seek to identify whether and how, DTBook may not be currently meeting the needs of braille producers.
One example of an item that has been submitted as a requirement is to Develop Methods to Provide Interactive books (workbooks). Since braille has particular requirements for workbooks, those ideas may be added as comments to the requirement.
When a requirement is being formulated, it will be ideal to have a clean version for Jennifer's review and approval. Necessary clarifications can be made in the comments. When the Braille in DAISY Working Group posts a requirement, there should be basic consensus; however, if there is descent within the group, this should be indicated.
The Requirements Gathering process will close on March 31, 2008.
The Maintenance Committee is expected to meet face-to-face in mid-April of 2008. In the meantime, the Committee holds a conference call bi-weekly.
The next Braille in DAISY Working Group call is slated to be held on December 7. Please monitor the list for details of the time and the agenda.
From: Matt Garrish Matt.Garrish@cnib.ca
To: braille-in-daisy Core Groupcore@mail.daisy.org>
Date: Mon, 26 Nov 2007 17:32:22 -0500
Subject: Table of Contents
As discussed on Friday, following is the last structure we had for tables of contents,
followed by the DTD snippet that we provided to the zed committee.
I only wonder if we're submitting this for inclusion in dtbook whether we need to
revisit the finer details of textbook production. It won't be as easy to amend later.
I also assume that we will need to come up with some
verbiage to accompany the submission to explain the rationale behind the structure.
--- sample markup
<toc>
<toctitle></toctitle>
<tocpart>
<tochd></tochd>
<tocentry>
<tocmain>
<pageref refid=""></pageref>
</tocmain>
<tocsub></tocsub>
</tocentry>
</tocpart>
</toc>
--- sample dtd
<!ELEMENT toc (toctitle?, (tocpart|tochd|tocentry|pagenum)+)>
<!ELEMENT toctitle (%inline;)*>
<!ELEMENT tocpart (tochd?, (tocentry | pagenum)+)>
<!ELEMENT tochd (%inline; | (div, pageref))>
<!ELEMENT tocentry (sidebar?, tocmain, tocsub?, tocentry*, textbox*)>
<!ELEMENT tocmain (div, pageref)>
<!ELEMENT tocsub (%block;)+>
<!ELEMENT pageref (#PCDATA) >
<!ATTLIST pageref
refid CDATA #REQUIRED
After discussion at our meeting in London, the Committee had the following overall suggestions: 1. It is important to identify elements that are semantically relevant for braille production (and, in fact for all production) for inclusion in the dtbook element set. The high level elements in your DTD: toc, index, cbr, acknowledgements are very helpful and are the types of semantic elements we would consider that everybody needs. We know that this was your goal. If you simply identify these elements without going into a content model in the DTD, that would be easiest for all. We are looking at importing modules that cover these issues from other domains, such as TEI and DOCBOOK. We will deal with these. We expect that the same concepts will come in from large print interest groups and other sectors. Perhaps if you could first approach and identify the high level structures that are needed, that would be most helpful. We think we would like to see these things first. You can submit these structures as requirements for the specification through the web form we have just set up for this purpose: http://www.daisy.org/z3986/requirements/ 2. The committee believes that beyond these new semantic constructs, it will be necessary to provide new elements and attributes that will help to create well-formatted braille. However, rather than include these within the dtbook namespace, the committee felt that a more appropriate technical approach would be to use namespaces to provide braille specific information for formatting. XML processors will ignore elements and attributes which they do not understand, and thus will allow a document instance marked up in dtbook with braille-formatting attributes and elements to pass through without problems. In other words, we can maintain a single source approach even though there are many items that provide braille-specific formatting rules in their own namespace. We do not know if there are different namespaces for different braille jurisdictions, but it should be possible to identify the rules that are in common and have a shared braille namespace definition (common_braille, and EBU, or BANA). In this way the common braille rules can be identified and those that are EBC or BANA could live happily in the same source file. The committee would love to schedule a joint conference call to explore this technical solution further. The committee feels that this is the best technical approach to implement the great suggestions that you are making for improving braille support in DAISY. We believe that the enhancements to the semantic elements would provide enough to allow very good braille to be produced, but that the additional step of providing braille namespace attributes would go beyond this to enable the production of terrific braille. Again, thank you for your input. This is very helpful in our requirements gathering process. Best George, on behalf of the Z3986 team