Minutes – Z39.86 Advisory Committee Conference Call

Attendees

Advisory Committee:

• George Kerscher, Advisory Committee Chair – DAISY Consortium and Recording for the Blind & Dyslexic
• James Pritchett – Recording for the Blind & Dyslexic
• Lloyd Rasmussen – National Library Service for the Blind and Physically Handicapped
• Dave Pawson – Royal National Institute of the Blind
• Neil Bernstein – National Library Service for the Blind and Physically Handicapped
• Linus Ericson, Swedish Library of Talking Books and Braille
• Marisa DeMeglio – DAISY for All Project
• Laurie Sherve, Scribe – DAISY Consortium

Participating Experts:

• Chris Wilder-Smith – CAST
• Neil Soiffer – Design Science
• Dominic Labbé – HumanWare

Apologies:

• Markus Gylling – DAISY Consortium and Swedish Library of Talking Books and Braille
• Ole Holst Andersen – The Danish National Library for the Blind
• Thomas Kjellberg Christensen – Danish Library for the Blind
• Mark Hakkinen, Daisy For All Project

Agenda

• The agenda was distributed to the Advisory Committee's list on 2006 February 28. There were no amendments in advance of the call.
• Linus found an error in the DTBook DTD. He submitted the error as in issue, "idref attribute of noteref and annoref is CDATA". See http://www.daisy.org/z3986/issues/issues_detail.php?ZedIssuesId=102 for the complete issue description.

Confirmation of Date and Time for Next Call

GK proposed that the next call be held on 2006 April 5.

Oasis Working Group

Dave Pawson has joined the Oasis working group and is working on converting a simple file to a DAISY format. Lloyd felt that he should join this working group, and George should monitor it.

MathML Extension

George reported on his discussion last week with Markus and James regarding the MathML extension. The working group is struggling with the MathML Extension, and attempting to use the smil <customTest> attribute. Markus felt that this solution was a little more than a "hack" at solving problems and that the MathML extension should utilize the current version of the specification.

The DTBook extension mechanism originally brought in additional structure, and for the MathML extension there would be "islands" of math structure in DTBook. The smil file would point to these "islands". A MathML "aware" player would see the <par> attribute for the math island and provide an alternative rendering for the Math. An unaware system could render all items, and not show the MathML image. Two stylesheets would be needed, one for Math ML aware player, and one for Math ML unaware player.

This approach would create a foundation for a robust extensibility mechanism of the spec. It could also be used for other extensions of DTBook, such as poetry or drama.

Markus sent an example of this approach to extensions to James and George who will revise and then distribute to the Zed Committee. Lloyd requested that the example provide enough complexity to illustrate the approach and must include both inline and block level tags, with text around both.

There are also problems with the <showin> attribute. It has been requested for many purposes such as braille, large print, and different formatting. Marissa felt that the next version of smil would incorporate many of these things. Dave pointed out that lots of additional information was needed for braille rendering including markup, metadata, a full diagram description, or braille translator, and didn't think that smil alone would be sufficient.

Lloyd felt that the purpose of the standard should be made clear as now it tries to represent both text books and multimedia presentations. The original thought was that stylesheets would be written for different purposes, but not much has been done in the way of stylesheets.

Should MathMl be represented as a block or inline element? The specification allows both. There is nothing to stop a author from writing 40 lines of mathml inline. Dave thought that we should not allow matrices inline, but Neil noted that small matrices were authored inline. The discussion was tabled as too low level to discuss in this forum.

A tag in the metadata could be used to alert players that the book contains math.

However, a dumb player cannot render the math, the best would be a braille translation of alt text. If there is a braille display in the player, MathML can be translated into braille.

Interestingly, the smil DTD does not contain an alt text in the image element, so there is no place for descriptive text for mathematics. However, the smil spec does contain alt text for an image. Not everything was brought over to the 2005 spec.

George brought up another problem - if you skip the image, an audio player will still play happily. However, if the player is for text only refreshable braille display, it will skip the entire content and that is a concern.

This could be solved by adding a required <prodnote> for dumb players. Currently, the user can turn the prodnote on and off.

Issues and Opportunities for the Future of Daisy

Items in this section are part of an email submitted by Dave to the Committee prior to the meeting. Not all these items were addressed on the telecon.

1. Alternative media output:
   • daisy dtb.
   • Braille.
   • Large print.
   Are we serious about this? Is there a pull for it? Who from and what do they want? How is it being used, with what MMI? What AT?
2. Players.
   • Types or classes of players.
   • Viable when minimal spec per class is considered.
   • Battery or portable.
   • Full PC capability.
   • Minimal PC capability.
   • Net connected or not?
   • Fast or slow connection.
   What minimal expectations can we derive directly from the spec? Annoyances include multi-disc books. Should be a part of the spec, and from which we can derive DAISY OK testing. User interaction should be included in these requirements. There will be gray areas which we can debate with player manufacturers.
3. Extensions.
   depends on player capability.
4. Where is the book I'm reading?
   • Online, Fully.
   • Online, streamed as per BBC radio.
   • Offline, downloaded, then played.
   What are the implications on the spec? E.g. links to online content.
5. Wider uses, looser spec.
   • E.g. Podcasting, reading newspaper, magazine etc.
   • Listening to mp3 music tracks. How are players being used?
6. Do producers have migration plans? What users are planning a move to Daisy 2005, if any? Should this group be concerned if there are none?
7. Can we put timescales on a next iteration? What is the point of a version n+1 if it's not being used? What expectations should we have for migration?
8. Where is the spec weak? E.g. areas the spec doesn't cover that users and producers are asking about, and we don't cover; what areas might we extend into that is currently outside the spec.
9. Sub daisy. Something like a minimal daisy spec, as perceived by Greg or the Australians; basically a smil player for navigable audio, that could be picked up by mainstream. Links nicely with mainstream products capable of playing 'sub daisy' material. Key point for promotion.
10. Licensing. Are we shooting ourselves in the foot with licensing?

Items on agenda, but not covered

	  Discussion about the need for a technical directions summit.
		 

Items identified for next meeting

	  An update on the Structure Guidelines/Documentation of the semantics of DTBook
	  An update on the DTBook issues resolution