Minutes – Z39.86 Advisory Committee Conference Call

Attendees

Advisory Committee:

• George Kerscher, Advisory Committee Chair – DAISY Consortium and Recording for the Blind & Dyslexic
• Thomas Kjellberg Christensen – Danish Library for the Blind
• Marisa DeMeglio – DAISY for All Project
• James Pritchett – Recording for the Blind & Dyslexic
• Lloyd Rasmussen – National Library Service for the Blind and Physically Handicapped
• Ole Holst Andersen – Danish Library for the Blind
• Dave Pawson – Royal National Institute of the Blind
• Neil Bernstein – National Library Service for the Blind and Physically Handicapped
• Laurie Sherve, Scribe – DAISY Consortium

Participating Experts:

• Neil Soiffer – Design Science

Apologies:

• Markus Gylling – DAISY Consortium and Swedish Library of Talking Books and Braille
• Dominic Labbé – HumanWare
• Werner Krebs – Design Science
• Chris Wilder-Smith – CAST

Agenda

The agenda was distributed to the Advisory Committee's list on 2005 September 6. There were no amendments in advance of the call.

There were no additions to the proposed agenda.

Confirmation of Date and Time for Next Call

GK proposed that the next call be held on 2005 October 5.

Revision of z3986 Specification

Due to email problems, no one received the revised spec as an attachment. The spec is to be placed on the temporary site, www.daisy.org/z3986/2005/z3986-2005.html for review by the Advisory Committee.

Web Site Status

There were no objections from the Advisory Committee to go live with the temporary web site. The Roadmap to DAISY Implementation document has been put on hold. Neil to assist George with the new site announcement to DAISY members.

Issues, Errata, Future Directions

GK proposed that issues, errata, and future directions to the standard be posted on the web site. New fields added to the existing database would drive issues, errata, and future directions tracking. All open issues will be submitted to the Advisory Committee either through a form on the web site or email. For each issue, the Advisory Committee who will decide on one course of action. If the issue:

1. Is a result of spam, miscommunication, or other error, the issue is dismissed.
2. Is an error in the dtd, an errata is created, the error would be fixed, and a new dtd created. All existing dtds would remain. See Compliance section below.
3. Is an error in the standard, an errata is created, a future direction created, and the error will be resolved in a future, or new, standard.
4. Describes a new feature, a future direction is created, and the new feature will be considered in a future, or new, standard.

Rather than create a new dtd to resolve each error, issues requiring resolution would be collected and fixed in a new version of the dtd. Prior to release, each dtd will be tested and the test files saved. Testing will be completed by the Advisory Committee. Two tests will be completed, one that proves the test script fails in the old dtd, and one that proves the test script passes in the amended, new, dtd.

It was not resolved how to deal with an issue where a change to a dtd broke previous content.

Compliance

How do we define conformance? It was pointed out that the committee could waste quite a bit of energy trying to answer this question. If we instituted a policy in the specification defining conformance as coding to the latest versions of every dtd, content and/or playback producers conforming to the standard one day may not conform two days later. Instead, on the errata page of the web site, we could explain that changes will be made to the dtds, and advise all producers that best practice constitutes incorporating these changes in new productions.

Producers of DAISY books could indicate conformance to a specific version of each dtd.

Recommendations for using the standard

There are no tools available to create a 2005 DTBook. The first tool should be ready in about 9 months. Currently, a dtbook file may be used to produce a 2.02 DTB, by downtranslating to an xhtml file and using this as the starting point for the production. The problem will be migrating the end users from one format, one player, to another.

Items on agenda, but not covered

	Expanded documentation

	   - In 2002 release, we had a document to explain where and how elements could be used.
	   - What is the correct approach to provide this type of information?
	   - Can this be auto generated?