Minutes Z3986 Revision FTF September 2008
From zedwiki
Contents
|
Attendees
DAISY Advisory Committee Members:
- George Kerscher, Advisory Committee Chair – DAISY Consortium and Recording for the Blind & Dyslexic
- Ole Holst Andersen – The Danish National Library for the Blind
- Marisa DeMeglio – DAISY Consortium
- Linus Ericson – Swedish Library of Talking Books and Braille
- Reuben Firmin – Benetech
- Hiromitsu Fujimori – Shinano Kenshi Co., Ltd.
- Boris Goldowsky – Center for Applied Special Technology
- Markus Gylling – DAISY Consortium and Swedish Library of Talking Books and Braille
- Kenny Johar – Vision Australia
- Dominic Labbé – HumanWare
- Rob Longstaff – Royal National Institute of Blind People
- James Pritchett – Recording for the Blind & Dyslexic
- Lloyd Rasmussen – National Library Service for the Blind and Physically Handicapped
Participating Experts:
- John Brown - NLS
- John Brugge – Benetech
- Ian Greenow – Royal National Institute of Blind People
- Kathy Kahl – DAISY Consortium
- Bob Martinengo - AMAC Publisher Services
- Bob Norton - NLS Quality Assurance
- Sam Ogami - Cal State University
- T.V. Raman - Google
- Per Sennels - Huseby Resource Centre for the Vision Impaired in Norway (UK)
Day 1
Morning Scribe: Kathy Kahl
Introduction
Goals:
- Get everyone in sync and happy
- Get "cracking", i.e. elaboration of concepts in the inception phase
Status:
- After the Palo Alto meeting last April was that we all had a general idea of how the revision was going to go
- We are still in the inception phase, there may be other ways to approach this.
- Our initial focus in this revision will be the authoring and XML revision point of view.
- The NISO revision will be:
- Part A: an XML authoring framework for publishers and republishers, nothing to do with distribution
- Part B: The second part will be for distribution
- We will have to start working on these in series. We do not have enough manpower to approach in parallel. We may be able to start tomorrow to consider strawman approaches.
- GK: As we work towards the distribution side of things, we will be working with NISO to bring publishers in.
Roundup (Review)
Brief history of DAISY by GK Interpretation by MG
- DAISY has always been a distribution format, now orgs are using not as a distribution format but as an authoring for, i.e. NIMAS. Organizations have their DTBook files, 1) talking books 2) eBooks 3) braille. So now it is clear to disambiguate the XML grammars inthe DAISY Standard. DTBook does not work well as a distribution format, does not display tables, etc. It is limited. It was created in a time when the DAISY format was designed to capture the information of printed books only, now too tight. Organizations around the world now want to use it for magazines, TV listings. bank statements, etc. As anyone interested in the proper approach to XML. DTBooks as a distribution is sub-ultimate. There are other needs that are not met.
Key issue is that many of us are here today to participate since DAISY 2 and DAISY 3 have been enormously successful. It satisfies the needs of 90% of the use cases. At the same time we have 'scope creep'.
- Examples of 'scope creep'
- There are people who want to use DAISY in situations where players are not available.
- Work on light-weight profile
- Note: cannot get a DAISY player less than 3 figures (GBP). Note: NLS player will be $154 US.
- Levels of complexity, i.e. quiz taking situations
We are talking about profiles, including light, moderate, 'expensive', "classic" - i.e. satisfied with current capabilities.
Raman: Are there plans for network capability? GK: Kenny Johar is the project lead for DAISY Online. The DAISY Online protocol is currently not on track to be part of the NISO specification, but as a stand-alone specification, a proposed recommendation put forth this year. There is nothing preventing this group to look at this as part of the DAISY spec.
Discussion
Regarding the 3 Pillar Primer, what are the problems and issues? Approach with fundamentals of architectural design, to be modular. A profile is a concrete manifestation of a DAISY book. We have participated in the SMIL spec development for the past 8-10 years, and it now includes a DAISY profile. It is rich enough to encompass everything we would want to do in a DAISY book. Issues & Wishes in the authoring, distribution domain. Very high view of 3 pillars: compare the Zed review of 2002 which was a minor upgrade. It did not change the nature of the DAISY spec. Looking at the problem domain, it becomes obvious that the revision we are now embarking on is not a minor upgrade. It is a paradigm shift on how we design the future DAISY specifications. We need to tear down everything we knew and look with fresh eyes on the future.
Modular approach for the 2 pillars of authoring and distribution
With respect to the 2 pillars of authoring and distribution, the fundamental idea is that the idea of "statisticity" should go away. By leaving the monolithic approach which we have had so far, i.e. to provide a static set of functionalities, we should provide a framework, but it should not stop there.
- Open-endedness is the opposite of 'static'.
- It makes perfect sense for us to develop a framework where organizations can inject their own modules.
- Every authoring organization may have needs that fit into the spine. Any agency/org should be able to take this profile and author with it, still staying within the DAISY compliance spectrum. It should be perfectly transportable within agencies/organizations.
- Need to do the same with distribution.
What is the negative effect of an open-ended framework?
- An unrecognized construct is a problem. The behavior of a processing agent is dependent on knowing the structure of what it will encounter. Example: suddenly a Vision Australia NewsML structure appears in in my Pipeline?
Pillar #3 came into to enable Pillars 1 & 2
RDF - a machine readable capability to assist in discoverability.
- Should we engage in the RDF work, or perhaps another capability that is not so complicated?
- The XHTML role module was introduced 4 years ago. It is an entire process to decorate a structure with a role attribute which points to an entire RDF vocabulary, so you can build relationships to other objects, and inherit other behavior due to inheritance through the RDF framework.
- This doesn't mean that we apply this to everything. WAI has implemented it already.
Question: Is RDF the only option?
If thinking of other formats, such as NewsML, TEI, etc, what is the role of DTBook? Why do we need an authoring format if we are going to support any DTD out there. A: So this is the disambiguation aspect. We need at all times to remember what piller we are referring to. With respect to distribution, we should relax our constraints, i.e. our pillars. So could say that you can use anything but give us the CSS which is what OAB did. They were not interested so much in behavior as we are. MathML is a perfect example. So DTBook may dissolve.
Q: What if I use DocBook? Is that an authoring format? A: (MG) I don't think so. You do have to define roles. If you are a pure DocBook agency, then you can be a distributor only. If you want to interchange information, then you have to define roles.
Comments: (GK) We're not trying to have world dominance, but we do need to establish a set of elements that we want to behave in a certain way. From those we can build an RDF that has the semantics that we U. It also has to be understandable that we can add and remove elements. If a bird flies into our barn space, if it quacks like a duck, walks, swims like a duck, I'm going to treat it like a duck. So most of the roles in these systems are going to be incorporated into our vocab. I've also seen that in many publishers' vocabularies, they don't care about semantics.
Lloyd: It seems like someone along the chain should have the correct judgement to help create the roles, which is so hard to do with so many formats.
MG: Think 80/20, we should be able to supply 80% of the requirements. So for the 20% of special requirements, there should be a way to establish a module to satisfy the requirements. We don't want to impose complexity for the 80%, just for extensibility.
Marisa: DTBook should supply usability out of the box.
MG: There are many constructs in this world that have no parallel, such as MathML, and are not semantically equivalent. GK: For the well-known vocabularies, TEI and TEI-lite come to mind, we want to understand and map to their vocabularies. But for those that are established, we can should handle. MG: Is RDF going to be enough, should we be defining paragraph, sentence, word, or 'thing' with sub-navigable elements. Kenny: At VA we have several vocabularies from many publishers. We run through XSLT into an intermediary format and then produce. So how would the role ele fit? MG: For each arbitrary format, need not only a role but also a vocabulary. Kenny: So why wouldn't an XSLT definition suffice, if it maps one contract to another? MG: It would but it depends on the entire framework. Need the role element for the transformation process. So RDF becomes a giant translation table. JP: What is the role of RDF? Discussion: to map semantics into behavior and appearance.
Q: Can we reuse the ARIA role taxonomy? A: Not much since it is widget oriented. The WAI role taxonomy was based on a module taxonomy.
Lloyd: With only 1 year, role should not extend into the distribution format. Marisa: It already has, with the SMIL role element.
Boris: The capability of having a role definition in a distribution format and semantic behavior to implement that, that we never thought of, enables the standard to be extensible.
Per: How do you avoid things just becoming a big mash - someone creating what they need in Norway and some one else creating the same thing needed in Switzerland, not matching.
MG: If we create a registry and everyone enters their profile, then can enable reusability.
Marisa: The DAISY standard currently is essentially modular in nature, but not technically structured to be enabling. For example, currently you still need to have SMIL constructs for navigation with text-only books.
Ole: Is clever table navigation practical in an audio-only book? A: Possible but not practical.
Sam: Do we have a good idea of what the landscape is?
GK: No statistics, just gut feeling, and what is recommended out there. There's a big break between professional and leisure. At least for education, the text is very very important, and more important than the audio.
MG: We want to manage the community and open up to new domains, more business opportunities.
SO: Is providing these profiles, dependent on everyone being willing to share these things. Do we know how many orgs consider this intellectual property?
GK: This is the exact reason publishers would embrace this approach. They could keep their content in their prop format, and the distribution layer would allow them to publish in other ways. There may be information in their distribution format that they are not willing to reveal. There should be enough for them to distribute to have a reading agent understand what they do choose to expose. Or work same way,
MG: See the DAISY AF, which outlines, that you may need a spec imp to render, but this is where the fallback mechanism shows up as most significant.
GK: High-res graphics are going to be very popular with some publishers, as opposed to "no-res" graphics (George invented a new term?).
Summary (MG)
- We have reiterated through the 3 pillar outline, but is it the only one way to architectural address the concerns and issues that we have encountered?
- There may be other ways. After lunch, with the number of brains involved, let's put heads together and try to break this.
- The encouraging part is that we're not inventing anything new.
Afternoon Session Tuesday, 16 September, second session: 1:00 - 4:00 p.m. Scribe: Kenny
George: Markus, you wanted there to be a discussion on the feasibility of the three pillars approach.
Markus: a discussion on the alternative options would help.
Boris: if there are already vocabularies like docbook..... in the light of this three pillar approach, is there really a need for DTBook?
George: docbook was something we looked at, but was too rigid for our purposes. We looked at TEI too, and same was the case
Kenny: should we be talking about objectives and then trying to think about options that could achieve each of the objectives?
Rob: someone needs to do some work on the three pillars approach before it can be understood and accepted as a reliable approach.
Kenny: should we talk through some use cases?
Rob: lets walk through a newsml use case.
James: there are two dimensions to the 3 pillar approach: authoring and distribution.
Rob: I am concerned about not losing the multi-format discussion.
Boris: lets start with a task that involves all 3 pillars.
Marissa: to test the feasibility of these three pillars, we only need to conceptualize the 3 pillar approach.
Markus: RDF does not transform elements like XSLT.
Marissa: RDF should give you the reason behind the transformation that XSLT performs.
George: if you have a programmer that knows DTBook, RDF would provide a tutorial to this programmer on how the XSLT should be created to transform the XML vocabulary into DTBook.
Kenny: who would create the RDF?
Markus: there would be an RDF taxonomy for each module.
Kenny: would we be creating an RDF taxonomy for books?
Markus: yes.
Marissa: let's see if we can walk through some use cases.
Marissa: we want our NewsML unaware daisy player to be able to read through the newsml document.
Marissa: would the end output format have NewsML in it or would it be pure DTBook?
Markus: lets make the end output format XHTML.
George: knowing the fact that something in NewsML is an article is important. heading is a part of the sequence in a book, whereas article is self contained.
Boris: we don't have the semantic capability in DAISY that an article needs to be read before another article.
George: the navigation model we have could impose a structure on the HTML. For example, right now the navigation is imposed by the navigation file and not the actual HTML files in the DAISY publication.
James: suppose in NewsML I have a byline, when it gets rendered as XHTML the role could be byline which would allow a news reader to do special things with the byline.
George: the design science tool takes a MathML fragment and produces an image, and an audio version of the MathML fragment.
George: lets figure out the scope and start moving forward.
George: Many organizations want us to produce a new version of DTBook that could act as a single file format.
George: the problem is that people are trying to put different types of content into DAISY and it is not working right now.
James: if the player cannot understand something, you might like to say to the player don't play it. On other occasions there might be a fall back mechanism specified.
Boris: we could come up with a few things that might improve the reading experience on the player even if the player does not understand it for example, should the not understood item be a part of the table of contents...
Kenny: The role attribute module ontology also has inheritance rules incorporated in it.
George: let's talk about Markus's document.
Markus: I posted the link to this document to the ZedNext wiki. The first part of this document describes context. The second part outlines one approach that we could take. This could be a replacement for the DTBook format both in the authoring dimension and the distribution dimension. The proposed solution is that we drop DTBook as a host and adopt XHTML 2 instead. This does not mean that we adopt the entire XHTML 2 vocabulary. XHTML 2 is modularized. We should only pick up the modules that we require.
Markus: We would then inject modules into the XHTML 2 host module collection that we adopt for example a pagenum module.....We could have a collection of modules that give us for example enough semantics for a printed book. Different organizations might need different modules for their specific needs. DTBook as it stands today has 83 elements and 60 approximately are adopted from XHTML. We can now import modules rather than copying and pasting stuff from other vocabularies as was the case before.
Raman: another benefit from XHTML 2 adoption is that many different industries eg. mobile industry, publishing industry hold XHTML 2 as very important, and DAISY publications would benefit tremendously from this. Furthermore, the daisy consortium will not have to maintain elements in the XHTML 2 vocabulary.
George: how do people feel about traveling down the XHTML 2 route?
Everyone: yes.
Markus: Processing engines in the DAISY space must adhere to the must-process rule.
Raman: explicit markup is great, but implicit markup is very powerful because mistakes are fewer in implicit markup than explicit markup.
Raman: If something is not understood in the markup, the subtree of the not understood element should be ignored.
Raman: two classes of role values have been defined: first is ARIA and the other is what was initially in the role attribute module.
Raman: role attribute can be used in two ways: one to provide semantics to generic elements and two to provide cross-cutting concern for example, in the book hierarchy... pagenum might require a role attribute as it does not fit in the book hierarchy in a DOM tree sense. Marissa: we could use the role attribute for skippable elements. Raman: processing instructions could be roles for example, a table of contents might be expandable on the screen but does not appear in an expanded form in braille. Raman: use RDF as a modeling mechanism to aid understanding. RDF is way too complex to implement correctly. Markus: NVDL should be used to allow the integration of various namespaces in a schema language agnostic way. Markus: the Oxygen XML editor supports NVDL natively. Markus: we need to define the modules that we require in the spec. Kenny: So the next version of the DTBook vocabulary would contain a pre-defined set of xhtml2 modules and a pre-defined collection of DAISY-specific modules. Robert: People might have very specific tagsets and this architecture would give them a perfect opportunity to extend the next version of DTBook to encapsulate this tagset.
Second Afternoon Session Scribe: Rob
Strawman discussion continued
What does import into neutral base mean? it's about how to deal with changing needs of the community to faithfully represent print (e.g. page numbers are not in XHTML).
By having XHTML2 as default container, when you add some role additions, you need to be clear about namespaces.
With one source file to support multi-format outputs, would we need to need to have the same content tagged differently for different output formats - we should avoid this if possible, maybe have the different format needs written within the transforms rather then the semantic content? Use nesting rather than sibling approach?
What else do we need to consider for the braille output? What about braille graphics, e.g. a tactile graph? Can we use SVG - the SVG working group did put forward a recommendation but there has not been much response.
Can an SVG fragment be plugged into the new architecture and be discarded if it could not be understand (role cannot be used in this case).
we need to separate needs of authoring from that of distribution and although content should be the same the braille might need richer markup.
Would new vocabularies (eg medical info XML aka CMI) need a separate namespace? For content that is not in XHTML2 nor DAISY namespace it should be allowed to parse and we would deal with it at presentation stage. You should not make CMI a module of DAISY namespace as you would then have to start maintaining it. Maybe it's better thought of as a profile or part of a profile?
Use Drupal to manage content to avoid reinvention of wheels? We need to make sure that everyone knows what others are doing - communications issue rather than a DAISY technical issue. Open source methodology would help to facilitate this.
DAISY spec might be:
- collection of behavior rules when creating a document model.
- set of modules in DAISY namespace.
- interface to users.
How do we get manufacturers to render elements in a certain way? Market forces! (but this is the distribution part of the spec not the interchange).
Approval of new modules (eg CMI) might be related to NISO process or maybe approval can sit entirely within DAISY?
Day 2
Morning session, part 1, 9:00 AM - 10:30 Scribe: Boris
Recap & plans:
- we made fabulous progress yesterday - need to identify team to work on authoring & interchange format & RDF, who will be responsible for various profiles - need list of modules that would make up those profiles
next step: finish review of straw-man proposal
Wrapper/Container format for a DAISY fileset
- Desire to get something done quickly here; organizations have been using unstandardized methods - IDPF, ODF, OOXML all have container formats specified; all based on Zip format - OCF - Open Container Format - Downside: mp3 player with no DAISY knowledge would be unable to play - Need for encryption (at least for some parts) - Can a large archive be split into pieces (eg, to fit on several CDs)? Current spec does handle multi-CD books. DAISY 3 added important improvements in this area. The technology is moving toward larger disks, downloads, etc. - May need to re-think the multi-CD use case; current method can be confusing to users. May be more a question of player behavior & user education, but want to make sure spec is not recommending confusing behavior. - We can put out a draft standard for a piece of functionality like this, for test use, at any time - though vote by NISO will not be until at least year from now. - Can this container support old and future versions of DAISY - We will see if people are willing to commit time to researching this when we talk about resources tomorrow.
Tentative timeline:
- 6 months on authoring and interchange
- 6 months for distribution
- 3 months to review & revise authoring and interchange
- 3 months to review & revise distribution
James leads discussion on straw man Authoring & Interchange Format proposal. Yesterday we talked about... [bullet point 1] using XHTML2 as a base. [bullet point 2] We talked about adding DAISY modules for print book semantics to this.
[bullet point 3] We talked about other modules, eg consumer medical information (CMI)
- this would be in a separate namespace; you want a separate namespace whenever separate groups are developing vocabulary. - Implicit rule: do not re-create the same thing in multiple namespaces; use existing modules when possible. - We need to walk through the whole process to make sure that 3rd party profiles like CMI will work on all DAISY players.
We need to define our profile deliveries: more than just the DTBook profile.
- maybe Basic Book, Book Plus, something different - Newspaper? Magazine? Textbook? Journal? - these are the ones expected by our main constituencies; but we could go farther afield: tax forms & utility statements? - forms and workbooks will be difficult, but useful - part of requirements - emergency preparedness or textbooks which include video - a lot will depend on the resources we have to do the research and development
Document producers (and/or republishers) can extend the range of document types that the spec handles. 3rd party profiles can be published on DAISY website, but organizations may also want or need to keep them private. Adding richness to the authoring format does not prevent you from down-translating to a simpler syntax for specific purposes (e.g. braille production) - but braille producers may also want to implement new spec and work with RDF roles. Duxbury really wants to work more closely with XML DAISY files
[bullet point 4] There can also be modules whose purpose is not describing the source material, but addressing features of the desired output, e.g. visual presentation, auditory presentation, pronunciation lexicons for TTS engines (There is an XML grammar from W3C for pronunciation lexicons). If you are not shipping audio, but are expecting user agent to do TTS, then including some SSML markup may be useful. Similarly, incorporation of additional information for use in Braille production. Real world publishing often based on page layout tools; similarly, Word or Open Office save-as-daisy is based on visual layout. Desire to maintain this visual layout in DAISY book. Maintaining layout also useful for Dyslexic, LD users. All the output-based information may be more transient than input-based -- for example, pronunciation changes moving from UK to US.
[bullet point 5] Use the xhtml:role module for semantic mapping. Role useful for adding specific information to elements, also for mapping elements from other namespaces. Can there be a way to globally specify role rather than needing attribute on every instance? There doesn't seem to be an existing way to do that, we'd have to invent it - eg in SMIL, mechanisms were added to allow smaller elements to inherit parameters from containing elements Avoid RDF/XML - verbose, hides meaning - "an abomination" Is there another standardized way to express the ontology information other than RDF? OWL? - it's an extension of RDF for writing ontologies. Once we start to really list what we need, perhaps this will seem simpler. Could we just use the name of the mapped-to element as the role? eg <para role="p">
Math, CALS tables, specialized vocabularies will be interesting tests of the system we come up with. Do we pre-convert all external vocabularies? Or pass through and do conversion late? Discussion to be continued.
Presentation Charles Chen, T.V. Raman
Morning session, part 2 (11:15-Lunch) Scribe: James Pritchett
Subject: Understanding the entire chain of events leading to distribution formats
James walked through the workflow:
- Publisher provides content in one or both of two formats: in Zed (DAISY authoring/interchange format) or non-Zed (some other XML vocabulary, such as DocBook).
- Producer transforms these (if necessary) to DAISY interchange format. This can now be sent to any republisher, etc.
- Distributor (could be same entity as Producer or different) takes DAISY interchange format and converts to one or more DAISY distribution formats.
- User agent takes distribution format content and:
a) renders to user b) exposes navigation to user (both built-in DAISY navigation concepts and, optionally, special content-specific navigation, such as math equation navigation) c) possibly exposes semantic information to user (?)
MG: Role of xhtml:role in authoring process. Example: Vision Australia gets totally predictable input content. Under this condition, they can ignore xhtml:role and hard-code everything. RDF is not needed here. But if given to TPB, TPB needs RDF to understand how to map VA's files to it's production process.
Hence, authoring-interchange format needs an ontology expressed as RDF.
On the other hand, a totally different ontology required for distribution format to support user agent behaviors (rendering, navigation, semantics). In a multimedia distribution profile, for example, this could be provided in SMIL. James presented example of a newsml "newsItem" element. In the DAISY interchange NewsML profile, this would have an xhtml:role attribute mapping this to something known -- e.g., xhtml:section. In the distribution format, the news item may have an xhtml:role of "escapable", since the republisher wants to allow the user to escape from articles when they get bored by them. These two xhtml:role uses are unrelated to one another, and the decision to apply the "escapable" role to the distribution format is made by the republisher, not the content author (although we could allow this, too).
Fallbacks are part of this as well -- e.g., include NewsML in one profile, with fallback to plain xhtml version for players that don't understand NewsML. Do we do fallbacks within a profile (e.g., inline, via xhtml object), or between profiles (e.g., in distinfo or package file)? Or both? Both are needed, and both must be generic, so that players can handle unknown profiles.
Distribution ontology should be extendable. This allows players to implement new functionality and producers to create content that activates that functionality.
Distribution level fallbacks: Distinfo identifies multiple profile flavors of same book. User/user agent selects most appropriate profile and renders. These point to package files.
Package level fallbacks: each item (media object) in package identifies fallbacks. This is a way of defining fallbacks for larger chunks of content. This is complicated to implement, and perhaps less desirable. Inline fallbacks: Within content, provide parallel equivalent versions of content. User agent chooses most appropriate to render.
Interchange and distribution ontologies are completely separate, can be developed by separate teams "in separate rooms".
Marisa: @xhtml:role allowed on elements in SMIL DAISY profile already. However, ontology for @xhtml:role was not defined (pushed off onto this committee).
George: Concern about the complexity of the spec. Needs to be simple enough to be implemented. Markus: From distribution format, should make things easier. For authoring format, we may need to provide supports (e.g., helps to get over problems with compound (multi-namespace) document editing).
1:30 pm - 3:00 pm, Scribe: Marisa DeMeglio
Present: George Kerscher, Kathy Kahl, Linus Ericsson, Boris Goldowsky, Per Sennels, Sam Ogami, John Brugge, Hiromitsu Fujimori, Reuben Firmin, Ole Holst Anderson, Rob Longstaff, Ian Greenow, Robert Martinengo, Lloyd Rasmussen, John Brown, Bob Norton, James Pritchett, Marisa DeMeglio (scribe), Dominic Labbé, T.V. Raman (for part), Kenny Johar, Markus Gylling
GK: Concerned by complexity of what we've been discussing. Good news is that we have more ready-made tools to work with than during previous spec revisions; however, we still need to make sure that our spec is implementable.
RF: Will it be too confusing for users to have to know that their player supports A, B, and not C?
MG: If we wrap everything into a single file format, the ugly details will be obfuscated
OHA: The single or multiple file set isn't the issue -- a CD could also be a sort of container
RL: Would it help users to know the capabilities of various systems?
MG: Is this a spec issue?
GK: Overlap with DAISY OK -- knowing what players play books correctly
OHA: This is related to how we define profiles
GK: Use profiles to help publishers sell their products everywhere -- audiobooks, ebooks, daisy books
GK: Back to original question: Are we building something that's going to work? Is it a too-heavy hammer for our task?
DL: If we have too many options (profiles/flavors), there will be too much confusion and we won't reach/serve who we need to
MG: One core requirement is that we have package-level fallback. All books will be shipped with a basic playable version, but that version might not have all the features of the more complex profiles
MD: Since we are talking about variations in source text, it's easy to see the chain of fallbacks -- if the schema is supported, then your player has more features, but at least, we can access the textual information from any player.
DL: We will need to manage all the options we provide, so let's choose our set of options/profiles carefully. A simple example is how confused people get about skippability -- some players support it, some don't; some producers use it, some don't.
RM: What falls in the scope of informative guidelines -- spec text for player behavior?
LR: In the beginning, we decided that players could be competitive, and we didn't specify player behavior
GK: DAISY OK addresses some of this
MD: In SMIL, we assumed that the DAISY-Next spec, which will use the SMIL DAISY Profile, would include informative text about player behavior.
SO: The book should expose what navigation options it contains.
MD: Don't we know this now?
DL: We don't know about how deeply tables are marked up.
BG: Spec could state what some of the errors should be. Eg. if user tries to go to the next page in a book with no pages, what is the prescribed behavior?
GK: Distribution profile mechanism -- axis 1 has structural features (math, tables, pages, etc); axis 2 has media types (audio, text, mixed).
MD: We can hide the complexity -- start with a full-text/full-audio book with mathml, and derive automatically six profiles: full w math, audio only w math (note to self: what would this look like? it doesn't quite make sense.), text only w math, full + xhtml, audio only, text only
GK: As a consumer, I want to know -- does this book have TTS? does it have human narration? is it a text-only ebook?
LR: Is anyone doing full-text, full-audio with human narration?
Group: Not very many people.
KJ: Do we need profiles? If we expect the user to have to decide what their player/software supports, then do we need to wrap things up as profiles too?
OHA: In the past, we've been talking about profiles like DAISY Light, DAISY Classic, DAISY Pro
BG: Maybe profiles aren't directly usable/understandable by consumers
GK: Is "profile" the wrong term to use on the distribution side?
T.V. Raman just joined.
TVR: It sounds like you're overloading the term "profile". "Profile" usually means a collection of XML modules. Maybe something like "level" or "flavor" is more appropriate.
TVR: Do you plan to define the media types allowed?
GK: We will probably have a list of supported codecs.
TVR: Suggest not to use "profile" to define player capabilities; instead, use it to talk about the XML modules involved in the authoring process.
KJ: "Lightweight" could mean "no SMIL"
MG: We should ask player manufacturers how we can make their lives easier.
DL: Offering different ways to see the same content -- light, medium, heavy -- could help. For example, a cheap player could use this to choose what version of the book to play.
MD: We shouldn't get bogged down with the idea of profiles or capability levels right now. Let's make a chart of distribution target features, and decide what to call it all later.
RM: Devices or providers could use metadata discovery to expose what features are available. This is being used now in the industry (scribe: sorry, forgot which industry)
GK: Good to know other industries are grappling with this.
GK: Can the authoring and interchange working group proceed without the distribution details?
MG: There is very little interconnect between the two areas.
PS: Can we be sure that what we create will be playable?
GK: We can move forward briskly with the authoring and interchange standard for draft use.
BG: This will require that we make some assumptions about what software tools will be able to deal with. E.g., what would video look like in an authoring format?
JP: The advantage of a modular authoring format is that we don't necessarily have to worry about all this right now.
GK: We have a list of requirements about what to include (e.g. forms)
JP quoting MG: "We'll have to specify: the framework (how to pull together a profile); the DTBook namespace, one or more profiles"; let's add examples to this list.
OHA: I don't think you need profiles on the authoring/interchange side.
MD: The word "profile" is just a convenient way of referring to a set of modules and how they interact.
GK: "Profile" is an easily-digestible way of describing what a publication contains. Good for using in discussions with publishers and other accessibility law-abiding organizations
GK: This work will be best done by small working groups.
We all talk about braille some more.
GK: Braille is a first-class citizen of our work. Need to integrate it harmoniously into our framework.
OHA: However, braille-related things are not part of what we need to do.
MG: Braille-output-formatting modules are not part of our specification. However, a document model rich enough to produce good Braille is part of our task.
September 17th Afternoon Part 2 Scribe: Reuben
- George - trying to identify who is going to move forward with the work is the next thing to decide
- Authoring and Interchange work should proceed
- Markus will lead
- NISO process review
- Small group will be doing core work
- Next step - Put together a list to do the work for Authoring & Interchange format
- Target of the work is a "draft standard for test use"
- Subject to change
- Once it goes through NISO voting process, it will be nailed down
- The actual schemas are not part of the standard, so if things need to change they can without a revote
- i.e. the standard "points to" the DTDs
Parallel Working Groups/Research Committees
- Some work can be done in parallel, but some is serial (i.e. same brains should work on both major formats)
- Can be done in parallel to A&I format:
Codecs, Feature set of lightweight audio format
Audio fileset - what does it look like? What is the minimum feature set?
Look at various formats - CEA, IPod, Audible - can we coexist with them?
E.g. if all that's needed is the M3U from the CEA spec (subset of NCX), that's a good solution
Player must remember where it left off
If it's easy to implement and addresses the features from the other formats, we should see the adoption of our lightweight format
Fixed bit codec was used in CEA to make it easier to figure out where the reader is.
Lightweight Audio Research Committee
Who: Dominic (lead contact), Lloyd, Hiro, Colin Garnham (RNIB - 20% between now and end of March), Marc-André Hébert
- Tasks of lightweight group (recap)
- Define minimal feature set for lightweight audio DAISY format
- Give examples of how the fileset would look
Needs to be done by the time the Distribution format work starts, i.e. 6 month time frame This will end up being on the distribution working group.
Codec Research Committee
Same people as "lightweight" Research Committee What codecs are required? Possibles: AMR, WAV, MP3, Ogg Vorbis, SPX, WMA. Any existing with some acceptance should be included Considerations:
- If I'm a hardware manufacturer, I want a small list of codecs
- How much cost does it add to include AMR? (for example)
- Proprietary vs open source
- Why develop an extensible format, but narrow down what's acceptable?
- It should be at least reviewed to ensure good player support / feasibility
- Valuable to legislate this in the spec
- Licensing fees are a definite consideration
- Could say that an unencumbered code is preferred
- If producer still uses MP3 anyway, then that's between the library, the device vendor, and the user
- MP3 will be supported anyway - it's pervasive
- DVD industry has only 4 codecs; should aim for minimalism
- What about video codecs?
- Distribution profiles define what codecs they allow within that profile
- Codecs is an area of technology with frequent change, makes sense to allow extensibility to prevent obsoletion of spec
- E.g. VoiceAge and Fraunhauffer at work on new MPEG
Recap:
- Do we specify codec, yes or no?
- At what level do we specify codec? Profile vs universe of DAISY formats
- Review list of candidates; match to potential profiles
- Image and video formats should be also discussed
- Make sure IP policy is considered
- As well as open source / freeness
- AMIS is a good example - we need to be able to distribute it free
Container Research Committee
- Who: Reuben (lead), Dominic, Lloyd, John, Hiro, Nick Williamson
- Multiple existing standards that are known
- IDPF vs OASIS
- ODF and OOXML
- Adobe initiative to move IDPF into ISO process
- Do analysis of benefits
- Where would it be used? Which formats? (Lightweight vs ebook vs multimedia vs professional)
- Is it only a transfer format? Or native playback format?
- Is it suitable for streaming?
- Is progressive playback possible?
- Relevance to DAISY Online work
- IDPF format was identified as being suitable for streaming
- Issues associated with where the data on size is written in the container? (Do you need to get to the end to figure out how big it is?) Etc
Authoring and Interchange Format Working Group
- Aggressive schedule
- 6 months for deliverables, i.e. end of March
- Lead: Markus
- Minimizing face to face requirements is good, would still be a need for solid face to face meetings
- RDF / Ontology / Use/Not-use
- Yes for both pillars, but differing ontologies
- Conference calls and time commitments?
- 1/2 an hour a week is not enough
- Who & time commitments
- Markus (lead)
- Kenny - 10%
- Ole - 10%
- Marissa - 40-50% starting November, 0-20% until then
- Stephen Phippin (RNIB) - 5-10% in November and December
- Per Sennels - 10%-20%
- Boris - 10%
- Matt Garrish from CNIB - TBD
- James and Linus will snipe at the work from the sidelines
- NISO wants to use their lists and their webspace
- Kathy & George will work out logistics
- An accessible wiki is an obvious requirement for the entire process
- 24 hour access to person w/ passwords/configuration is a requirement
- Kathy & George will work out logistics
- When will work kickoff?
- End of day today
- Locations - Toronto, Boston, NY, Stockholm, Copenhagen, Peterborough, Australia
- Subgroups could meet based on geography?
- European branch and North American branch
- Is it doable?
- About 1000 man hours dedicated
- Actual output is about 60% of that given parallel
- "Distinct possibility"
- A lot of the names we have put to requirements already exist
- About 1000 man hours dedicated
- Possibility that we pick up somebody from outside the process
- Need for a "tech writer"?
Wrap up
Day 3
Morning Scribe: Lloyd
Four groups have been formed, the objective is to come up with work plans: (First 3 are in research mode)
- Codec Research Committee
- Container Research Committee
- Requirements for low-complexity audio profile Research Committee
- Authoring & Interchange Format Working Group (officially constituted)
The meeting broke up into parts corresponding to Research and Authoring.
Reconvened at 11:10 AM.
George has a document with questions that need to be answered with help from NISO.
Change in name of standard? Bifurcate it? Name for the A/I working group? Unofficially might be the ZedAI Knights.
Overview of Architecture / Interchange (AI) work plan:
Deliverables: Framework, several modules consisting of schemas and their descriptions, profiles. Also there may be instance documents to be used in a test suite. Nice-to-have: additions to the Pipeline to build new profiles, DTDs, validation tools, migration tools.
May be providing three ready-made profiles: book, book pro or book+, periodicals profile.
There was some discussion with GK about which profiles they intend to do. EPUB might be a target format for ZedNext.
EPUB was demonstrated being played by alpha software on a Victor Stream, unprotected book.
End of October: one profile and an instance of a document, RDF ontology, define scope of the next iteration. Exercise all of the relevant technologies early.
With some of this tech work out of the way, prose can be worked on toward the end of the period, with March 31 as a deadline for the last iteration; it may be the fourth. (See their document on the wiki.) JP and MG gave most of this report.
Questions about resolving namespace information; may use RDDL as part of that solution. This should be resolvable by end of March also.
Meeting frequency: teleconferences weekly or twice per week, total of 3 hours/week. Focus on virtualized meetings. Maybe one or two F2F meetings. Time commitments preclude more than this. What will NISO say about time commitments for additional participants?
At end of each iteration, the whole extended working group will have a chance to review the results. Process to create these will also be transparent.
Schema language has not been decided; by using NVDL, the process is schema-agnostic and will depend on which developers create what.
First telecon and more definite schedule after NISO conversation. Probably will do their telecons on Monday mornings. 1300 UTC. Probably start Sept. 22.
Delivery Group
Research Committees: Audio codec and lightweight format in one group, container in another.
Codecs: Identify criteria and other characteristics, including IPP.
November 1 identify criteria and codecs; Nov and Dec to rank them and start building consensus. Name codecs that should be dropped. Contact people involved with standards we reference. Criteria include VBR, open-source, level of compression/quality, will probably display some of the criteria in a comparison chart.
Need to estimate commitment needed when distribution committee starts up.
Telecon schedule has been tentatively set.
Lightweight profile/format: More complex than codec work. Review existing lightweight formats for audio books and material. Describe functionality that needs to be in this profile. Sample file sets. We might define more than one level of this profile. A recommended audio codec, likely to be MP3.
Probably need two months to review the existing profiles, then after that begin developing file sets and test them on a wide range of players.
Container: Analysis and description of requirements for first milestone in about two months. Review and compare existing standards in third and fourth months. Also look at existing DAISY containers. Months 5 and 6 provide a straw man proposal.
Active Groups
Authoring & Interchange Working Group
Codec Research Committee
Container Research Committee
Lightweight Audio Research Committee
Adjourned at 12:09 P.M.
References
Drupal both for platform and framework model
RDF
- RDF Data Access Use Cases and Requirements
- Resource Description Framework - non-authoritative
- Sample RDF/XSLT Application
- RDFa: a light-weight profile of RDF.
