Minutes – Z39.86 Advisory Committee Conference Call

Date: 2006 January 25
Time: 9:00 – 10:10 EST
Venue: telcon
Scribe: Laurie Sherve
Last Edited: 2006 January 25
Status: Version 3

Attendees

Advisory Committee:

Participating Experts:

Apologies:

Agenda

Confirmation of Date and Time for Next Call

GK proposed that the next call be held on March 1, 2006.

Structure Guidelines/Documentation of the semantics of DTBook

ACTION: Dave to work with Lynn to create a list on semantics of dtbook.
ACTION: Dave to send Lynn his work creating a list of semantics from a schema.
ACTION: Lynn will ask for volunteers as required on DAISY mailing lists.
ACTION: Mark will ask the SMIL folks to find a SMIL introduction/overview.

The Structure Guidelines identify elements and their associated markup, but not each element's semantics. The Structure Guidelines need a straightforward list of DTBook elements and the semantics of each. Dave started this body of work and has created a schema that generates content in xml. He will send this to Lynn. The schema can be used for the next generation of the DAISY standard.

Brandon is also interested in the semantics list, and may help Lynn. Lynn will ask for other volunteers as required on the techdev and xmltechniques list.

Markus pointed out that 95% of the questions on dtbook regard what is not supported. Therefore, do we address the "holes" in dtbook? This is a critical issue because everyone will resort to html markup to solve omissions. Dave suggested that we collect a list of "holes" or omissions in dtbook.

James suggested after the "holes" are identified, the committee needs to decide how to handle each "hole" within constraints of the 2005 standard, and how to make a book that will play on existing players. Whatever is decided as the best way to handle each omission may become work items for next or future versions of the specification.

The issues that arise from identifying and resolving omissions in the specification should be tracked as a issues, errata, and future directions. The Structural Guidelines will provide guidance and pointers to issues as they arise.

DTBook issues resolution

ACTION: Markus to lead group focusing on revisions to the DTD based on the issues submited, including the attribute.
ACTION: James, Linus, Lloyd to work with Markus on team focusing on DTD revisions

There are many issues with the current DTD, including an issue regarding the <showin> attribute. This attribute issue seems to be of special interest. The MathML-in-DAISY working group is having difficulty figuring out what a reading system would do if presented with a paragraph with content and the <showin> attribute. Would the reading system present the normal paragraph first and then follow it by the braille formatted paragraph (assuming this is a braille enabled device)? There is no example of this in the guidelines.

For example, there is a picture of an equation followed with a textual description. and then a paragraph with attributes. How does a reading system with braille display know what braille to display? Is this an error in the DTD?

This problem is not documented. There is no bracketing element or container to determine what <showin> applies to. How does a reading system know what value to choose, such as print only, braille, or large print? There is no default value for <showin>

Markus will lead a group to work on the DTD, including James, Linus and Lloyd. This includes the <showin> attribute. Depending on the scope of work, the project should take one to two months. Changes to the DTD will create changes to the Structure Guidelines.

Errata Status

ACTION: George, Laurie to author errata introduction and present to committee for approval.

The status of errata remains an open question undecided by the committee.

Dave strongly recommended that DAISY compose a Process Document addressing how to deal with different types of errata.

However, what do we do to get issue tracking announced if we can't agree on the status of errata?

James suggested that we acknowledge that the status of errata is unclear, and that the question of compliance with the standard is not cut and dry. However, errata are clear errors and the committee strongly recommends that best practice is to fix these errors in future production and playback systems.

Items on agenda, but not covered

	     Update on the global library.