Notes from Zed Face-to-face October 1-2 2007 London
These are the detailed sequential FTF notes to accompany the October 2007 Z3986 FTF Summary document. Each portion identifies the scribe.
- 3.1 Review of NISO process and status of this work (George)
- 3.2 Overview and Orientation (Markus)
- 3.3 Requirements development
- 3.4 Profiles/Modularization
- 4. Braille in DAISY WG element set
- 5. SMIL 3 (Marisa), 6. Requirements
Gathering, 7. Project Planning (George, Markus)
3.1 NISO
Process, Status -
Monday October 1. Morning, Diana Scribe
Zed Meeting in London 1st of October 2007 ================================= 3.1 Review of NISO process and status of this work (George) * Karen Wetzel from NISO has advised us to make up our own terms of reference. It has to be open to NISO and others. George and Peter were set to write the guidelines - to be completed by end of October. * We need to announce our activities to NISO. The statement will be written by George and Lloyd - to be completed by end of November. 3.2 Overview and Orientation (Markus) Started to review the agenda. The agenda is very ambitious, but we really need to make a lot of decisions. Markus presentation is attached in a separate document. Some discussions followed: * What should and should not be in a specification? Should there be player functions/requirements be in it? Informative sections should be interpret as describing behaviours. "If you take it out and it's not working anymore - it was not informative (JQ)". * Discussion about Zed spec verses the requirement document for Zed production tools. EBU document? Is it up to date? Here's the link to the Document Navigation Features List document prepared as part of the original Zed spec development: http://www.loc.gov/nls/niso/navigation.htm *** End of morning session part 1 ***
3.2 Overview
and Orientation -
Monday October 1. Morning, Rob Scribe
Zed Monday Morning Part Two - Notes by Rob Longstaff Requirement Development Based on Current Knowledge Define the process of requirements gathering Discussion on timescales MG: the data from the requirements gathering, if done well, will start to define timescales. JP: from last meeting the end date was December 2009 - does this still stand? GK: six months on, is this still realistic? RL: should we set the "How" and "When" for requirements gathering which when complete would allow us to set a more realistic timeline for the rest of the work? MD: We could also start some technical work based on current knowledge in parallel - we don't to wait completely for the requirements work to be completed. DW: We have seen a Shift from book paradigm to more multi-media requirements (inc. video) for some time - are they acceptable within the traditional paradigm? JQ: We could have short-term modular spec reformatisiation based on DAISY 2005 as well as the creation of a light user spec MD: do we work on list of problems as outlined by MG in the earlier session? MG: we need requirements gathering to get buy-in and commitment - The proposal is that, based on our set of defined problems, we have enough to tell us that a new spec is needed. We can have two tracks: 1) start technical work on that list; 2) gather requirements. if the requirements gathering indicates that the current spec is sufficient or that it is not now relevant, then we can close the project. If the requirements tell us that there is a reason to go on, then they will help to determine the next set of timescales. JP: how do we assess commitment to any profiles that are developed? (eg light profile/playback)? MG: friends within the DAISY community should give us this feedback GK: one requirement seems to be to recast DTD's as they are too loosy-goosy (copyright George Kerscher 2007) into schema MG challenged this as research has shown that all schemas can be expressed as DTD's GK: wideband/Orbis are other considerations, all of this telling us that spec is out of date. GK sees the text side to be a key driver (rather than the audio side) - what should be the function of our DTD's, how should they relate to other DTD's? PO: at RNIB we do not just produce books via XML - we also produce magazines. leaflets, bank statements. This is not just about access to books, it's access to information JQ: we could consider that DAISY is the solution to make any content accessible JP: zed spec can be seen as end product (the book) sitting on top of a number of technologies that enable this - these underlying technologies can be deployed elsewhere (SMIL is a good example of this) GK: from the standards perspective, we can revise or write a new spec, or break up current spec into parts. IDPF seems really important re content and navigation PO: propose timescale re requirements gathering - to be completed by March 2008. Then review against other requirements such as EBU and take outcomes from there. We know technical issues and we should select from the list and move ahead as agreed MG: we need to understand how to gather requirements JQ: it needs to be personal MG: volere.co.uk shows public domain requirements gathering template [this was demonstrated on screen] Proposed minimal submission requirement: Description - what Rationale - why Reference - detailed spec Source - who Source stakeholder type - user category Value - should or must (or rating 1-5?) TC: Scoping of requirements gathering is important MG gave examples of requirements gathering: face to face with users in schools (ethnography), using scenarios (natural language description) via users/educational testing - this would be submitted to us and filtered into an appropriate form (the final requirement form) TC: What about current non-users? MG: we need to come up with scenarios/template/example/submission form/links to previous information for web DW: how do we interface with communities that have specific communication issues? BG: the Copenhagen notes might have some info on this? A list of such communities should be available for contact once we are prepared to do so GK: we should have a trial run of the website/fields before we go public? We could use our own current set of issues to test this We agreed to proceed with two examples - over to Markus
3.3 Requirements Development -
Monday
October 1. Afternoon, Lloyd Scribe
October 1 afternoon, beginning about 2:15 PM - Notes by Lloyd Rasmussen Marcus to define forms and web pages for the database, give to Kathy Kahl, by October 12. Three forms will be needed. Tomorrow assign who will be emissary for what for requirements gathering. Integrate the EBU and Chong documents. A working group that does analysis and turns things into requirements for committee action. Committee are the primary consumers, but the Daisy and book community are also consumers of the data, because they must know where we are headed. Each of our "big problems" must also be broken down by someone into submission requirements. Friends are strongly encouraged to also participate in requirements. Analyzers include Dolphin, HumanWare, Kathy, Marcus, Lloyd. George had more questions about the idea of completely preserving the image of the book. Kathy suggested that we all give her some kind of requirement. By tomorrow after lunch. A description, rationale, source, source type. Modularization: Technical work is going to continue through March. Assumption is that the big problems are valid. Many other things we could do in additionmodularization and profiling. Audio codecs research could be done now. Spec is a little hard to be modified, could be written in W3C specML grammar. Could also proceed further about changing to schemas. The modularization working group: They didn't work on DTBook, but on the spec and on the books as a whole. Marissa presented the report: She, JP, DL, MD and Julian. This document was sent to the Zed architecture list. Did we read that report? She went through the report, as summarized in the following paragraphs. They looked at modularizing and profiling. Current Zed spec is conceptually modular, but the document is still a monolith. For a Daisy book, what content does it have, how do people navigate? Single medium? If multimedia, what glues them together? SMIL was the only thing suggested. What kinds of text, audio, images? What are the semantic roles of the navigable items? Do those roles have properties that relate them to each other? Such as nesting? How do you navigate to them? Three possible profile ideas: distribution-related: Lightweight profile. Customers want even less-expensive players than the current ones. Cell phone, MP3 player? Low overhead for player processing. Profile for text only and also one for audio only? For those, remove the SMIL requirement. Navigate to the files directly. Text could be plain, audio could be plain. Offsets to navigate into each. Medium profile: Purpose to maintain approximately what we have today in Daisy formats. Makes tools easier by avoiding some of the proposed complexity. Basic SMIL files;headings and pages, URL + fragment identifiers (u#f); no skippable structures, so this realy profiles a cleaned-up version of 2.0.2. Super-awesome profile: Math, video, DTBook, XhTML, Xpath instead of just U#f pointers. Perhaps open to more DTD's of text. One problem with the arbitrary XML is how do you create layout that is a faithful visual representation of it? Put on a single media all three profiles, the player and user select which one to render. Or if streaming, do content negotiation. Why didn't the medium profile include a little more? Medium profile shold be easy enough for an authoring tool to be developed. Don't get hung up on those exact profile definitions. Authoring tool could create the profiles less complex than its native profile. Can the simpler profiles be automatically derived from the complex one? Yes. No new data required to create the simpler profiles. Requirement to create a transcript for the video, for example? Next spec should include all of the profiles, and a path to upgrade existing content. Navigation should become a little more generic than the NCX. Separate the semantic roles from the media types. Navigation roles might be defined by the roles found in the content. Need examples of that! How do devices find their books? What happens to the packaging file or other mechanism. SMIL has the system-required attribute which tells a player what profile it must deal with. Now what? Awaiting instructions from the whole committee and requirements process. Relationship of these profiles to IDPF pieces? Doesn't work as well as it might. Should Daisy consortium recommend the IDPF format? IDPF allows some alternate formats, as well as XML islands, in the current version. We could have an IDPF profile. Adobe can create IDPF content with their latest software. Marcus asked whether we need to define the profiles first before we begin defining the modules? In the mod squad, there was some talk about regions and how they fit into these profiles. A profile should pick one format from each of the modules. More than one navigation module? Probably. ID3 consortium is working on updating their "standard" to allow navigation between files. Then there are cue sheets. Why did they have to develop a standard for scrolling lyrics when we can already do it inDaisy? DivX movies, for example. There are a lot of nonstandard formats which are widely used but were not standardized through a "standard" process. Do we end up with one spec with modules and profiles? If we modify a module, then the whole spec needs to be updated? Or better that each of them be its own spec?Math and DRM didn't go through NISO, but they are definitely modules already. Spec is not just a description of the super-awesome profile. Perhaps we need to bring the DRM specification to NISO. There will be an NFB-called conference November 12 about accessibility of eBooks. Several recommendations could come out of this meeting. How might the DRM spec need to be changed to eet publishing industry requirements? Can we get other industry to help us build some of these modules? Would we trust that process? Think of DRM as another module. As far as text goes, the mod squad didn't really say if it was ASCII, UTF8 or what? Plain text is a vague term. Next steps: Research on modularization and profiling should continue to be done until the requirements process finishes, end of March? Do we assume that we really want to do this? We probably do. James and Marcus think it's a good architecture. But how much should this committee control, and how much come from other groups outside the NISO/Daisy process? Someone could come back with a chemical markup addition or a TEI addition. We almost certainly need a generic extension algorithm for this spec's modules. Normative rules on describing roles. Rationales for the various profiles. What constitutes a valid profile as submitted by someone outside Daisy? How do these profiles work with respect to fallback? Need a generic fallback algorithm. What other profiles do we think might be useful? Can we come up with some that don't carry more than necessary overhead? An interactive or educational testing profile? SMIL people will especially have to be involved in the work for the more complex profiles. Propose we continue the mod squad until end of March. Further work on modularization. More elaborate examples. Begin to flesh out the light-weight profile, limit its problem space. Is there more than one way to do the light-weight profile? Not tied to a specific text format. Add Ole, Marcus to the squad, Marissa thinks. Before we end today, clarify what the squad will exactly do. Any other type of technical work that should happen before March 31? Audio codec strategy development team: Domenic, Colin from RNIB, Lloyd. Issues of royalties, quality, etc. Daisy consortium may not be able, as a standards-setting organization, to negotiate codec licenses Need a white paper about these options. AMR-WB+, Ogg Vorbis. Audio Engineering Society has asked Daisy about audio codecs for talking books. Mod squad will not be working on the DTD/schema debate just yet. Julian suggested RelaxNG as a schema source. But Marcus pointed out that schemas don't really solve the research problems we must still solve. How do we modularize DTBook grammar? Other things. MathML doesn't need urgent changes at this moment. Zed spec stilll needs a good generic extension algorithm; math extension is not necessarily the best example for the next extension. A braille extension? An online profile for the next Zed spec? We may see activity on a workbook extension or at least create a workbook activity. How do you represent a workbook in the Daisy concept? How to subset properly? Standard place to put a longdesc for an image, as there is in HTML. People don't understand why we call it a prodnote. Supplied by the publisher or the follow-on agency? Is visual presentation well-enough covered in existing standard? RNIB wrote their own DTD after finding deficiencies in DTBook. Daniel: video work that was done about longdesc. There are many uses of video. But what should be the scope of any Daisy video work? SMIL extensions may have something to contribute to this. Should there be a video working group? Can people get together and begin describing the existing standards? Have enough wheels been invented already? Timed text is already out there for captions. Daniel feels it's premature to submit requirements; he will submit scenarios. Autism training work that has been done? They use text whose glyphs are displayed as pictograms. George mailed us the Braille in Daisy DTD. Work assignments must be more completely verified and committed to by the group.
3.4 Profiles/Modularization -
Tuesday
Morning October 2, Julien Scribe
The DAISY SMIL profile (Marisa, October 2, morning) - Notes by Julien Quint
The profile should represent a DAISY book. Nearly at the end of the
process(candidate recommendation soon). Work by Marisa, Daniel, Hiroshi and Julien.
The goal is to formalize our use of SMIL and improve on SMIL itself to
better represent our needs as we are the biggest users of SMIL outside of
academics and research. But we use the smallest amount of it.
# Example: the "Climbing the Highest Mountain" book (skippability example)
reformulated with the DAISY profile. The SMIL content is modified by:
* adding metadata (next and previous; for navigation)
* adding text parameters to define how the text is rendered (displayed
in context, highlighted in yellow) rather than rely on the default
behavior of the user agent. We use the param mechanism of SMIL and add our
own param names and values in the DAISY profile.
* adding layout definition to the document (layout is an old SMIL concept
but we're starting to use it now) so that we can define the size
of the text region, and to which region the aforementioned text
parameters apply.
These additional parameters are intended for regular SMIL players,
but it is expected that DAISY players would respect them as well.
Skippable elements in the presentation (page numbers and producer notes)
were implemented using systemText/customTest in SMIL, but that was very
limited; this is replaced by SMIL State which allows for better control
logic. State has no required data model, but we use the XForms data model.
We can then declare default values (playPageNumber and playProducerNotes are
both true by default for this presentation.)
In the presentation, we add "role" attributes on <par>s to mark sections,
and text elements have a region in which they are displayed. The role
attribute replaces class to mark semantic role of SMIL containers.
The "expr" (expression) attribute is added to producer notes and pages, to
test whether the given container is to be played depending on the state
variables that were introduced above.
We need to define state variables that we want to have. The SMIL document
provides default values for these variables, but the user agent should let
the user change their value.
Roles and expressions are different; for instance, we can have optional and
non-optional producer notes so that only optional producer notes could be
turned on or off using the expr attribute.
We need to define DAISY roles as well (e.g. section, pageStart, etc.) and
how they can be used by user agents. In the next spec version we can define
a role grammar outside of the SMIL profile itself, and apply DAISY navigation to arbitrary XML.
[Markus sent a link to http://www.w3.org/TR/aria-role/ (Roles for
Accessible Rich Internet Applications]
# The label attribute is used instead of longdesc (too vague.) For instance
we have label="labels.smil#text" which points to a separate presentation
with prompts. This is like a resource file but expressed in SMIL.
Multilingual labels can be implemented with this (several files, state
variables, e.g. label="{lang}-labels.smil#text" where lang is a
variable which value is the name of the user's preferred language, and there
label files such as en-labels.smil, fr-labels.smil, etc.) SMIL labels can
also be imported in the NCX later.
# Specific renders for media object: use tts or braille to render media
data, in some specific cases. Additional parameters can be specified.
This comes from MathML where the braille markup is specific, so different
data needs to be sent to a braille renderer. The list of media renderers
is not complete, and additional parameters need reviewing.
Who controls the layout? SMIL or DTBook?
# Example of a quiz (using state):
* First screen is a title screen ("how to wrap a present")
* Second screen has text and images
* Next screen has the same view, pushed to the left, with a video on the right. The video has captions.
* Next is the quiz: a question with two buttons for answers.
* The user picks one (selection is rendered in some way)
* The second question comes up on the same region than the first.
* Last screen pushses the answer the left and shows the score on the right.
I am not reproducing the SMIL source as it's really big. It:
* describes the layout (many regions for the different layouts) and state variables (score, answers)
* uses different renderings and XML Pointer to point to textual content in an external XML document
* uses CSS rules to only show some of the data (the XML data also has answers)
* uses SMIL text for inline text
* uses labels
It's pretty hairy.
# In summary, the new stuff:
* State logic in the SMIL file
* Use switch to specify fallbacks
* Point to external files using XPointer in addition to URLs with fragments
* Sequence of SMIL documents using metadata (previous, next)
* Semantic roles on SMIL objects
* Multimedia label on the SMIL object
* Specify text highlighting style in the document
* Display text in context or show text fragment by itself
* Specify a renderer for a particular media object
* Use regions to define layout
* Support more linking (<area /> as well as <a>)
* Support <video> and <image> in SMIL
Things the group needs to do:
* Choose renderer parameters
* Choose presentation variables
* Do we want SMIL text?
* Give feedback
* Talk about the label attribute
* In the next spec be more descriptive about the player behavior
The profile spec can be updated independently from the SMIL language
itself as long as there are no language changes.
4. Braille Discussion -
Tuesday Morning
October 2, Boris Scribe
DAISY Committee meeting - Tuesday 9:00 AM - notes - Boris Goldowsky Kathy has completed form for requirements submissions. Our "homework" requirements are due by lunch time to Markus. Braille in DAISY discussion Lloyd, Pete, Lynn, Moira are on the BiD list DAISY spec has always been intended to allow for multiple outputs, including Braille. But how to actually transcribe it into Braille? Can automated systems handle Dtbook? What more has to be done by transcribers? Lloyd worked on informal Duxbury stylesheet, but not adopted widely. Meanwhile, books contain ever more information that doesn't come through a structure-only DTD, so a lot of work is left for transcribers to do. And a lot more going on in other countries too -- BiD group is international. First effort led by ghBraille faltered. Next effort led by Joel Håkansson also did not get far. Now, a new list, led by Sean Brooks, with more structure, is beginning to come back with recommendations. They have asked us for feedback and we should provide as much help and guidance as possible on how to make DAISY work well for Braille-specific needs. Pete - need to eventually interface with Braille engines; talk with vendors. Different Braille authorities have different standards -- the only internationally standardized area is the most difficult -- Braille music. Key things that may be required: - a page information line (what section, page #, etc), like a running header. - a marker to show a volume division in Braille? - somewhere to put information about page size (eg, lines and characters) - a way to note code switch, or not-to-be-translated regions (eg, proper nouns that should not be contracted) To avoid: - exactly how TOC is formatted, or pages are layed out. George: WG has focused on semantic items that they feel are underspecified in Dtbook, but formatting-specific items have a way of creeping back in. Attempts to bridge differences and create consistent formatting internationally have failed after years of committee meetings. Has even been difficult to make headway on joining two formats in American Braille - literary and textbook. There is a lot of resistance to change. Also, guidelines are sometimes based on aesthetics, not research showing what is usable. Many feel we may be able to do most of what is needed with current Dtbook. Eg, page information line - could be a country-by-country decision to use something like the chapter title + page number, automatically extracted. Page size, we may not even want to put in Dtbook; it's format, not structure. We need to focus on what the best thing to do for the future is, but we will certainly get disagreement. Central question: can you maintain Dtbook all the way through the process and use that for all your different outputs? If you make changes for a Braille problem, does the fix help clean up your large print edition? Don't want to fork the source file at any point. Dtbook has no TOC element, or index element. But these are not purely Braille issues - identify semantic items. Similarly, no acknowledgments element - but in some formats, acknowledgments need to be moved to a different location, so needs to be identified. To give transcribers what they are asking for, need to provide good translation from Dtbook to RTF. Can we do completely automated translation to Braille, or is a manual step needed? Volume breaks sometimes need to happen in very specific places, and things get moved/shuffled in very intricate ways. May need specific namespace for markers? Volume breaks will be in different places depending on page size, note location, etc. Clyde: In NZ, have produced automatically, but require multiple passes. After first pass, add specific markers based on problems in output. Still single-source document, but with rendering hints. James & Markus: could layer markers (eg, volume break here, or "don't contract" element on span) in a separate namespace. Attributes like this would be ignored by processors that don't understand or need them. Other elements like TOC, perhaps endnotes, that are useful for other formats, should be incorporated into Dtbook. Braille group should identify these type of items; we will define markup for them. Markus: Other groups have suggested additional element types. But if we start including many, we would be changing the nature of Dtbook. Right now Dtbook is monastically sparse, HTML like. We may get a waterfall of new proposals if we start adding elements like this and turn into something like TEI which has 2500 elements. If we modularize Dtbook, we could incorporate modules from other grammars. Eg, the table module from HTML; perhaps TOCs from TEI? Would be better to import these properly rather than copy them and call them part of Dtbook. So, do we put TOC identification on our list of requirements? But they need these things now -- can they wait for us to get around to next dtbook revision? 90% of world (but not Scandinavia) is using Duxbury systems. Need Duxbury to implement this. Clear direction: formatting hints as empty, namespaced elements. But for structural items, what to do? Class attribute, new attribute, new namespaced element? For globally useful elements, request that they submit requirements to us for standardization. We would like to see full scope of what BiD needs - first, identify high-level elements that are necessary without going into details of content model. Prose probably better than DTD at this point. Develop an analysis document of needs. It would be interesting to compare to needs & problems of people doing (very) large print - eg, similar TOC requirements. This would be important part of our requirements gathering process. In this, try to stay above the level of national differences. Eg, page information line may have different contents, or not be needed at all. Boris: should we use CSS for braille-specific formatting directives? Lloyd, Moira - Or should we use things like code and samp? Marisa: or can software detect what should not be contracted? You always need some way to correct automated systems' errors. George: action item is to put together a reply to Braille in DAISY group. Pete, George, Lynn to do that in the next week.
5.0 SMIL Profile, Requirements, Planning
-
Tuesday Afternoon October 2, Romain Scribe
Tuesday 2nd - Afternoon - Romain Deltour ----------------------- ## input gathering for the SMIL profile: Markus suggested to have a DAISY book sample in the SMIL profile spec. ### Presentation variables (e.g. playProducerNotes, playPageNumber) & Label attribute MG: warns against having an enumeration that locks us in the book paradigm. DW: Use a namespace ? JQ: there is not necessarily a need to specify it. => we want a label used by the user agent to expose the presentation variable Example: <data xmlns="expose-to-user"> <playPageNumbers label="labels.smil#page">true</playPageNumbers> <!-- label says "play page numbers" --> </data> How the user agent would know which of this variables to expose ? How to identify which items are target for skippable structures ? Need to define roles clearly, some roles can define skippable elements. The problem here is to define a generic mechanism to expose the variable to the user. Skippability is a particular case of the presentation variable, we can have a "daisy:skippable" namespace. MD: should a label be associated to a role ? Having to specify a "label" attribute each time we use a "role" attribute is redundant. Could be part of the taxonomy defining the roles. Markus asks whether the XForms data model support the previously discussed requirements. SMIL wg members answer it should be feasible in the DAISY profile, to be confirmed. ### Highlight style Limited to CSS 1.0 Special style for the first character ? We can't use a CSS pseudo selector because we only use properties. JQ: We can have our own custom property. Is it better to use a boolean "highlight" and let the user agent choose based on user preference ? DW: tempted to drop css-highlight-style and let the user agent do the job. JQ: the current attribute allows us to just feed CSS-compliant user agent with the properties. Problem: The user agent is probably the more able to know what the user prefers for highlight (e.g. high contrast). It shouldn't be the responsibility of the document author. There's definitely a requirement for defining the highlight, if we drop it in the DAISY profile, we must make sure it is specified somewhere else. It seems easier to have it in the SMIL rather than in an external CSS. => consensus: keep it in the profile, rethink it if nobody uses it. ### smilText Created by SYMM to be able to add simple inline text in a SMIL document (e.g. captions, labels). Design goal for smilTest is "keep it simple". Captioned videos to be considered by DAISY: in SMIL doc (using smilText) or in an external doc ? GK: DAISY-compliant players will deal with text pretty well, no need to burden them with additional text format. => consensus: don't use smilText for now. ### display-in-context DW: still seems to be ambiguous. How would it be implemented ? LR: as an author, you can expect any particular behavior from the player. Let the user agent decide what the context is. Note: Example of the quiz / test is irrelevant to DAISY, which targets print books. What's the relation between W3C's DAISY profile and the future Z profiles. W3C Profiles tries to define how to use SMIL in the DAISY context. It will probably not used as it is in the next modularized spec. MD: the next spec may have direct references to SMIL modules and use W3C profiles. Check with SYMM how this is feasible. MG: we'll have to find a way to restrict the current profile. ## Requirements gathering Define roles: who does what ? who goes where ? Boris started to gather a list of contacts. @George, Markus and Lynn: write an overall introduction letter/document for people we contact. @Lynn: announce to the lists once the document is written. Start date ? Now (on Thursday) @Kathy: update about the state of her work on the web site. see http://daisy.org/z3986/requirements/ ### Submission form GUI If it's ready for thursday, let invite anyone to submit to the requirements site. Even fill a form during Rob's session. MG: GUI for submission should be either requirement or scenario. We want it to be as simple as possible, don't force anyone to submit a requirement along with a scenario. Admin get the list of submitted requirements and scenarios, finalize it, and make them appear on the public site. Even rejected submissions. Make clear that "accepted" means "accepted for consideration". Link to previous EBU and NLS documents (see mailing list). Add a vote mechanism ? Now or once we have the final list ? Be sure that all votes are honest. It's a good idea to enable comments on the submitted data. => add a commentary thread at the end of each submission. It's more likely that non-techie people will want to submit scenarios, and the Z-Committee is responsible for extracting requirement from it. WG to finalize the submission form: Lynn, Markus, Kathy and James. Consensus on allowing anonymous submission. The email address of the submitter is used to send a report and keep track of the submission status. ## Announcement / Outreach Contact lists The announcement should go in the following areas: - NISO - WAI - Daisy - NIMAS - EASI - DTB Talk - PTR user group - AFB solutions form - Ahead eText group - European Accessible Information Network - FEP - International Publishers Association - EBU / WBU Technical Committee - IFLA - Google Book Project - Daisy Planet - ATIA Outreach list: - George: NSET (center for supported e-text), IDPF, Google Books, WGBH, Project DOIT - Boris: Richard Jackson - Moira: Round Table, Achieve, New Zealand Dyslexic - Daniel: see his email on the Z mailing list - Hiroshi: ask him about his contacts (UN, etc) - Lloyd: Deaf blindness Consortium - Thomas: Danish Disability Council and Danish Disability Organization - Lynn: Canadian DAISY Consortium, Utta University of Toronto, Marie France Laughton - Markus: Swedish Dyslexia Association Julien to look at the requirements related to i18n. Pete to gather contacts at the Publishers Industry Action Group (UK-only). ## Timeline & Resources GK: How often do we want to have calls ? MD: break calls up by sectors / working groups. - a monthly call for the whole group - an extra call focusing on requirements gathering Next calls: October 24th, November 7th, 21st... Requirement gathering closes on March. => Meeting to be planned in April for the analysis (week 16 in the US ?) Modularization Work: ModSquad (including Ole and Markus) continues its work and goes into details based on the audio lightweight profile. Rapid prototyping. OHA: Or the medium profile MD: better pick up 2 profiles => Meeting in the US in January Timeline: The timeline till March seems reasonable. The general timeline should be updated starting from the Copenhagen minutes. Resources: What other resources could be used to manage getting things done in the 2009 timeframe ? Lynn: Jennifer could help with formatting / extracting requirements. Rob: currently 2 resources in Braille in DAISY, 1 in codec work Roles can be defined for consultancy: how much would it cost, how long would it be needed ? ideas: - spec editor - XML guru
Version 3