ZedAI telcon 20090216
From zedwiki
Note: The 16 February 2009 meeting will be held at 1400h UTC. Find the meeting time in your geographical location.
Contents |
Present
Present: Stephen, Kate, Kenny, Markus (scribe), Sam, Marisa, Per, Dennis and Josh, Ole
Regrets
Leona, James
New Action Items
- Boris: post minutes from previous call
- Kenny: invite Marisa to this wednesdays periodicals call 1:AM
- Dennis: produce XForms+XHTML2 workbook examples, put on Wiki
- Marisa: find Dicks and Jacks presentation on SMIL+XForms
Previous Action Items
- Dennis to post information about QTI to the list.
- kenny to post information about the leads to the list.
- Stephen to assist in documenting the elements in the Zed AI profile suite.
- Markus fix ZedAI main page, start a ZedAI Overview page (postponed, Markus is working on spec prose first.)
- Sam - gathering sample documents.
- Kenny - gathering sample documents.
- Markus to contact Oxygen for possible free licenses.
- Markus to invite people for profile testing.
- Markus to ask the DAISY list about how newspapers/periodicals markup is currently being done.
- Gregory to research mechanisms for local extension of taxonomies
Agenda
Metadata status update
- Background: ZedAI_Meta_Data_-_AI_Working_Draft and ZedAI_Meta_Data_-_Status_Report
XInclude report review
http://www.daisy.org/zw/XInclude_Analysis
XForms/QTI
As per email thread started with Dennis' email "some overview questions"
AOB
Minutes
Metadata status update
We hold this item until Matt makes it to the call.
Periodicals Update
Kate has compiled the concepts information, will post Wiki information soon
CMOS concepts on journals needs to be put in place. Marisa to help out.
@Kenny invite Marisa to this wednesdays periodicals call 1:AM
Markus: SVN skeleton for periodicals is available at SVN, same thing true for advanced book profile
Markus posted link on SVN and build system setup, please notify Markus on missing items in the documentation.
XForms/QTI update
Dennis: we need to decide exactly what we are trying to accomplish? Is the scope just to capture print book content, or expand to interactivity etc.
Markus: need to remember the output agnostic goal of the AI design. Still, limiting to XForms View part only will make the source XML incomplete for eg DAISY output. So perhaps another approach is to allow the entire XForms (+Model +Events), and make it clear that parts of the content can be ignored by certain output formats such as braille.
Dennis: We need to have more discussion on how much interactivity we can include. Also, SMIL issues need to be resolved.
Marisa: SMIL state allows tracking of values. It does not deal with the presentation layer, relies on UA for this. Smil state can share its model to other applications.
Kenny: I did not think that XForms was something that we could use in the distribution format, not in authoring format. But I found that it is modular.
Markus: Key questions to answer: can we use only XForms View Module in ZedAI and delegate to output format rendering to decide what Model impl to use?
Dennis: the XForms Model element is convenient, supports multiple models etc. Acts like a manifest or a template. We probably want to include some of that.
Markus: so we could look at this as a declaration of the needed model; it can be replaced by output renderers by other models (such as SMIL State for DTB output).
Dennis agrees with that view. Hence the hypothesis to allow xforms:model and XML Events (the latter to a yet unknown extent) in ZedAI with declarative intent.
@Dennis: produce XForms+XHTML2 workbook examples.
Dennis: will look at QTI as well. May be more elaborate than what we need. Its really intended for online testing.
Kenny: there is an XForms implementation in Lotus Notes.
Marisa: ... and a plugin for Firefox.
Kenny: XForms 1.1 is a CR. Markus: thats the one we need to focus on. A dependency of XHTML2.
XInclude
(A brief discussion was held in the regrettable abscence of JInclude Pritchett.)
Markus: Does it adress our needs?
Ole: doesnt solve DOM problems
Markus: its the choice of processor thats the core problem. In an Authoring context at least, this problem can be pushed to the tool implementors and hardware configs.
Markus: In the distribution context, Epub uses a max size treshold recommendation to circumvent DOM-size explosion in UAs (which typically depend on browser widgets), which has resulted in Epubs typically being distributed in a one-file-per-chapter fashion.
Stephen: sometimes we divide into sections when rendering the output, which doesnt keep us from keeping the source as one document
Summary
- XInclude covers the collective editing use case (and should therefore be allowed in the standard), but it does not help with the size/performance problems.
- Alternative solutions:
- use the epub approach (for distribution): mandate several valid complete documents. For authoring, ignore the problem.
- drawbacks: the content doc is not longer a tree (and is that a problem? It was with DTBook, but must not be in ZedDist)
- invent our own fragment inclusion mechanism with the option of not loading all parts by default
- drawbacks: is a very low level interception on our part, and will never work with off-the-shelf processors. Further, ZedSpec implementors would have to do a lot of low level work just to get hold of the entire document instance. Cost may be higher than benefit.
- use the epub approach (for distribution): mandate several valid complete documents. For authoring, ignore the problem.
Stephen: XML TWIG seems to be addressing this problem.
