Notes from Zed Face-to-face February 7-9 2007 Copenhagen
These are the notes from the F2F. Each portion identifies the scribe.
Wednesday February 7. Morning, Julien scribe
Z committee meeting, February 7th-9th 2007 DBB, Copenhagen, Denmark Participants: Ole Holst Andersen, Thomas Kjellberg Christensen, Romain Deltour, Marisa DeMeglio, Linus Ericson, Boris Goldowsky, Markus Gylling, George Kerscher, Dominique Labbé, Rob Longstaff, Pete Osborne, Diana Hiorth Persson, James Pritchett, Julien Quint Scribe: Julien * Goals of this meeting? Where we are, what we may need to do with the spec. Who else do we need to get involved? Need to have a roadmap. Markus talks about community requirements from other reading disabilities than blindness (e.g. dyslexia) Technology is already way ahead of implementation, so implementation should be driving the next round of development [James and Peter] George thinks that the mistake is that we don't have authoring and reading systems coming out at the same time as the spec. NISO says we can publish "betas" of the spec easily for implementations to be built. Implementations should come from different places. What is in scope for the standard, and what is outside, but related? Also, what are the problems and use cases from places where implementations will come from? Are pathological books (DBB's big dictionary, TV schedules?) getting better with the Z standard? Laust is creating a big book to see how it plays. Do we have a problem with scaling, with large documents like dictionaries? Dominique points out that users want cheap players but the spec is complex. DAISY OK work is trying to capture that and needs sample content [George]. Timeframe for technical development research: finalize some research by November for the Techshare Conference in the UK; prototyping is also necessary. We need a plan identifying problems (and when/how they can be solved) by that time, informed by the needs of host organizations. This may lead to a non-monolithic spec, or sets of guidelines. NISO says there is a trend to break large specifications into smaller pieces, e.g. addressing navigation, DTBook element set, online delivery? This is already happening with DTBook and package file being specified separately. Create a strawman set of prioritized issues to bounce off the community. If we are on the verge on creating a new spec, we need to review our process. E.g. why hasn't the Z spec been implemented enough? [Markus] Look at resources [George]. * Analysis Where are we? George: when we came out with DAISY 2.0(2) we had incredible adoption of the spec, basic but met the needs of lots of people, but is hurting us because people don't feel the need to upgrade, what do they gain from the cost? Same experience from DBB, RFB&D, RNIB... Effective recording tools can drive adoption but large organizations will have migration problems. Peter estimates 200-250,000 DAISY players out, compared to 100,000 JAWS; this is the most successful accessibility technology. Updating the players in the field can be a good step, but costly as well (hard to have a cheap DAISY 2.02 *and* Z player) whereas users want cheap players. Trend to abandon DAISY and use the CAA spec, or MP3 files with metadata? MP3 books can be obtained from DAISY books (e.g. as done by DBB: labeled MP3+, RFB&D calls it audio+, also known as DAISY-) Is Z lacking backward compatibility? Hardware players are an issue. Multi-format DAISY players need to be clever, whereas MP3 players can be stupid and just play audio, discarding all the rest. Multiformat media (MP3, NCC and NCX) easy to do automatically from Z books. DBB distributes books for keeps; so every 2.02 book that goes out adds to the problem as people want to keep playing them. Why does an organization want to go to Z? DBB or TPB use it internally, then downgrade. George sees text-centric vs. audio-centric: if you're just audio/leisure person, 2.02 is just fine. Most books are audio books at this time. Lots of people convert their analog books to digital. What implementation problems are there? In hardware players, it is a matter of adding more memory, i.e. more cost, to implement more features. In software there is a marginal difference. New codecs are a big problem (e.g. ACC) for hardware players; multiplying codecs will limit low-end players - see if NLS using wide-band AMAR(?). How to subset the current spec? Implementers can support a specific profile of the spec. Differentiate between features (e.g. a Z-basic profile similar to DAISY 2.02 versus full profile) and required codecs/media. Simple players can discard extra info, but if the codec is not there, nothing plays. Will the spec drive people, or the tools? Both. The spec will be the defense. How many organizations have explored the deficiencies of the products? Are end users complaining? In the US, people want ASCII text so that they can do whatever they want. Thomas: younger people want text and audio, for searching for instance. Users coming from ebook lending systems who like highly marked-up content. RFB&D needs to create books quickly for schools. Hardware players still outsell software players despite cost. Process must be as simple as possible. RNIB: no complaints. In Japan [NRCD] lack of Japanese support (ruby, vertical text); need for complex layout to replicate print books for LD readers. Demographics of readers: traditionally seen as elderly, but including dyslexia bring a larger audience (used to have old ladies, but also young boys in DBB.) In US, more learning disabilities than other print disabilities (less diseases, better LD diagnostics.) Images: images referenced in SMIL vs. embedded in DTBook or HTML. Should be one or the other but not both; going the SMIL way needs better support for layout. Two tracks: better multimedia, or PDF-like to replicate pages from print books. 2D-synchronization vs. word synchronization in PDF+Flash (Texthelp from Ireland.) Humanware is working on something in that direction? Support for PDF in the format (e.g. from Jim Fruchterman) User groups want to convert Powerpoint presentations (basically animated images + audio), symbol languages, comic strip books, etc. Sometimes conflicting requirements from visually impaired and LD; e.g. PDF good for LD but bad for blind users. DAISY could be thought as an intermediate format, but not what gets to the player; rich markup gets converted down. Hard for CD (physical media) based players as people want the disc to play straight away; online distribution can better accommodate server or player-side transformations. Spec can mandate a fallback format (e.g. when the spec mandates a new codec) but books may get bigger. Bigger issue: how to render something that looks like a print book, PDF like. See what users want, and technology will come later. A factor to consider is technologies with wide adoption, e.g. mobile phones implement SVG or wide band AMAR. Issues at different stages: layout not quite ready for spec writing; scalability or online delivery more so; modularization also serves an immediate need (embedding Z in other specs; backward compatibility.) Embrace backward compatibility because of the success of DAISY 2.02. Possible problem is confusion between different profiles. Addition to the list: special kinds of contents like dictionaries, maths, TV guides, transport timetables... more conditionality (several speeds = SMIL switching), language training, interactivity workbooks, testing. After lunch: online.
Wednesday afternoon Marisa scribe
Jan 7, 2007 Afternoon minutes == Topic: Online issues RNIB has been working with organizations who are about to kick off trials of streaming and downloading. Issue: how do players interact with services? Plextalk gets access to the book via simple hyperlinks RFBD, Humanware have other approaches A protocol is required for consistency. The goal is to have 1000 users on wireless players by the end of 2007 Humanware has been working on some trials in New Zealand Users are leisure (non-tech) readers, working without a computer Trials with a prototype were very successful The machine was a PDA inside a victor reader classic interface with internet connectivity. The protocol should not be proprietary. The trial used FTP with small packets of XML data exchange (with the book and library cards in XML). At DBB, there is some interest in using digital video broadcast being used to download magazines. A perennial topic at board meetings is to have a working group on online services. A starting point will be the work done already, like what NZ is trying. The PDTB spec was designed with online services in mind, although it doesn't specify a specific web service. However, the security issues have been thought out by the WG and keys and authentication procedures should work over the internet. The ability to exchange content across countries should not be ignored when we talk about online protocols. Messages between a player and service: buffering, authenticating, user profiles (what kind of books I like). There are both business and core technology needs. We are interested in finding out which basic steps are common across DAISY book providers so that these services can be provided and built on to suit specific organizations. We should investigate about if core technology needs can be built on existing industry approaches, such has how to download or stream SMIL content (which needs to be done as a layer on top of existing content without modifying the book). Who has the resources to staff a working group on online services? Which organizations are interested in moving forward right away? CNIB, RNIB, New Zealand, Humanware have all been discussing this, so maybe they are candidates for a working group? Parts of the approaches used with PDTBs could be tightly integrated with online services: no matter what, you're going to want to identify the patron. Although, DRM and identification should be separate, whether on paper or conceptually, because we will want to identify users in many cases where DRM cannot be used. Topic: What, if any, are the compelling reasons for a new DTB spec? Here are a few: 1. Break up large files (DTBook, NCX) into smaller ones 2. Nicer handling of modular extensions 3. Incorporate video 4. To improve script support 5. Fix our image problems (where DTBook and SMIL overlap in referencing images but each has its own rendering behavior). 6. We could appeal to commercial publishers who want to distribute multimedia books alongside the print copy. There are concerns about whether we have the resources to support another specification revision. The more organizations who are moving in a certain direction already, the easier it is to find resources. But who needs this stuff now? Will we place too much of a burden on existing tools if we revise the spec? No, we think that if we modularize, then the current DAISY/NISO 2005 can be expressed as a sum of its modules, and the content looks the same. Refactoring (modularizing) of our spec could accommodate current tools and also make a clearer path by which we can add new things. Also, interactions between our spec and others are made much easier by modularization. Topic: Who else is interested? IDPF uses DTBook. It was a new model for them (they had been using HTML). They also liked NCX. How do we appeal to more organizations? For example, commercial ebook publishers. They need to do all sorts of books, including scientific, novels, embedded video, etc. In our technical directions research, we need to find out who to bring into the discussions. At its beginning, DAISY was created to replace audio cassette books, and the implementers were well-defined. Now, it could be that the publishing industry represents the next set of implementers. Users' needs aren't covered 100% by libraries (even just in the amount of material available). However, publishers need to be brought along quite a bit regarding technology and process before they are prepared to talk about this. Existing audio publishing: some MP3, some DRM, downloads will be more popular than CDs. Navigation is atrocious (11-hour audio file, or bad iPod navigation). A whole other area is testing. Although they are not the primary administrators, libraries have some experience producing tests (DAISY, large print, Braille). Interactivity is lacking so far. One of the main publishers of student literature in Sweden is quite open to producing books in DAISY, but they really want the layout to match the print book (the issues are: several different fonts - not all free, text flowing around images, background images on every page). The production has been quite a long process, starting with PDF and ending with hand-editing in XML Spy. InDesign is another tool they use, which seems to have removed or limited their XML export. Presentation about SMIL by Marisa. Here is a summary: start SMIL presentation As a significant producer of SMIL content, the DAISY community has valuable input into the SMIL standard. This continues with SMIL 3. SMIL continues to be important for us because it is an open, mainstream standard. This offers opportunity for interoperability among devices and tools which support SMIL (mobile phones, free software players). An example of this is AMIS-Ambulant, where an existing full SMIL player has been embedded into a DAISY player. Our goals for being in the SMIL working group are: a. we want to improve SMIL's accessibility b. we want to make it easier to incorporate interactivity and rich multimedia into DAISY Changes in the SMIL language that support DAISY: === 1. addition of "access" and "role" attributes in the SMIL Linking module for representing device key mapping and semantic information, respectively. 2. XPointer for referring to external text without requiring that the external document be covered with prior markup (such as IDs on every synch point) 3. Media parameters can work on a whole region (see later how this is very useful to us) 4. Label attribute added to the metainformation module (point to a piece of SMIL to use as the label) 5. Metadata can be used in the body (see later how this is very good for us) We have created a DAISY profile within the SMIL specification. It specifies which modules to use and how to use their features to represent a DAISY book. Here is what it gives us: === Specific features: 1. Next/previous document-linking using metadata in the head 2. Metadata on elements in the body to show that media belongs to the same "channel" 3. Our own "namespace" for our events (daisy:) and param names 4. Specific param names for conveying rendering instructions, for example, to apply highlight styles. 5. Targeting specialized renderers using a combination of custom test and param 6. Our profile is fully SMIL-compliant We get more useful features simply by including more modules (part of being SMIL compliant): 1. excl time container (good for interspersing audio descriptions) 2. switch element (good for content control) 3. basic layout (solves interoperability problems seen now with DAISY documents being played in mainstream players; also, layout should be used properly for specifying what to do with images) 4. video as a media type Some new interesting things overall in SMIL, which are still being fleshed out: === 1. DOM and State 2. SMILtext For the group to consider === Our profile needs to pre-define a basic set param values. Our profile needs in-depth review of its examples (when available) end SMIL presentation Just for completeness, here are some SMIL links that should go along with the notes from my presentation yesterday (they are the same ones I've sent out before): a. The SMIL 3 working draft: http://www.w3.org/TR/2006/WD-SMIL3-20061220/ b. The DAISY profile: http://www.w3.org/TR/2006/WD-SMIL3-20061220/smil-daisy-profile.html
Thursday Morning Feb 8, Rob scribe
8th February 2007 (Thursday morning) DAISY Technical Conference ========== Pre meeting discussion: Need modularization of specification in order to reflect differing needs of differing communities, producers + player manufacturers. Brief discussion of the need to include librarians + publishers re ISBN/metadata. Do different accessible outputs need different ISBN? - what impact does this have on metadata needs? ========== NISO discussion: GK: Conference call with NISO revealed that they had lost copy of NLS documentation, they only have PDF of the spec. - they do not have copy of by-laws - they accept most of the responsibility for this.. NISO think current process is too closed and needs to be more transparent The following was agreed: 1. A letter of understanding between NISO and DAISY as the maintenance agency is needed, part of which needs to describe processes. They were informed about modular extension, braille work + SVG work and want such work in future to be announced more openly. 2. A document which describes the committee formalities is also needed. A template can be supplied for letter of understanding. PO/GK volunteered to work on draft (GK also volunteered Kathy). GK wants more formal committment to committee process/documentation. Current set reflects 4 people appointed via DAISY and 4 via NLS - Tom McClaughlin (NISO rep) has since quit as has Michael Moody so there are currently 2 spaces to be filled. NISO is not comfortable with the current setup/processes. TC thinks more consistency is needed. MD wants a better mechanism for external input - GK stated there has been criticism in the past re lack of external involvement/openness. JP asks if 9 voting members + x number of invited experts is the correct amount? GK has asked if W3C was appropriate to manage book standards but this was not thought to be the best way - they think NISO is better placed. PO suggests 9 voting members (with a quorum of 5) + up to 6 invited experts , with a limit of 2 members per organisation with 2 year terms. After much discussion, it was agreed that voting members could be between 9 and 15 with no distinction between members and invited experts. Any vacancies will be announced to NISO and committee will consider applicants. JP: what do we start with and how - do we start with what we've got? [nb Current website info might be incorrect]. PO's proposal is that Dave Pawson will be withdrawn from committee as he does not have the ability to commit resources from RNIB and proposes RL as he does - this was accepted. GK thanks Dave Pawson for his valued work in the past. MG says it is important to keep channel open with SMIL. Round the table on who will be included as of now: JP, MG, RL, GK, TC, Ole, LE, MD, Neil and/or Lloyd from NLS. GK says it is important that there are a few open seats when this is presented to NISO. Chair responsibilities: meeting agendas, tie breaking vote, minutes, overseeing of agreed process, elections. JP: chair needs life term, how does he resign? GK voted by committee as interim chair pending official (post NISO participation announcement) vote. Transparency of process with the ability to have closed meetings is important. Reaffirmation of committment from organisations is needed for committee members. GK: maintenance of existing spec (as opposed to working on new specs)- can this be handled by sub-committee? Boris: sub-committee to email any resolutions to bigger group monthly with time limit for comment? Sub-group agreed as Ole, JP, Linus, GK, Lynn Leith + Kathy/Laurie. GK: math working group is in final stages of spec announcement. NISO are to allow fast track, trial spec approach in order to accommodate parallel development of tools etc. Do we need to define process within DAISY, especially to satisfy NISO perception of openness? MG: this is not a new spec, nor is it standards but rather a leveration/note for a particular type of content. This DAISY process needs to be defined more clearly in future and currently needs an additional statement about comments received/addressed. ========== How do we get best out of resources/general discussion: TC: how do we resource new spec work etc (DTbook developments, audio/visual/image reqs (maybe to profile work?), ncx, bookmarks, distribution) JP: how do we get new requirements (from externals) into group? GK: where does SMIL 3 sit? MD: we could bring this in as a module. DL: don't forget that you lose phrase navigation if you consider moving from SMIL to ncx because there is only one medium. GK: Word level syncing/SMIL question. Julian: doesn't believe that this should be done. MG: who wants this? - users? publishers? Maybe more possible using TTS but human voice feels impossible. DL reported seven hours work to achieve one hour output with human voice/word level syncing. Boris to look at CAST research. DL can provide some research information if contacted. GK: is it spec work and investigative work that is now needed? MD: layout is an issue. ========== That's all folks. Peter Osborne adds in email: For info, with reference to multimedia presentation, independent television commission standards for audio description (UK), even referenced by US broadcasters as most authoritative at present. Pete
Thursday, 8 Feb 2007, Afternoon: James scribe:
Process for
moving towards next release of standard
Mostly my rough notes on the rather free-ranging discussion of the afternoon – James P.
GK: Next release of standard; part the "dissection" of spec, part the reference to other specs (e.g., SMIL). Need to wait for SMIL 3 to come out – end of this year (?).
MG: In order to do the dissection, we need to know what the new features, contexts will be.
JP: Seems reasonable to do requirements-gathering and re-engineering of spec in parallel
MG: Has sketch of work already! Some things already agreed upon – e.g., Dtbook not flexible enough to handle islands of new grammars. Most of work is already done – SMIL profile, IDPF package file, etc. May not be that much work. Dtbook is probably where the bulk of the work lies.
GK: Make it a generic parent book document? Include other stuff by reference (e.g., XHTML tables).
MG: Other consequences to compoundedness – e.g., what does reading system do when confronted with grammar it doesn't understand, etc.
JP: Process:
Analysis of parts
Refactoring
Profile mechanism described
MG: This could be one deliverable, but not endpoint – a beta/test release of spec prior to adding new features for full release.
JP/MG: Requirements gathering for new features goes on in parallel with spec refactoring. After spec is refactored (with identical features to 2005), new features designed, implemented, etc.
GK: Problem with announcing a new spec: people no longer port to 2005 because new spec is in development. Are we just developing for the sake of developing?
MG: Does "release" mean spec release, and authoring tools, and validation tools, etc. (sample implementations)
DL: Need to do something that people will use.
JQ: Need implementers on the committee who implement while spec is in draft.
MDM: Modularization of spec could mean modularization of software tools, can be shared, etc. Makes spec friendlier to developers.
MG: Looks like we are abandoning DAISY 2.02, which is the bulk of the work that is going on in the world. It's a socio-economic problem – rich libraries can implement the new spec, others cannot. Currently the whole world on a single standard (2.02); don't want to lose that. Rich countries at an advantage because they can write their own tools.
TKC: Supporting new spec not an authoring tool problem, but a playback system problem – expensive burden on players and/or users.
GK: Two profiles – one for lightweight (cheap) players, one for full-featured.
DL: Or playback system could choose which profile to use depending on size & complexity of book (e.g., for "middle weight" player, if too much data, revert to lightweight navigation).
MG: Create free tool to package all these different versions of book on a single distribution medium. No longer a spec issue, but a tool issue.
[Discussion of multi-format medium handling issues]
[JP: Presentation on CEA spec. My talking points notes inserted here:]
CEA audiobook specification (CEA-2003-C)
Built upon OSTA's MPV (MusicPhotoVideo) standard.
MPV is just a fancy XML playlist format. Designed to provide a common, rich playlist format for DVD players, digital cameras, PVRs, etc. A way to structure consumer-created and consumer-organized content such as photos, recorded video programs, ripped music, etc.
For info on MPV, see their website: www.osta.org/mpv. There's a white paper that explains this well.
The Audiobook standard implements something close to an NCX in the MPV format as a series of nested sequences. The MPV format playlist combines the functionality of NCX and SMIL into a single file, making it easier to use in a limited-resource player (?).
Should be possible to transform a Zed book to the CEA-MPV playlist format. In fact the spec itself references a DAISY activity to produce a tool to do this (p. 53).
To take full advantage of the audiobook profile for MPV, a device needs to be "Audiobook compatible" and carry the CEA logo. There do not appear to be that many devices that conform to this specification at this time, nor are there many vendors providing content in this format (SoulMate, Brilliance Audio)
GK: Should we be working with Apple, other manufacturers to implement something simple that we could target?
JP: Correct, CEA spec is not the answer.
MG: This was part of charter for the DAISY Pipeline – to create multiformat books. Need to get back to this.
Action item: DAISY Pipeline geeks to take remind themselves about this.
GK: This undermines the DAISY standard?
GK: To drive down player costs, bring the player manufacturers together to make our standard compatible with them, show path up to DAISY.
Tech directions:
Profiling
Refactor spec to support this and other new functions
New "lightweight" profile
Board wants strategic roadmap that coordinates with our technical one.
JP: Needs to be 2-way street: Board needs to provide input to committee to guide technical work as well.
BG: Profiles are compatible with each other; doesn't require major revisions to go from simple to complex.
JQ: Text-only profile, too. Make strawman profiles to validate the deconstruction of the spec into building blocks.
MDM: Linking & bookmarking need to work across all different levels of complexity.
TKC: [Distributed his medical handbook (big monster book)]
GK: Are pathological book problems solved? Group thinks so, either through best practices for existing books (e.g., SMIL file sizes) or through new modularization.
MG: For each spec module, scalability should be addressed.
GK: For technical directions, need input from:
lightweight player people (Apple, Audible, etc.)
Disability research community for new feature requests
E-book space
JP: Two profiles are ways of infiltrating mainstream space – lightweight profile for audio players/content providers, text-only profile for e-book players/content providers. They can't/won't support current spec because it is monolithic and huge. Modularized spec with limited profiles lower barrier to participation and adoption.
GK: Who do we go to get participation in multimedia development? NRCD, WGBH, other disability research community orgs
[More discussion of video, captioning, descriptions, etc.]
Realize that this committee doesn't have the experience for video; needs to be a module designed and implemented by people who do know. Modularization of spec makes that possible.
GK: Do we change the name to "Digital Accessible Information System" spec? I.e., not just books. Or "Digital Accessible Information"? "Digital Accessible Publication"?
Summary
To summarize:
Two parallel tracks
Modularization of existing spec to support profiles. Includes full profile (equivalent to Z39.86-2005), audio/featherweight profile, text-only profile; support for fallbacks, scalability
Gathering of requirements for next version of Zed spec. Focus on wider range of disability groups and publication types.
Compound Document Format (CDF)
* Compound Document Formats
+ XML makes it easy to mix documents through hyperlinking (by reference) or namespaces
(by inclusion)
+ Classic example: XHTML+SVG
+ How are the graphics rendered inside a page?
+ What happens with events or user interaction?
* CDF Documents
+ Compound Documents by Reference Framework gives very generic guidelines
for referencing, DOM, etc.
- Web Integration Compound Document (WICD specification) describes XHTML
+ CSS + scalable graphics, e.g. SVG. Three layers (Core, Mobile, Full) building from CDRF.
1. Core: root XHTML document, references to SVG documents for still
images, but also audio, video; hyperlinking, focus handling
(navigation inside the document), synchronization support, etc.
2. Mobile: requires XHTML Basic 1.1, ECMA Script 3rd edition compact
profile, CSS Mobile Profile 2.0, SVG Tiny 1.2, DOM mobile stuff, XmlHttpRequest.
3. Full: builds on Mobile; supports XHTML 1.1, ECMA Script 3rd ed., CSS 2.1, DOM.
+ CDI framework in the works.
* DAISY as a compound document framework
+ Mix XHTML, SMIL, and DAISY-specific markup
+ Spec defines behavior like CDF
+ What happens when SVG gets thrown in there? MathML?
* What we get from CDF
+ Solves lots of issues for us and illustrates some that may come up
+ Building a profile could help in specifying future DAISY versions
- Building several profiles, like WICD
+ CDF implementations means easier DAISY implementations (see SMIL)
* What we can contribute to CDF
+ Accessibility focus
+ More SMIL and less XHTML
+ If we have a successful DAISY profile, provide another strong user base
(see SMIL advantages.)
Julien
Friday Morning Diana scribe
Protocol from Zed meeting Friday morning 2007-02-09 (9-12) ========================================================== Note taker: Diana Hiorth Persson Decoder discussion ------------------ For the future specification we need to review what codecs we should include. It is important that we keep the number of codecs to the minimum and only include realistic options that will be used. MP3 is a given one, although MP3 files might be too large in some cases. AMR was put forward as a suggestion. It should give the same quality as MP3 using half the bitrate. The licensing cost is agreeable as well. (http://www.voiceage.com/) AAC that is included in the current specification should be removed at the next update because no one is using it. All parties must be informed about this. Before we decide what codecs to include we need to evaluate e.g. Speex. FYI, the DVD "consortium" has decided to only support 4 codecs: PCM, DTS, MPEG L2, Dolby AC3. ACTION ITEM: Dominic Labbé will lead this research topic. RNIB will participate. Text discussion --------------- How do we get the text into our format? The publishing world is very PDF oriented. Since the law about making all text available for the accessibility area the publishers have been working against us rather then with us. Is DTBook the right format to demand from publishers. Is the name wrong? Too rich? Rich enough? ACTION ITEM: DAISY need to make more effort to show best-practices how to create DTBook from other formats. More training sessions. Decide the agenda for the rest of the day ----------------------------------------- * New requirements (90 min) * Modularisation of the specification (how, roadmap, who) (120 min) * Communication (60 min) New requirements ---------------- What are the requirements for the next generation of DAISY/NISO for the LD, cognitive impaired, dyslectics etc.? What can we do between now and November (next meeting)? We tried to define different people and groups to talk with to get their requirements. ACTION ITEMS: Marisa and Julian - Contact AIST, NCRD to find out their requirements George - Contact LDI in Philadelphia to find out their requirements Dominic - Contact Brenda (Humanware) to find out requirements Boris - Find out what research organisations in US that can be of help. George - Contact the organisations found by Boris Markus - Contact research organisations in Sweden Peter - Ask someone at RNIB to find out what organisations in UK that could be of interest Outreach to organizations regarding participation on different profiles Peter - Contact AES (Audio profile) George - Contact Audiable, Apple/IPod, APA, CEA (Audio profile) Julian - Contact Vodaphone (Featherweight audio publication profile) George - Bookshare, Idpf, DocBook, Google + competitors, Gutenburg, ODF, Safari, Microsoft, Adobe (E-text profile) George - WGBH (Video profile) Julian - Hiroshi (Video profile) How do we approach these organisations in a way so that they can give us the information we need? * Find the right person within the organisation * Interview rather than sending an email * Ask specific questions like: * How should the book look? * How should it work? * How do you want to interact with it? * How can DAISY help? * Show with sample content ** end of morning session **
Sent by Peter about the Online Delivery
(If you are not at the meeting, ignore) An example of the kind of thing I think it would be helpful to give to George to communicate to the DAISY board. Play with the words of course... We agreed to create a working group around the development of online service delivery and the possible development of a solutions/agnostic protocol governing how playback solutions interact with those services. The approach will differentiate aspects that may be included in a protocol from organisation/specific business rules. The aim is to deliver a presentation in this area around the Techshare meeting in the UK, November 2007. Pete Osborne (RNIB) will facilitate the group and a call for participation will be issued by end February 2007.
Friday afternoon, Ole scribe
Minutes Friday Afternoon Session: Modularization discussion MD: Create a RDF role hierarchy from dtbook. Julien+Daniel+Marisa do SMIL related module MG: The specification currently is segmented, modules would probably be the same. Have someone do a strawman modularization of the current spec. After this each module is assigned to people. There should be a single editor responsible for each module. Look at other specifications that are modular for an example of how to modularize Zed. JQ: SMIL is a good candidate We need to be careful not make the modules incompatible, there needs to be intercommunication between module groups. Should we have a single modular specification or multiple specifications? MD: Having multiple independent specifications will make life easier for implementers. Will also make it easier for other standards to reuse our work. Solution: - Have standalone documents describing each module. - Have profile documents describing inter module dependencies in addition to specifying rules/constraints for the used modules. We should start by splitting spec. into modules/sub modules. Then use the modules to create the three pre-specified profiles (full zed, flyweight audio, text-only) After this we meet and discuss the feasibility of the architecture. Should there be a master editor of the entire specification? Should we have a fixed formal grammar for writing the new specification? This will help us testing conformance of implementations. W3C and OASIS have grammars that we could possibly use. WIKIs could also be usable during spec. development. We currently have three sources of information for every module: 1. The spec. prose 2. The DTD 3. Comments in the DTD
Process (as captured by JP):
1. Define working group (small; no more than 5-7?) 2. Work out overall architecture: a. Division of whole into parts b. Define profiling mechanism 3. Analyse spec pieces to see: a. Whether division of whole into parts works b. Whether profiles can be constructed from these parts 4. Collate analyses and revise architecture as needed [repeat 3 and 4 as needed] 5. Write individual parts 6. Write profile assembly spec 7. Write profiles 8. Prepare sample content Who should/can do the work: We should communicate to the world that the modularization/profiling process is the technical directions of the specification. Since we are not adding any major new features to the spec. the modularization process is not interesting to the outside world. The outside world would be more interesting in the requirements gathering discussed in the forenoon session. Action item: GK will ask NISO what the procedures for working groups are regarding release of alpha and beta specification drafts Volunteers for spec. working group are: Markus Romain (Markus and Romain has limited availability in the spring of 2007) Ole Julien Marisa James Dominic Milestone 1: Step 1 is now finished Milestone 2: Steps 2-4 should be finished by the next NISO meeting in October 1-3 2007 in London (Before TechShare) Milestone 3: Steps 5-8 should be finished at some point in 2008 - beta release (MG suggests March 2008). Milestone 4: Beta of new spec. including new requirements in the beginning of 2009. Milestone 5: Next spec. release by the end of 2009. We should have simultaneous release of tools supporting Z39.86-2009 at this time. Remark: Milestones 1-3 include only the three predefined profiles (full-zed, fly, text-only) The primary obligation of this group is to meet the requirements of the users, hence the gathering user requirements should precede the gathering of requirements from manufacturers/publishers. How can we convince the DAISY board and other sponsoring organizations that the new technical direction is the most efficient route to take? Resources for the reorganisation of the standard are limited, the people needed for this work have other obligations and can not spend all or even half their time on spec work. GK has problems with the fact that Z39.86 has not been widely implemented and with the fact that DAISY at present has to recommend using Daisy 2.02. Session: Communication Milestones defined in the previous session are a useful part of the communication. * Analysis of the success of Daisy 2.02 - The success of Daisy 2.02 is partly responsible for the lack of Z39.86 implementation * Analysis of the weaknesses and problems in implementing Z39.86-2002 and 2005: - One issue is the handling of large books - scalability - We need technical guidelines on how to use the spec. in a sensible way - Graphical presentation - Lack of support for other disablilty groups - Lack of on-line protocols Since the specification in the future will have to support multiple disability groups we see a need for modulizing the speecification. A two-page document describing the above points needs to be produced. GK will do this. Also a new implementation roadmap for DAISY members.
Version 3