Minutes: 110909 Morning

From zedwiki

Jump to: navigation, search

Contents

Monday Morning – Notes

Agenda and top level achievements/goals

3 overarching targets:

  1. Finalize the design goals page on the wiki – experiment that encapsulates implementation directives (clear imperative statements about things we must achieve in the spec.) Produce a contract for ourselves. Many of the goals are simple, with no side effects or risks; others are far more complicated. Two major levels:
    1. Evolutionary goals – fixes and/or enhancements to existing spec
    2. Revolutionary goals –
      1. Profiles – since last year’s meetings at Google and Bookshare, we have established the hypothesis that the spec will use distribution profiles. We have no formal decision on this, so we may revert if we need to.
      2. Generic fallback mechanism – we want to preserve player compatibility.
      3. Video support
      4. Interactivity support – aka “forms”

We will split into three groups for today to iterate on these design goals.

  1. Produce at least one straw man outline of the standard. Based on the design goals page we can attempt to produce a logical model of the zed dist spec. There are two “cannon fodder” wiki pages which can be starting points.
    We will also review (day 2) relation to other specifications. Political and technical ingredients. HTML5, EPUB, SMIL3, TTML (time text markup language).
    We may produce two or three that oppose each other. Preference to come out of meeting with a top contender that is as concrete as we can make it; we can add things to it that we are not really sure of, in the interest of being comprehensive. e.g. audio codecs – list candidates for the sake of things to snipe at.
    Q – when do we need to come up with draft spec? May – June 2010. We probably need a 30 day comment period + 30 days to revise, so April 2010. We are at the moment 3 months behind the schedule, because of other events/specifications. We need a fallback plan in case we don’t hit our target. NISO may be lenient in timelines. (6 month period after?) NISO process will date it when it’s approved; it will probably take 3 months for them to vote, after we submit for approval. It will probably be 2011 before it is finalized.
  2. Thursday – last day – we will produce a plan based on the resources available to come up with a draft standard.


Design Goals Finalization

  • In terms of interactivity and video, there are numerous features that may be added to the spec. Where do we draw the line in terms of what to add as native features?
  • Interactivity has been narrowed down into several categories, and should be further narrowed today. Video is somewhat easier.
  • DAISY 3 / 2005 – static, finalized specification. Document types are defined, as are the logical relations between them. There was one extension point built into the specification, in the text grammar, which allowed foreign grammars to be hooked on (e.g. MathML.) That notion is something we are likely to have in DAISY 4; still open as to how it is done. There is a solution for it in Zed AI: features, which is essentially the concept of plugins that can be injected into document instances. We may built upon this same mechanism.
  • So, this is good to keep in mind in terms of interactivity, in that we can continue to develop features as plugins even after the initial specification has been finalized. So the important thing is to make sure that the foundation is flexible enough to build upon.
  • So to be pragmatic, the initial forms feature could be quite concrete and tangible, e.g. educational testing.

Review of Design Goals Wiki Page

