Z3986 Maintenance Committee Agenda, Palo Alto April 15-17 2008
From zedwiki
Action Items
DAY ONE, Tuesday April 15
This day is about creating a general overview of the requirements gathering, analyzing the data to see if we have critical mass to warrant a revision process. It is also about understanding how we will interact with NISO during the revision.
- 09:00-09:15 Administrative matters [George]
- Attendees:
- George Kerscher, Advisory Committee Chair – DAISY Consortium and Recording for the Blind & Dyslexic
- Ole Holst Andersen – The Danish National Library for the Blind
- Neil Bernstein – National Library Service for the Blind and Physically Handicapped
- Thomas Kjellberg Christensen – The Danish National Library for the Blind
- Marisa DeMeglio – DAISY for All Project
- Linus Ericson – Swedish Library of Talking Books and Braille
- Markus Gylling – DAISY Consortium and Swedish Library of Talking Books and Braille
- Kathy Kahl – DAISY Consortium
- Dominic Labbé – HumanWare
- Rob Longstaff – Royal National Institute of Blind People (RNIB)
- Peter Osborn – Royal National Institute of Blind People (RNIB)
- James Pritchett - Recording for the Blind & Dyslexic
- Lloyd Rasmussen – National Library Service for the Blind and Physically Handicapped
- Jennifer Sutton – DAISY Consortium
- Invited Experts:
- Attendees:
- Karen Wetzel
- Apologies:
- Boris Goldowsky – CAST
- Karen Wetzel described her role at NISO as Standards Manager
- Minutes will be taken by different committee members for the 6 half-days of the meeting
- 09:15-10:15 Requirements Gathering: General Review, Outcomes [Jennifer, Markus]
Markus: 2 documents:
Review what we decided at TechShare
James, Jennifer, and Neil were not there. We had a rationale for moving towards a public requirements gathering.
- we want to solicit general input from the community.
- DAISY is now used for other groups than original intent. Is DAISY really to be used by the dyslexic community, so time to look at these new needs.
- GK: At original inception of DAISY, dyslexia was considered but we had very little input
- MD: Now people have something to look at, to respond to
There were choices of methodology re requirements gathering, either:
- Force people to individually enter requirements on a Web site (the choice we made)
- Collect user stories - hard to do without an expert sitting at your side
Current Status
We now have a collection, no legal status, no obligation to consider everything, need to analyze what we can do and cannot do
GK: we do need to formally respond to the submitter.
KW: There are some formal requirements for interaction with the community (tobe detailed later). At some time you do have to feature freeze what you are considering. We are not at that point now.
So, what do we want to do?
- What do you do with requirements and turn them into something usable?
- KW: IEEE 39.98 is recommendation on how to create a Software Requirements Specification (SRS):
"An SRS is a complete description of the behavior of the system that is to be developed..." They have a template, IEEE is about software, not about a standard, so some similarities and differences. A complete SRS describes all of the interactions that the user will have with the system. We don't need to do that. What we're doing is a revision to the system, very costly, very useful. Can we afford it? We could focus only on the changes in the system with this revision.
JP: In our cases, what is the system? The spec could be the system.
JS: Some of the requirements seem like they can be done, others should be done, but don't know how.
TC: A standard is a set of rules with which you design a system. Need to stay in the helicopter but design some road maps.
JP: Where is our focal point, some reqs are high level, some are digging in the garden. We should not be limiting.
JS: Examples need to be careful, not saying this is the only way. Structure Guidelines are examples. It's about opening doors, i.e. a req for UML, we don't need to build UML constructs. Users don't think at the high level, we need to.
TC: Cannot be too open, else too expensive, to implement a player. The spec should also limit the behavior.
GK: The biggest competition is the drop-dead stupid imp, such as MP3 play lists. Hopefully we could have something easy to implement and to build on.
So, one point is to leave the monolithic approach that we've had and look at building blocks.
We don't want to approach a real SRS, but have one document that either includes just the changes, or start elaborating with the user story approach, which is more costly. We need this not just for us, but for others in the community, the DAISY Board, some kind of communicable instrument as the basis for moving forward. With user stories we can show concretely what can be done with the spec when we are done, describe the new interactions that are allowed with modifications to the spec.
TC: But this is marketing, need to separate
GK: This is needed with respect to NISO processes as well. The Contents and Collections Comm. has to review the need for moving forward.
KW: The general information community is the audience; they need to see what the revision entails. ANSI requires that any revision be completed within one year, extension for two years, from the point when approved by vote. Technology reasons for not extending longer are relevant.
JP: What if DTBook became part of another development, such as a profile, not part of the Zed spec. How high is your helicopter supposed to be.
MD: I'm coming from the player perspective, a viewpoint of predictability.
GK: There could be more people added as resources. The scope of this revision is something that our community needs to approve.
JS: The scope of this revision as a business case may entice other parties to be involved.
KW: What kind of resources are you looking at? Yes, human resources. Any organization that has a stake in the standard would want to commit human resources.
What now? Need to decide what kind of document do we need now? Most outside organizations want to know what the EFFECT would be on their organization. There are many that are still on DAISY 2.02 because the effect of DAISY 3 was not beneficial enough.
GK: When we started , there was nothing, so there was complete buy-in. With our next standard, there will be 2 standards to compete with.
TC: If we fight among 3 standards, I cannot come up with a business case, both from usability and production. Needs to be a win-win situation.
GK: Am envisioning marching forward, allowing others to join on the side in the original direction. e.g. a light-weight profile would allow more in.
TC: If not immediately usable, libraries would need to write-off. Therefore needs to be a very good business case.
MG: Do we think we have a business case? Parallel production - the ability to produce braille, large-print, etc. If can can input that's usable in a fast way.
GK: So we want to be able to take garbage in, and ... Everybody wants the magic bullet.
TC: Maybe it's not magic, but it could be green...
LR: You look at all these organizations and wonder who's going to produce all this?
JP: Suppose we target those who want to do really motivated cool stuff, like with math?
JS: What is target say 5 areas - what libraries want to do...?
GK: This whole WYSIWYG area is something. They are taking all this visual presentation information and transforming it down. We need to make something that appeals to publishers. Libraries really don't want to have to produce the material themselves.
TC: We need to provide the business case:
- Pub be able to produce the content very cheaply
- Pub want to be able to control the visual presentation.
They have created a certain look and feel. We need to be able to support that visual presentation. We need to be able to automatically stream it out to different channels.
JP: list
- new product features
- streamline new content production
- remove barriers for acquisition from publishers
- preserve visual presentation
- cheap players
- allow other communities and producers to come on board, joining on the side to go in same direction
(huge, critical, vast market segments)
Good cheap and fast is a business case...
GK: If we're losing information, that's wrong.
LR: Do we see our product being produced by server-side transformations?
MG: Rob and Pete have spent time with the British publishers to eliminate
GK: Bottom line is why should I move from 2.02? So need these points to make the business case clear. Audio producers ready to come on board, don't need specialized player, playback is ubiquitous.
JP: In some sense the requirements are a statement of the underlying business case.
GK: The whole podcast scenario was not addressed as a requirement. Professors want to produce their lectures with audio and notes, all automated.
MG: In the original agenda, the ideas was to spend this day on details, and tomorrow address the overlying actual themes - perhaps the wrong order.
NB: Do the publishers have the best interests of the user in mind?
GK: No, they want to sell books and don't see how a book that has audio and presentation problems will help sell books. Overriding style sheets on the web has been the standard; the user rules; content publishers wanted to prohibit.
JP: Build a bigger tent. We didn't get any requirements related to cost.
GK: The visual presentation requirement has its counterpart in the audio, we can still do a better job with that (fidelity). They are selling the audio rights separate from the text; in some cases the content doesn't align.
- 10:15-11:00 Requirements Analysis and Categorization - definition of problem areas [Markus]
- 11:00-11:15 Coffee Break
- 11:15-12:30 Requirements Analysis and Categorization pt II
Categorization Buckets (Business Cases)
New Features (new products)
R2 R3 R6 R8 R12 R16 R18 R21 R23 R33 R34 R35 R36/R56/R66 R40 R41 R44 R45 R47 R58 R73 R74 R75 R76 R77 R79 R81 R83 R84 R87/R89
Single Source (streamline new content production: braille, large-print)
R48 R71 R89
Presentation - preserve visual presentation (separate into user/publisher)
R4 R9 R11 R15 R25 R31 R42 R43 R46 R48 R60 R64/R86 R69 R83
Complexity reduction (reduce cost of implementation, cheap players, free players, ubiquity)
R32 R39 R46 R62 R63
Assimilation (adoption by others, huge, critical, vast market segments, included in all the others, "resistance is futile")
R37/R68 R48 R51
Providing tools (being smart)
R52
Garbage (on the shelf, not selling points but perhaps important)
R5 R14 R17 R19 R20 R22 R24 R26 R27 R28 R30 R38 R49 R50 R54 R55 R59 R61 R65 R67 R67 R72 R78 R80 R82 R88
Wrap up of categorization
Obviously this is only one way to set up the buckets. Suggestion is to break up presentation into user-based and publisher-based. The approach of using the visual presentation has been around for a while. Many users find it useful to modify the publishers' choices for font, color for readability. Learning disabilities are very user-specific.
Question: Is this critical mass?
There are many new features, but not many that reduce complexity. All of the requirements add complexity and cost.
Promoting cheap players might be enough.
PO: If we can narrow the gap between what publishers have now and what is wanted, that alone.
JS: Focus on low-hanging fruit.
GK: Zero in on publishers. Jim Thatcher posted something on books of the future. Newer books would be more dynamic and interactive. That may be true in some markets but not all publishing. Academic publishing would change faster than your average novel. O'Reilly Safari has HTML view or print fidelity view.
KW: Drawing on the idea of making it easy to download music
PO: UK Publishing - don't really get the interactive idea, not much reason to move away from current practices, DRM less significant than several years before. (PDF is DRM!)
GK: In the NIMAC, publishers were refusing to submit PDFs since you could produce print from them.
- 12:30-13:30 Lunch
- 13:30-14:00 Formal decision on revision process [George]
Note that, due to the thinking at the time, there was no formal decision. Actions and next steps were generally confirmed at the end of the third day. A summary of actions will be posted.
14:00-15:00 NISO revision process [Karen Wetzel]
Notes provided by JS
This is partly a NISO effort, but also one with ANSI. NISO is accredited by ANSI. Z39 is an information standard
KW is supposed to pull out the parts we need to review. I believe GK has the entire 2007 NISO guidelines document, so this will be adequate.
It seems that we are doing a full revision. standards should be open and based on consensus, and they are available free
Requirements relate to both NISO and ANSI work with all of the stakeholder/players
There needs to be a bit more upfront consensus and buy-in when doing a full revision, rather than a minor one (as 2005 was)
Use voting pools as consensus body
There are leadership committees, and the content and collection management one is the one that's relevant for the DAISY spec. Proposal for revision to that topic committee: does this have the business case, is it balanced, include all of the interests, don't just knock down somebody's practice, is it actually doable?
This group consists of approximately a dozen people. Two thirds approval is required. We might want/need to know who they are.
After the Topic Committee approves, then it goes to the NISO membership.
Beforehand, it has to be demonstrated that about fifteen members must vote to show that they are interested; (meaning that they think that this is something NISO should do)
Then, when the proposed standard goes to the NISO membership for a vote, the idea is that at least those fifteen have to vote on it. There are slightly over a hundred members of NISO. Fifteen days are allotted for the fifteen member voting pool. Once that fifteen days is past, then send a note to ANSI, and then have voting period of 45 days, and that makes 60 days for the standards Action Bulletin from ANSI If have enough people, early in the 60 days, can start informally moving forward membership can express interest in being part of the working group working group has to be representative
A KEY will be that we need to have more publisher representation Seek input from IDPF and who? Perhaps BISG?
At the end of the revision, done by two years, goes back to topic Committee to see if it's done what has been promised, and then to the voting pool and any others for final vote. No major flaws or issues should be identifiable by that point.
Summary:
- GK: outlines our proposed revision which is short and has scope, goals, and rationale.
- GK has a doc that describes what should be in it
- Topic Committee
- Membership for vote, fifteen percent respond in favor
- Then to ANSI for wider approval and at the same time can be starting to work
- That blessing triggers one year timeline and one year
- There is a possibility of extension; some flexibility with a special form that can be submitted. If more than one year is required, we need to explain why.
- can be establishing the chair and forming the Working Group while the 60 days is happening
It might be possible to have a core and an affiliate interest group that is asked to provide feedback and review drafts.
15:00-16:30 Strawman process outline
Basically, a discussion of higher-level themes continued at this point. One of the key decisions was the idea to start thinking about DAISY as both a distribution and an authoring platform.
Is the spec. going to solve the problem of working with mainstream publishers? Spec. needs to be part of the answer, even if only the language changes to accommodate publishers' language.
We don't want to compete with ourselves i.e. one standard revision competing with another.
BISG. Book Industry Study Group probably should be at the table. Their white paper about ebooks may be useful, but I am not finding it quickly. the link to the BISG store
If there is a serious effort to move into the mainstream, we must be careful to convince ourselves and our constituents, staffs, and such, and IDPF and so forth.
Maybe it would be helpful to have recommendations for production and then have DAISY as distribution But note that production vocabulary is in the laws. DTBook is what's referenced in laws. It's the only part that has a direct correspondence to print.
A key phrase: Maximizing the viability of the standard as a commercial product
We do what we can at the technical level to provide a framework that can be made into a shiny commercial product making things possible, opening doors
The DAISY standard has been, in some ways, the intellectual property of the disability community.
A goal is to move the standard toward the best way to read and publish.
Two key goals are:
- Maximum viability, and
- Working toward the better way to read and publish
It's important to communicate this to the DAISY community, not a threat; longterm is to build more accessible info, not selling out
We are going to do a revision because we want to maximize the viability of the standard for use in commercial publishing.
What are the priorities among the features and buckets in order to achieve this?
Would it help if we split the distribution and authoring within the standard?
what would such a split have to do with the buckets that were sorted in the morning? Categorizing by authoring and distribution might make some requirements emerge as easy ones to do. An example might be that it'd be possible to start using off-the-shelf software for presentation.
JP: observed that there's a disconnect in terms of the requirements we have and the plans being discussed.
It'd be important to gather the requirements of what the commercial market needs.
What are the problems that have to be solved there? What are the use cases for the commercial market and playback systems, etc.? These would have to be aligned with our existing community's needs, too.
We might need to do more focus groups and help them to see the business case. We could do another requirements pass, or we could set up a straw man of the spec. to include publishers.
We want to work with publishers who are open-minded, forward-thinking; we want to find a friendly publisher, a mini-project, to give them something concrete.
The real goal is to maximize the use of the standard in the market. Salesmanship and training are required.
If we develop a prototype and proof of concept, these can lead to the conversion of hearts, minds and attitudes. There also can be geek to geek diplomacy. Example could be: Google, O'Reilly, and NISO as a possible group meeting? Perhaps have them submit requirements.
How do we sell SMIL? Why are people adopting it, and what causes others to ignore it? Is the issue primarily about "proprietariness?" The lack of adoption of SMIL may be a part of what may hold back the reading systems and their ubiquity.
DAY TWO, Wednesday April 16
This day is about building consensus on the nature of the revision; * what problems are we going to address in the new specification, and what will the actual effect be on users * how do we want to re-architecture the specification, and what will the effects be
- 09:00 - 12:30 Theme: Defining which issues to address
Quintessential Standard
Start with a recap of what we discovered yesterday:
What's the essence of a revision, re the "quintessence" of the Standard
MG: Will probably entail going through the requirements again.
Review
Start with distribution/authoring dichotomy, then discuss modularization.
Yesterday: The business case and the publisher focus of the revision doesn't bring any requirements to the table - it seems to be more of how we position the revision. It's good that we're thinking about marketing/business and not just pure technical merits of what we could do. Keep both in mind.
PO: A question about timing: When do we formally engage with NISO process? Certainly not now, but we need to determine when that will happen. Do they have an expectation of revision every five years? Then 2010 would be expected.
GK: Every five years require a review of status, whether that's a revision or not (reaffirm, discard, etc.) The process doesn't require anything sooner, but Content and Collection has seen documents produced so far - post-Copenhagen summary, modularization paper and others. Another was sent after the London/TechShare meeting and they'll get another after this meeting.
GK was expecting that the document we had provided would be enough to launch the revision. Not so.
PO: We should know what they're expecting.
GK: We should set expectations in the next report. It was great to have Karen here and her getting to know us. JS to speak at NISO meeting in May.
The 5 buckets that we ended up with yesterday represent a sorting based on the business case/selling points. Overarching point being the "Best way to publish" - More appeal for publisher. LR: It's not where we started, but it's where we ended up.
KK: We need to go through requirements again with a different set of buckets. Yesterday's were the "Business Case Buckets". [DL to circulate a picture of whiteboard classification]
Discussion
Can we use the "Best way to read" alongside "...publish" as a parallel track to the standard? The strategic plan supports this direction.
MG: Late yesterday we came up with one sentence that may form a part of the quintessential summary (maybe not the only one). "Focus on maximizing the viability of the standard as a commercial format." Implies a lot, including some unknown things because we haven't engaged the publishers. It's a domain requirement giving us an overall direction, desired effect, goal. Probably not the only goal - we need more. We know we have a community with many different desires. So - let's append the sentence into more of a list of such highly compact, loaded vision statements.
MD: Look at community and see requirements. Some are desires for standard, some are just desire for something to exist in the DAISY world. The latter can go to workflow of how-to, as opposed to just changing the standard. It's one way to split up the requirements.
JP: Goal was to revise to maximize the viability for use in commercial market. Actual goal is the use, not the usable standard. Part of that is to make standard support this. Then there's the rest of the job - selling, making it happen.
GK: "Water the roots," too.
PO: Three goals: One outlined already, one for DC members (standard as an authoring environment), one for DAISY as a reading experience. Distribution domain as opposed to authoring. Commercial = playback and publishing.
JP: We didn't discuss manufacturers so much yesterday. PO and LR disagree - did discuss and the revision has to include these parties. Playback is the broader group - not just DAISY playback.
GK: One domain not represented: Many uses talked about but unrealized but seen in requirements - video, language, preservation, training, emergencies, podcasting - big market segments that could use standard but not being directly addressed in standard. Is this a goal of the revision? Could just be a marketing goal.
JS: Clearly a goal but are there the resources to market it? Regardless of what we put in the standard, it won't matter if nothing behind it to get the word out. Can't just fix it and cross our fingers.
GK: But the work starts with the standard.
PO: As an example: Emergency information is just another form of publishing. Look at UN money spent on publishing - one of the biggest publishers in the world if it's looked at that way. So, it slots into one of our goals. Requires a different kind of marketing effort, though.
MD: Hiroshi - many international organizations printing leaflets and distributing them in the "wrong language" (PO agrees). We could also solicit research projects from interested organizations. E.g. deaf in South Africa. Enable video and captions in standard but then have this picked up to illustrate new capabilities of standard.
GK: If Z39.86 is a better way to publish, we need to make sure it's better for everybody. Thinking about the three Rs [reading, writing, and 'rithmatic]. Better way to read and write (publish). Math too! In the hands of everybody.
JS: People are going to need to think about the Z format as more than just for books. More of an "information management" system. It's the very meaning of "DAISY." It's more like a multimedia system and less of a print-conversion-only thing. It could even be incorporated into course management (and not just in academic circles). Not necessarily a standard change - just a different angle.
GK: DAISY has a revised mission statement - it doesn't change mission but restates it in a very compact form. Approved by board in Zagreb. "Face lifted" for the brochure.
KK read the vision and mission statement from the board meeting minutes here:
- Vision Statement: The DAISY Consortium envisions a world where people with print disabilities have
equal access to information and knowledge, without delay or additional expense
- Mission Statement: Our mission is to develop and promote international standards and technologies which enable equal access to information and knowledge by all people with print disabilities and which also benefit the wider community.
The fundamental principles support the people we're serving: It's clear we're not selling out to the publishing industry. The mission statement supports that we're all about accessibility.
Now we have three or four goals but they're not clearly identified yet.
JP: What are the outcomes? What do we want to see in the world when we're done? One example, authoring-related - want the ability to create a master file from which multiple accessible formats can be produced. This goes into the "Single Source" bucket from yesterday. It's an existing membership, authoring-related outcome. How does the standard change to accommodate that outcome? What has to change in the standard in order for that to happen, if anything? And WHAT ELSE IS NEEDED? We tend to think about just standard changes but there are other things - marketing, tool development, etc.
This is just one outcome we can use to come up with a standards goal.
Another on the reading experience side: Great new products with new purposes, rich experience, multimedia, interactive content available to everyone. Again - what do we need to do? In this case, much more non-standard-related activity has to happen.
Third: Already discussed - publishers everywhere taking up the Z standard - ubiquity.
MG: "Optimizing the standard as a multiple-output-format authoring platform."
GK: Add "channel"?
JP: We should look at these outcomes and state them as plainly as possible - this is what we're selling. We can geek it up later.
RL: Each outcome needs a different approach. Some are more around standards other around "hearts and minds." Not one size fits all. We need to work backward from outcomes.
JP: We may not be able to do it all. Different requirements from different outcomes.
GK: One hang-up: GK views the source document at heart of everything. What's the relationship to the other output formats?
LR: Each output format pushes requirements back onto authoring format. E.g. speech synthesis markup, braille markup - end up getting pushed back into the authoring format. Need to keep them all in mind when we're designing it.
GK: So: short statement now is developing an authoring spec and multiple output standards.
PO: The goals are not entirely independent.
JP: We want all kinds of new rich multimedia products used in lots of different ways. We want those things to exist. What's in the way? What, from a standards perspective? We need to pave the road with the right kind of standards support.
RL: There's a huge opportunity to position Z/DAISY as *the* authoring format - there is a vacuum there and we could put the DAISY file right in the center of everything if we get it right.
JP: What does George mean by authoring format?
GK: DTBook Next
MD: SMIL is also an authoring format. We need to make DTBook and SMIL play nicely together.
GK: We need to continue to solve the problem of existing print publishing area and not lose focus on solving that problem. We're in multimedia. Moving in other directions is great, but...
RL: Lack of standards will be a real problem. The publishers' difficulties aren't the killer - they don't actually stop us - but if we don't have the standard right... PO: Others will just move on and fill the vacuum themselves.
JP: Agreed - the current model works but is annoying and expensive. We can help publishers by allowing them to focus on what they need to and not this stuff.
GK: Let's get into sorting but still not happy with what we've got. Understand authoring format need. We want to be in "multimedia heaven" both in authoring and distribution.
Once piece: Textual source doc - maintaining this. Add multimedia - audio - understand that well. Now bring in interactivity - testing, forms etc. Then add video/multimedia and include in the authoring environment - synchronize these things. Looking at authoring and reading environments for multimedia (including text).
LR: Spend time looking at output formats? Many are monomedia. What outputs need to be created so they can be streamlined and used on simple players for that medium?
RL: Need to define multimedia as well. What are outputs? What's the right terminology? PO: "Multiple formats" versus "multimedia"
JP: My angle: Why do we want to do a revision? Is there a good enough reason to do this? What's the ROI?
MD: It's the right thing to do!
JP: What do we want to happen that's not there already? Let the standard facilitate that, so we agree to put in the resources to do it - then we need to figure out what those things are. We've also got to have a clear understanding of what's going to pay for it when it's done - thhe business case. Multiple things there - need to understand what and agree to it. And figure out what's standards and what's everything else.
TKC: And need to have commitment too.
JP:...and what does the goal mean? What data do you need to produce all that (in the example of single source). Collect the data, and find we need different people, maybe? Fear that we've tended in the past to design a standard and then put it out there and hope folks come and use it. Hasn't exactly happened.
JS: Requirement requesters aren't necessarily the "doers." Who's gonna do it?
GK: Still not clear on what we're doing at this point. If we have an authoring format from which we can build a multimedia, multiformat reading experience - understand the text-centric view of world there. If we add video to this - embedded media, like in most e-books today, different from synchronized multimedia - want that object synchronized with other channels for accessibility. This is what we want in the standard.
MD: So you have SMIL.
PO: That's just part of it. Want whatever we develop to be easy to use/flexible to allow other formats e.g. large print, braille to be produced.
TKC: What if video is driving the text? Need to keep it open. not just text-centric
MD: SMIL is controlling it.
PO: What GK has said doesn't undermine the principle. Need to discuss how to author.
MD: Even if we expect the end distribution format to have embedded audio, the authoring environment doesn't need to support that - we can rely on the distribution format to handle that. They're in different domains.
GK: Do we have images in our source content doc?
RL: No, but we can reference them.
TKC: But it doesn't matter - we need an abstract model.
MD: Urakawa model?
TKC: Different ways to represent things, to better utilize the advantages of different media. SMIL not necessarily in charge. We need to be very abstract in our model.
GK: How does the authoring format relate to the distribution format?
PO: Principles say we're thinking about both.
GK: Restate goals: Develop an authoring format and a set of distribution formats including multimedia distribution, DAISY 2.02, lots of other things.
JP: So the extensibility mechanism becomes much more important. Previous efforts didn't leave room for others to come in with better/new ideas and incorporate them. But we can't specify things that don't exist so we need to create a spec that allows for innovation when it comes along.
RL: Rather than "new products" do we mean "new distribution methods"? JP: New products sounds better!
PO: Agrees with necessity of extensibility and the importance that people understand how to do this quite clearly.
JS: But this is what we are getting to - moving away from "books" and textual thinking. Really would have a framework for authoring and one for distributing, with good hooks. But how to keep it under control?
TKC: Should be wide open at least on authoring side. Need this in order to build on it in the future?
MD: Authoring framework, with distribution targets. Transformation imposes expectations on authoring format. The number of variations is limited.
JP: Add in defaults, fallbacks, etc. so playback systems receiving things they can't handle natively can still handle them intelligently.
MD: This would be a great strength for the authoring format.
MG: Principle of extensibility applies to both sides. Nothing to prevent anyone from authoring in the distribution format - it's not a locked pair.
TKC/JP: Distribution format has to be fixed in some ways or can't have interoperability
LR: And maybe not accessibility!
MG: So - two expectations on the authoring format. One - just an improved DTBook "hotted up" so we can add other formats but still text-based. Other option: All-encompassing in terms of media. A completely different thing. The former means we just address core set such as DAISY, large print, and braille. Authoring format would not, at its base, support for example video.
TKC: Should not be fixed to text but be able to handle text. Can't extend it to do everything - we would never finish - but what if we're text-centric and want video only?
MD: Abstracted, this is a time-based media as the center of presentation. It's a completely different paradigm from text-based.
GK proposes fundamental unit - link text to audio to turn text into a time-based system.
KK: Overriding principle should be twofold: First (and maybe unstated) - make it simpler and more extensible. Envision the DAISY accessibility framework at center, with profiles feeding in and out. Start with richest content source and let it be the driver. E.g. if you start with video then it's video driven. With text, it's text-driven. The framework allows us add on later.
We need to stick with synchronized media (not video) - some want the published page layout so in that profile you'd start with that - the page. It's the page, dissected into pieces, that then drives the reading experience. But no single wording that explains this to the general public.
Need to get someone to implement something that works at a highly visible level. The best impact on the market is for someone to create and show something that works.
JS: That gets to the need for reference implementations. We have to develop them in parallel with the standard.
KK: But those aren't designed for the market. But if products are too hard to create then there's a problem with the standard.
JS: People don't know what they want because they've never had it before. People think they still want ASCII text. People don't necessarily want it simple, but they don't know that.
MD: A simple user experience doesn't imply a simple standard.
- BREAK -
GK: Some bookshare staff joining us - Reuben, John Br____ (Sr. Engineer)
But before we get moving: a big current problem is the lack of interactivity. There's just no way to rewind a presentation. The players don't allow it. E.g. rewind doesn't work well. It's easy with a screen reader/HTML. That kind of interactivity is lacking in the current DAISY reading experience. It's the same thing with table mode - I want to interact with the content. Same thing will happen with Math. Don't want to be encumbered with the SMIL presentation.
MD: Should we do what W3C does - need one or two implementations for each thing in the standard?
GK: We have a view of the revision of the standard. We know we need to build the business case for it and it will focus on its appeal to the publishing community. Two general areas to focus on: The authoring format and the distribution format(s) - multiple formats it can produce including supporting a multimedia format.
On authoring side - think beyond the text!
Going to go through requirements and identify essentials for next revision.
MG: Through the requirements but this time with authoring/distribution dichotomy in mind? Then what? Filter out most essential requirements?
GK: I want to come away with a really clear idea of what revision is going to be.
JS: What's "essential?" Best bang for the buck based on our business case? Something we've been meaning to fix? What?
MG: E-mail to list summarizing three overarching themes - what MG thinks we've been talking about - with each requirement group sorted:
Message contains:
Three overarching themes (goals of the standard)
Maximize the use of the standard as a commercial product
- publisher alignment
- complexity reduction (cheaper players)
- ability to reuse parts in other contexts
Enabling the use of the standard as a multiple output format authoring platform
- thinking big; this is not necessarily text based (although many of our fave formats would do fine with that) but can have audio or video at its core (a "primary channel" of any media type)
Fostering or facilitating new and/or improved DAISY products [JP adds: for everyone everywhere now and in the future]
- enhance presentation (i18n and CSS related fixes, other enhancements) [e.g. broken in Japan]
- provide a framework for extensibility, examples: mathematics, interactivity, video
JP: Change #3 to emphasize everyone everywhere now and in the future - allows in bug fixes etc.
JS: So "essential" means they fall into one of these three things?
GK - happy with that. Now - pass through the requirements?
MG, MD, JP: If a requirement doesn't contribute to one of these it's out of scope for this revision or it means we've missed something. Needs to make sure it fits into at least one of these things
MG: A reality check. Requirements are raw materials. Did our distillation work?
Results of second scan through the requirements:
Bucket 1. Commercialization
- 8, 11, 12, 16, 18, 23, 24, 28, 32, 33, 34, 35, 36/56/66, 37/68, 39, 41/81, 44, 46, 48, 52, 58, 62, 69, 71, 89
Bucket 2. Authoring platform
- 2, 3, 4, 5, 6, 7, 8, 11, 12, 14/78, 18, 21, 24, 25, 28, 29, 31, 33, 34, 35, 41/81, 44, 48, 50, 53, 57, 58, 60, 64/86, 70, 76, 77, 79, 83, 84,
Bucket 3. New and/or improved
- 2, 3, 4, 5, 8, 9, 11, 12, 15, 16, 18, 19, 20, 21, 22, 23, 32, 33, 34, 35, 36/56/66, 40, 41/81, 42, 43, 44, 45/87, 47, 49, 55, 58, 60, 70, 73, 74, 75, 76, 79, 83, 84
None of the Above
- 17, 26, 27, 30, 38, 51, 54, 59, 61, 63, 65, 67, 72, 80, 82, 88
GK: A question about #7 (braille): What non-semantic info on a print page are we not capturing? Got page info element. Is there semantic info being conveyed by print formatting/positioning that we're missing, we need to include that.
PO: No conventions in braille formatting. Do we want to get into that? Need to mostly work with what we've got. Some issues incl. table layout.
GK: But we don't control table layout presentation now - just provide the info. Can do same with braille. It's up to the reading system.
Summary
MG: Our original objectives for today (building consensus on nature of the revision etc.) turn out to be very well-aligned with what we've done. A good start - we needed to work at this high level to start. Back on agenda.
PO: We did find a place for each requirement - not much confusion.
MG: Now we have an overarching theme statement. We can spend the afternoon looking at spec design approaches: mod squad paper and authoring/distribution breakdown.
- 12:30 - 13:30 Lunch
- 13:30 - 16:00 Theme: Overall Specification Design approach
Mod Squad report: DAISY Accessibility Framework
Mod Squad report: DAISY Accessibility Framework
16 April 2008 1:00pm - 2:45pm
Scribe: Linus
Markus: How does this help our goals? Did everybody read the report?
James: Generalizing idea of media channels and provides extensibility as it abstracts out certain parts. The accessibility framework knows nothing about specific content types. The parts need to be combined into a profiles to create accessible formats.
Markus: We are mainly thinking about distribution formats. We need to think about what this means for the authoring format.
George: Does this work for all accessibility groups?
James: Yes, multiple channels are supported, i.e. the ability to create equivalent content channel in another format and identify same structural points. In a way Daisy already does this, but this is at a higher level.
George: Focusing on (multimedia) digital media presentation.
Lloyd: Single media presentation also included.
Markus: How does this affect profiling?
James: A profile would use the content module (with a limitation on the actual content types allowed), with fallback if not supported. It would also have a structure module, synchronization module and an extensibility module to support new content types. All of this is part of the specification.
The specific profiles identify the content types it supports, ie. DTBook, SMIL etc.
-- Module examples --
Navigation modules: flat, hierarchical, search, page
Semantics module: role attribute
Markus: Modules are composed into a profile. Someone else could create another daisy-like profile, i.e. others could pick up the principles. We might not endorse PDF, but someone else could (like Adobe).
James: Someone could plug in a new navigation module as well.
George: Would there be a separate channel for low vision images?
James: Doesn't this sound SMIL-ish, something that should be handled by SMIL?
Marisa: Might be another version of the document, or a switch (for each image) in SMIL.
Markus: We have so far known our client's disabilities. With this we could publish a book with enough channels to fit everybody.
Ole: I would rather see it (channels) as an authoring paradigm. How would the user select the version to play?
Markus: Think of the language shifting paradigm, i.e. when you supply the same presentation in multiple languages (language learning or multi lingual population).
George: What about complexity. This sounds complex.
All: Simplicity for whom?
Markus: Implementors need to deal with profiles only. Compexity is for the committe. Now we deal with extensibility. The composer of an extension would probably also need to deal with the details.
Ole: But there would of course be guidelines for that.
Markus: The profiles could be simple (e.g. the "Daisy classic" profile). The profiles are on the distribution side only.
Ole: There would probably be authoring tools directed at a single profile.
Markus: We also need a fool proof fallback mechanism.
James: Content provider must provide the fallback. Sometimes the producer might decide not to provide a least common denominator fallback.
Markus: So what does this give us?
James: Extensibility. We spec above product definitions (don't have to specify everything now) and support the commercial market (for example synchronized PDF).
Lloyd: Can there be audio in PDF?
George: I've seen audio embedded as a link on the top of every page in the PDF, so the audio was synchronized at page level.
Jennifer: What would profiling mean for Daisy OK?
Ole: We already have 6 different types of books today.
George: It is now 3 types, for simplicity.
Marisa: The manifest (package file) would probably describe what the book can do (i.e. which profile it supports)?
Markus: Forces us a mechanism for extensibility. What about interoperability? This could actually be worse from what we have today.
Lightweight profile example
Ole: What would the difference between a lightweight daisy profile and Daisy 2.02 be?
All: There would be no skippability in the lightweight profile, and we would probably just have page and heading navigation.
Markus: The profile would contain an audio content channel, with a few file formats specified, packaging module (containing a manifest and the profile name), navigation module (perhaps flat navigation with roles), id3 tags, order of filenames. No phrase detection so the jumps would be time based.
Ole: There could also be guidelines for ID3 use.
Markus: This results in compexity reduction for implementors, tool providers etc.
George: We need to engage the CEA folks as well. Their specification is more player related.
Dominic: But the CEA spec is not so simple to implement. Binary file, and provides only one level of navigation.
George: It's basically a music album playlist.
Markus: Does anyone support it?
George: The lightwheight profile is just terrific for commercialization. Often 6 - 10 h novels.
Daisy ncc/ncx-only profile example
George: Next level would be Daisy ncc/ncx-only functionality. Phrases support and skippability.
RFBD, RNIB are not currently doing phrases. NLS does it in some of their books, as well as DBB. Most (all?) TPB books has phrase detection.
Dominic: We should be able to ship books with multiple views. We shouldn't remove functionality from books, just let players ignore the heavier to process stuff. Use the Distinfo file to select the package file to use.
Marisa: What about bookmarks created when reading using the lightweight profile, would they be openable from another profile?
(Someone): Is the fallback handled by the user, the player or by the publisher (i.e. in the book itself)?
Markus: Publisher should be able to set fallback behavior.
Dominic: I think the player and/or user should select the fallback.
Markus/Ole: The Distinfo file should contain a tree of books: Selecting which book to read on the first level and the profile on the next level.
- Following discussion on alternative approaches
Distribution and Authoring
16 April 2008, , 2:45pm - end of the day, Scribe: Marisa
Role of DTBook
Currently, DAISY is mostly a distribution standard, but DTBook is not an efficient distribution format, mostly due to the fact that it is difficult to properly display the files in commonly-used controls. It is, however, a good authoring format, and has strength as a master format.
While we want to solve our distribution problems, we don't want to make the mistake of restricting ourselves to a single format. One idea is that XHTML will be a great distribution format, but we don't want to prevent people from innovating. One idea is to suggest a fallback text format that all players should be able to handle.
How do we translate our DTBook constructs into something like XHTML?
* Page numbers = controlled in the NCX; not a problem to have them in XHTML. * Footnote = links controlled by the SMIL presentation; the XHTML could also have hyperlinks connecting the superscripted number and footnote body
A powerful tool for using our semantics could be using the role attribute. We would create an RDF taxonomy to express our semantic view of documents and apply the roles to XHTML (or potentially any markup language such as SMIL).
Could we do a roundtrip between DTBook and XHTML + Role? We think not. But we shouldn't have to; this is about separating authoring and distribution formats.
Question: could Braille translation software learn to work with roles?
Question: can we write into our taxonomy the equvalencies between distribution format elements and authoring format elements? For example, we want to say that our "p" tags are the same as XHTML "p" tags; we don't want to write "<p role="paragraph">".
Role of Urakawa
Is there going to be a separate specification for the authoring format? According to Karen at NISO, it is possible to have different parts within a single specification.
We should consider the Urakawa SDK as a reference for developing an authoring format. Whatever authoring specification we come up with should fit nicely into the Urakawa object model.
If the text is in control, then something like DTBook could be a good starting point, but if audio or video is in control, something else must be used. What we need in an authoring format is to have the structure separate from the media.
The structure should be in control no matter what media type is being used. For example, you can have a heading that is an audio clip or an image.
Publishers would be required to validate according to a schema.
We will still consider text as a fundamental block of our standard, because most of our users are re-publishing content that starts its life as print. These people will need a good conversion DTD to go from their source to a DAISY authoring format. DTBook could be useful here as part of the roadmap.
We recognize that this has to be marketed properly so that people don't feel like we can't make up our mind about what format to use.
Note that W3C also publishes IDL (interface definition language) and we could consider this as an approach to specifying an authoring format.
The whole group is pleased with our emerging approach: we are able to express the essence of DAISY as a. structure and b. multimodality and apply this to an authoring roadmap and distribution in everyday formats.
- 16:00 - 16:30 Conclusion
ZedNext Pieces and Relationships
We review the agenda for tomorrow; everything looks on track.
What pieces and relationships do we have so far for ZedNext?
* Distribution vs Authoring * Roles * Authoring object model * SMIL DAISY Profile
For example, DTBook is not our object model for authoring, but an improved version of DTBook can be used to start the authoring process and get the content into the object model for authoring.
Are there any existing RDF ontologies that we can look to for guidance? There should be many public ones (ARIA, XHTML) from which we can see the semantics that they have defined and be sure to align our elements with theirs insofar as they have the same semantic meaning.
DAY THREE, Thursday April 17
This day is about creating high level project plans, including both resources and timelines. There is also a slot for continued work on overarching architectural concerns.
- 09:00 - 09:01 Scribe [George]
- 09:00 - 12:30 Theme: High Level Project Plans [George, Markus]
James scribe
NISO process and draft standard
George talked to Todd Carpenter (NISO) about how fast this can move forward; about draft standard for test use. Possible for working group to create beta standard, implement it, etc. prior to NISO approval. However, needs revision committee in place and involved (don't just use a couple of people).
The urgency of DTBookNext development
Peter emphasized the need to move swiftly to prevent people from all going their own directions, which is a threat to DAISY. He suggested we ask the DAISY board for commitment of resources to do this quickly. It would be dangerous to have no deliverable until 18 months; need something sooner (6-9 months). Otherwise, organizations will have moved on and designed their own ways of doing things. This complicates the marketing task: you have to convince multiple organizations to migrate from multiple formats to the new standard. We need something like DTBookNext in order to have an interchange format to share rich datasets among libraries, serve as the basis for legislation (e.g., NIMAS), etc.
The area where organizations are innovating now is in authoring formats -- that is, a format for text documents, since dtbook doesn't do what they need now. There was general agreement that developing DTBookNext first would be a good strategy to address this. James pointed out that, if the risk is for people to devote time & effort to go their own way, why not just involve them? We need to:
- Figure out where DTBookNext fits within the overall context of ZedNext
- Bring the players to the table to start talking
Markus reminded us that we also need to have publishers involved in this. DTBookNext must be rich enough for DAISY producers and simple enough for publishers to deal with.
The way forward
George outlined the process at the highest level:
- Describe overall goal for standard
- Identify pieces of standard and how they fit together
- Then, work on the parts that are most urgently needed
- Put out as draft standard for test use & get feedback
- Create final spec for vote
This is then overlaid with the NISO process and resource allocation.
ZedNext architecture: 3 pillars
With input from a spirited discussion among the committee, Markus drew a draft diagram of the overall architecture of ZedNext. This consisted of three "pillars": Interchange format, Semantics, and Distribution.
Interchange
- Rules for creation (abstract)
- Specific formats (concrete), contains:
- DTBookNext (text-centric)
- Extension space (future specific formats)
Semantics
- RDF taxonomy, contains:
- Modules, which can be composed to form:
- Taxonomies for specific purposes (e.g., book, magazine)
- Extension space (future extensions of Zed taxonomy)
Distribution
- DAISY Accessibility Framework (abstract), contains:
- Abstract modules (one or more)
- Rules for creating profiles
- Profiles (concrete), contains:
- Specific profiles (one or more)
- Extension space (future specific profiles)
James pointed out that we need to do much more thinking about this, especially on the interchange and semantics parts (the Mod Squad has already devoted much time and thought to the distribution pillar).
Project Planning
Minutes, Zed Meeting Thursday 17th April 11am to Lunch, Rob scribe
- Communications: (Report; Revision Overview; Business case)
- NISO Process: (Request for Revision; Vote on Revision; Working Group Formation - get through these two asap in order to facilitate the following)
- Resource identification (Board buy-in)
- Technical Development Work (ref: picture board #3 and/or text description from previous minutes)
GK: Rather than try to do it now, do we need small working group to plan technical development work
a) before we can commit resources; b) so that we can fully understand implications; c) so that we can fully understand inter-dependencies of technical developments.
Zed meeting agreed that this was the best way to achieve this.
MG: we could prioritize the fix of DTBook-text version (aka DTBookNext) without a final version of the abstract rules - as long as we have an idea of basic fundamentals of the abstract rules it should be OK.
GK: We should try to parallel the creation of the abstract rules alongside the DTBook fix - it will slow us up if the same people are doing everything.
RL: How big is the skill pool?
MG: Fixing DTBook would be doable with an expanded group but the number of people who really understand all of the technical work as we have discussed is relatively small.
Suggested names for working group/DTBook fix: Kenny Johar, Dave Gunn (large print input), Joe Sullivan (braille input), Per Sennels, Linus Erikson, Matt Garrish, Markus Gylling, James Pritchett, Ole Anderson, Stephen Phippen, Boris Goldowsky, George Kerscher. Invite Sun, Microsoft, Dave Schleppenbach, Martin McKay, Adobe, O'Reilly, Pearson, Oxford University Press as reviewers.
Suggested names for more extensive continuing technical work: Kenny Johar, Markus Gylling, James Pritchett, Ole Anderson, Boris Goldowsky, George Kerscher but we could add other DAISY members to contribute via a NISO call for participation.
- 12:30 - 13:30 Lunch
- 13:30 - 16:00 Theme: Overall Design approach: requirements
- The aim here is to create a final list of requirements (i.e. deliverables) on what we expect as the outcome of the revision process. This is a "manifest" which lists the effects we want to achieve for end users, for vendors, and for ourselves as a maintenance agency. This listing will serve as a guideline for the coming work, and will enable us to measure rate of success at the end of the process.
- 16:00-16:30 Conclusion
Lloyd Rasmussen - scribe
GK: How much time is really required for the DTBook subcommittee to do their work?
JP: They may start on the architecture before they get into the weeds of DTBook development.
JP: What schema language? What structure? Build from ground up, or port what is there? Start building it from modules?
MG: Look at Dave Pawson's draft schema and breakdown? Part of this is f2f and part is b e-mail. Compare the RNIB DTDs against DTBook.
Could schema authoring be outsourced? Probably not.
The post-meeting phase fills out the features defined in the architecture.
A decision beyond DTBook is something like: can you define SSML islands in your DTBook files? But before you get to that stuff, figure out what exactly goes in the DTBook namespace. Then drivers must be developed for modules such as table, list, metadata, image, etc.
MG estimates probably 3 days for the first meeting, but it might not be finished work, especially if braille issues become too controversial among the committee.
RL: This DTBook process has much to work with already, it may not take very many months to get this done.
Two DTBook meetings, the first with a smaller group than the second; the second meeting would start with a day's briefing of the larger group by the smaller.
GK: Sometime after those two meetings, can begin figuring out what to submit to NISO for a longer-term plan. The DTBook meetings might be late summer.
May end up with A, B and C parts of the standard. C is role definition.
Where would innovations fit, such as word-level synchronization without SMIL? Probably would be in newly-developed modules. A interchange, B RDF roles and semantics, C distribution and profiles.
Distribution spec would probably be divided into sections for its various moduls and profiles and rules for creation of new modules and profiles.
Can these three parts be revised and go through NISO independently of each?
OHA: Because of profiling, changes within modules cascade into their profiles, so the whole spec really does change. To make the profiles stable, the modules must be stable.
GK: So how do you make the standard extensible without requiring a change of the whole standard for each new extension?
Some things map to existing roles for which you are giving new equivalent names. But others are really novel.
You will need fallbacks as you do this, so reading systems are not broken.
GK: How do you do compound documents containing embedded islands of other non-DTBook content
MG: Perhaps different profiles enumerate allowed namespaces. Again, fallback. Maybe one of the profiles will be for generic extendable documents.?
These scenarios must include test cases. This is how much of the innovation will occur.
GK: Most of the submitted requirements could be addressed using these concepts. But how do you do word-level sync without being too verbose? GK will probably ask Martin how he generated his Flash presentation. DL would like to see the sync data compiled into the same file as the material being presented.
Zed conference calls continue how often? Probably continue with twice per month.
GK will need to create a plan to be submitted to NISO, over an 18-month work period.
DL: Use milestones in the plan, not so much fixed dates.
Should it be unrecommended until we do the XHTML because of appearance problems?
Until middle of June, must write all of these documents and convince your bosses that this upcoming work is a good business case. Would our organizations move to this new spec, should we develop it?
TKC thinks many organizations will move.
DL: 2.02 is like the audio CD; it's ubiquitous and hard to replace.
Changing from CD to download may necessitate new players and new format. How do you justify a standard that only lasts a few years? How is the new XHTML-based standard better than 2.02?
TKC thinks the existence of profiles for lightweight and for streaming are the selling points of ZedNext.
JS: The new standards will really make extensibility more robust, and make authoring tools more interchangeable. The tools as well as the files they manipulate.
MG: won't have to create so many customized tools.
Adjourned at 2:06 PM.
