ZedAI telcon 20090302

From zedwiki

Jump to: navigation, search

Note: The 2 March 2009 meeting will be held at 1400h UTC. Find the meeting time in your geographical location.

Contents

Scribe

James

Present

Markus, James, Marisa, Leona, Sam, Boris, Per, Stephen, Dennis, Josh, Kate, Matt

Regrets

Kenny

New Action Items

  • Markus to create wiki page devoted to level issue
  • Markus to open tracker item regarding emphasis, underlining, etc.

Previous Action Items

  • Dennis: produce XForms+XHTML2 workbook examples, put on Wiki
    • Started, not completed; waiting on copyright clearance from publisher
    • Samples in both XForms and QTI
    • Markus announces: XForms+XHTML2 integration is completed
  • Dennis to post information about QTI to the list. (open)
  • Markus fix ZedAI main page, start a ZedAI Overview page (postponed, Markus is working on spec prose first.)
    • James and Markus are currently working on this page.
  • Sam - gathering sample documents.
    • Markus to contact Sam this week regarding this
  • Kenny - gathering sample documents.
  • 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

SVN status

  • Open issues are now being collected exclusively at the issue tracker. Issues with priority high are the ones targeted for current iteration.
  • A refactoring of schema drivers and modules is currently being made to update the collection against the latest version of the W3C schemas. Commit will be made this week.

Kathryn/Leona questions on simplebook profile

Below the email SimpleBook testing - questions & feedback for the group sent at 20090301 to ZedAI list:

Levels

Comments:

It appears that nesting is intended to be used, rather than numbering levels, ie for

  • sections/headings
  • TOC
  • lists
  • indentation

We would prefer that level numbers are indicated, as it is

  • more familiar to the operator (and much easier when marking up from scratch)
  • more transparent. eg a print book may show a heading 3 directly under a heading 1. If the operator does have not a clear way of seeing the heading level in DAISY, they may not realise that a blank section/heading needs to be inserted.
  • more compatible with output formats, eg both Word (for standard print and large print) and Duxbury (for braille) use heading levels

Discussion:

  • MG: Discussion started on list; to continue there
  • Action item: Markus to create wiki page devoted to this issue

Simple Book vs Advanced Book

Comments:

SimpleBook seems quite restrictive, for example it doesn't seem to have the facility to include diagrams. Users will need a very clear definition of the differences between the two book profile types in order to decide which profile to use. It seems likely that practiced users may prefer to always use the advanced profile just in case something extra comes up in an apparently "simple" document.

Discussion:

  • MG: Not committed to two different book profiles. If we do move forward, advanced profile may include math, science, workbooks, etc. Simple book, if it survives will be targeted to more "leisure" reading.
  • MG: Notes that images are currently available in the simple profile via the object element. Whether we use this or some other method is still an open issue, however.
  • MG: When testing profiles, look for things that aren't supported, etc. Send to list first, then can be added to tracker for followup.

Attributes

Comments:

At the moment, all of the XHTML attributes are being offered as options in Oxygen, but no prompts are provided as to the potential values of the attributes.

  • Could any attributes that are not being used please be excluded to reduce confusion?
  • Also, is there any way that we can find out what attributes (and their potential values) are being proposed for the simplebook profile so that we are able to test and comment on them?

Discussion:

  • Per: Information on attributes is included in the documentation, although not necessarily with full details. More work needs to be done.
  • Leona: Found documentation confusing, since they were being pointed from one resource to another, etc.

Braille output

Comments:

The Duxbury Braille Translator, probably the most widely used braille translation program, accepts XML and DAISY input but has some limitations that should be kept in mind: a. Only the element name has any effect on the braille file. Attributes will not be read. b. Duxbury will not recognise nesting as a means of indicating levels. This is particularly important in the case of headings. c. Automatic numbering will not be imported into Duxbury unless it appears as text. This is particularly relevant to headings and lists.

Leona has contacted Joe Sullivan from Duxbury and enquired about their future plans/capabilities for XML input.

Discussion:

  • Matt: Wouldn't use Duxbury at this point for producing Braille from these files; not yet ready. But it certainly can be done in the future with the information we are including in the profile.
  • MG: Will probably need an intermediate step to convert XML to Duxbury-ready files. The key question is whether we are providing enough information to do the conversion.

Metadata

Comments:

When will this be ready for testing and comment? There are some things that could potentially be included either as meta or content.

Discussion:

  • MG: Metadata still an open issue, as is the front matter/title page content models. This needs to be made a priority.
  • Matt: Worried about tying our spec to MODS; they seem to be stuck at the moment. We may need to move on our own in order to make deadlines. We'd create an RDF vocabulary for the subset of metadata that we needed as a stopgap while we wait for MODS, then change to point to MODS when they put their vocabulary in place. This is risky, though.
  • Matt: There will be a metadata call this week, maybe tomorrow

Extraneous elements

Comments:

Are the ruby and standby elements really needed?

Discussion:

  • MG: standby is not need; already removed.
  • MG: ruby is needed and must be included for political reasons.
  • MG: We can generate informative schemas that omit things like ruby for those who don't need it.

Fonts

Comments:

There doesn't seem to be a facility to indicate underline

Discussion:

  • Indeed, there is no support for this in the schema.
  • Could look at this as another form of em or strong, and use @role to distinguish it
  • Dedicated element was supported in early versions of HTML, but deprecated in HTML 4.
  • Do we even need both em and strong? Could we do this with just em and @role and CSS?
  • Action item: Markus to open tracker item regarding this.

finalizing annoref inclusion

Issue tracker: http://code.google.com/p/zednext/issues/detail?id=16

Below Markus' suggestion from list:

  • The module would define an IDREF typed 'annoref' attribute (was element in dtbook) and an annotation element. The use of an attribute for annoref means that the range of the annotation can be set at a preexisting element in the structure, or a dedicated one.
  • Leona's Shakesperian example where there were overlapping ranges is not covered here, simply because the result would be malformed XML. As pointed out earlier, supporting overlapping ranges would require an inversion of the pointing relationship, and a use of something else than ID-IDREF pairs (along the lines of XPointer). Think: <annotation range="xpointer(string-range(//P,"a little hat ^"))">

And while this is something we *could* do because of the flexibility, it is quite complex markup to do, with limited support in authoring tools.

The suggestion for now is to keep things simple in the first version of the module, and extend it carefully later in the process if needed (once real-world testing input is available).

No objections from group; issue closed

new issues to close this week

  • Issues to close (via emailing list) this week.

AOB

Markus will not be present on call next week.

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