These are taken from requirements analysis in 2008, google and bookshare meetings from last year. This page restates the problems and desire for change for each. (See wiki page for details)

  • Evolutionary targets
    • Text Media – Better Support For Visual Styling
      • DTBook’s support for visual styling is very poor. Essential to solve for sighted and/or dyslexic users.
      • Why should every playback engine have to do XSL transform to render as HTML? Want to allow cheap implementation of players.
      • If we move towards HTML, we should impose additional restrictions on the structure etc, so as to avoid the risk of inflexible/poor semantics.
    • Text Media – Flexible Semantics / Vocabularies
      • We have very poor semantics if we adopt HTML straight off. HTML does not support <note>, <sidebar> etc.
      • We should allow flexibility beyond the book.
    • Text Media – Dynamic Extensibility with Generalized Fallback
      • Ability to extend with new types – XML islands – MathML, MusicML, etc.
    • Text Media – Varying Structural Rigidity
      • We all love DTBook, but it imposes a high cost on producing content. This excludes massive amounts of content from being DAISYified.
      • This does not mean saying goodbye to a structured document, but it gives producers the flexibity to decide.
      • We need to make it easier to make books.
      • We might provide two or three DTDs as options.
    • Audio Media – Extended Codec Support
      • Extend or modify the optional audio codecs.
    • DTB Fileset – A Single Container
      • OCF container as primary contender.
    • DTB Fileset – Multiple Textual Content Files
    • DTB Fileset – Machine Readable Semantics
      • Decorating arbitrary element with statement of roles
      • HTML5 does not support extensibility in the role attribute. I.e. locked to ARIA.
        • Will HTML5 support additional attributes, e.g. daisyrole? Yes, if you use “data-”, i.e. data-daisyrole. Or, if you use XHTML5, then we can.
          • The problem of using XHTML5 is that we may miss out on compatibility with NG browsers.
    • DTB Fileset – Ruby Support
    • DTB Fileset – Modularization of NCX
      • Set of modules and composition rules – to allow specialized adaptations to be used in varying contexts.
      • Terseness is an issue; NCX can become huge. Memory is an issue in EPUB readers; having 8MB NCX is not helpful.
    • Update of SMIL to 3.0
      • Will help with interactivity.
      • Action item – Marisa will expand this entry.
    • Generalized Bookmarking and Annotations Support
      • If this portion of the specification can be reused by other standards, it has potential for wider adoption.
      • Action item – clarify design goals to define “generalized”.
  • Revolutionary Targets
    • Profiles
      • The core problem is that DAISY is expanding in terms of who wants to use it, where and how.
      • One fileset cannot capture all use cases, at least efficiently.
      • A large population wants rich navigation + audio.
      • Text only users.
      • Expansion into interactivity, video.
      • Allows tool implementors to focus on niche aspects of the standard.
      • Action item – add risks to this section.
    • Generic Fallback Mechanism
      • A universal fallback mechanism for all distribution profiles.
      • One distribution unit should be able to work in a given device.
      • DAISY community will not be well served by being fragmented. We want to maintain universality.
    • Interactivity
      • What do we mean by interactivity?
        • Forms content for tests, quizzes, orders or taxes.
        • Mathematics – e.g. if you are working with an equation. Maybe you want to do some operation on it, e.g. move something between sides, solve sub-sections, etc. (Sounds like Mathematica?) Seems like a candidate for extension.
        • Input of data – support of forms implies acceptance of input in the same form that it was rendered – e.g. sign language. Should interactivity be accessible only in one direction? How are we going to accept and store data from users?
        • Annotations – in the same way that you can collect form submissions, maybe you want to be able to subscribe to other people’s annotations.
        • Build your own list of structural items in the book; share those.
        • Animations or “gizmos” within a book. Seems like too much for specification, but how do we allow for extension point to provide this?
        • Where does DAISY interactivity end and alternatives be the better solution? (E.g. the web.)
        • Should you be able to insert DAISY as embedded content into web documents, or similar?
        • Q – would it be better from an architectural point of view to treat the DAISY book as a resource, where the behavior is applied by the client? I.e. provide a well defined interface to it that can be used as a resource (e.g. DOM).
        • Q – SMIL state, should this be exposed for programmatic operation?
        • Q – what do we know that our educational communities need?
          • Accessible testing systems (forms) – usually a “biological interface” provides this in schools today
            • Being done today e.g. in workbooks that accompany NIMAC textbooks
          • Pragmatically, that may be in
    • Video Support
      • Common misconception that we are trying to reinvent the wheel.
      • Instead we are trying to add new features that are not currently available.
      • E.g. sign language
        • In sign language, we have the sign language by the signer, plus the text.
      • In the general sense, accessible motion pictures are text captions, e.g. subtitling.
      • Structure and navigation, and synthesizing multiple content – DAISY is very good at this.
      • Use cases:
        • Disaster preparedness / emergency training. Want something as accessible as possible for presenting this information, not just islands of multimedia within the context of a text document. They are targeting a broad variety of users – end users in Japan, for example, include “how do you evacuate a hospital?” This content would be applicable for training.
        • Autism – video is particularly good for education.
        • Traditional captioning and audio descriptions – there are much better tools available on the web, but it’s something we can easily available.
      • 3 main general cases
        • Video as master.
        • Sign language as master.
        • Islands of video interspersed within the main document. Reading flow might pop up a video within the context. Particularly good for education fields.
      • Q – do people read the text and then look at the sign language? You have to choose; it’s possible to play at the same time, but hard to look at both at the same time.
      • Q – does it help to teach the reading of text with sign language, so that people can become more proficient at reading text? Yes, that can be a use case. There are various use cases, such as enhancing reading, or enhancing sign language skills, or as a navigational tool.
      • Indexing and searching is a use case here.

Q – is DRM in scope for spec? PDTB2 should meet requirements here. It is generic enough that we should be able to wrap anything in it. There is a lot of interest in taking that spec and moving it into the mainstream.

Q – does EPUB currently support PDTB2? No, there is nothing inter-operable in the EPUB space.

Should there be support for different encryption schemes for different kinds of media within a given document?

3 groups will form after the break. Need to tighten up “video support” and “interactivity support” goals on the page.

Retrieved from "http://www.daisy.org/zw/Minutes:_110909_Morning"
Personal tools