From zedwiki

Note: this meeting will be held at 2100h UTC. Find the meeting time in your geographical location.

Present

Markus (scribe), Per, Matt, Boris, Sam, Christian, Kenny

Regrets

Josh, Dennis

Previous Telcon

ZedAI_telcon_20100118

Action Items

New

@markus: summarize number element discussion to list, assure possible connections to Dennis' "simple math" expression are covered

@markus: on meta+properties for braille/formatting annotations: summarize to list

@markus: check with Joel re homonyms in BiD

@Christian: check with Mr Waldfogel re suppression of emphasis: one-by-one or following a pattern?

@markus make sure we have an issue in the tracker to populate vocab with properties for names

Brought Along

• matt: review inline markup in bibliography, glossary, index {ONGOING}
• kenny: send summary of use case for continuation indicator to list.
• markus: close issue 44: deferred until proper Braille Feature is built. (see below however)
• markus add issue to tracker: may be necessary with publisher address in inline reqd metadata.
• dennis find out if math:switch supports mathml-for-css
• dennis, on MathML_ what symbols are used to denote the switch types? point us to where switch is explained. Need to figure out relation to our content selection feature.
• markus: add math role to vocab, add prose to MathML feature doc that explains its restricted use.
• markus check how math/@id and else/@xml:id works in RelaxNG and XSD.
• markus investigate pros/cons of going back to using id?
• Boris: start documenting object and annotation {ONGOING}
• Boris/Markus - ask ViewPlus et al about the SVG namespace-inject issue [ONGOING @markus]
• Kenny - own the page continuator issue (note, we have a similar lurker in terms of running heads)
• Boris: help deal with svg integration, help with object documentation and samples, address issue 9 [ONGOING]

Agenda/Minutes

Welcome Christian Egli, SBS

Refactoring Status Update (short)

Impacts on the timeline

• markus will be making a commit by the end of this week containing the "abstract definition" refactoring
• matt will work intensely with markus during feb
• should be no problems to meet end march deadline for public draft

This weeks Braille Issues

Reminder:

• the intent with ZedAI is to have a grammar that allows (but does not require) a 100% automated production process; this intent includes Braille
• the core grammar should be as expressive as possible in terms of generic (non-output-format-specific) markup
• there may be good reasons to produce a Braille Feature (with output-format-specific markup), but we are not doing that now.
• (because Braille varies so much between locales, a single Braille feature may be a suboptimal solution; perhaps locale-specific features will be needed)

ChristianE :intro to markup requirements for german/swiss braille

Christian to introduce us to particulars in german swiss braille markup

Proper names

need to be contracted slightly differently

Homonyms

Depending on the semantic meaning some contractions are not allowed

Ordinal numbers

need special announcements

ISBN

Replace hyphen with dots

Phone numbers

Replace spaces with dots

Polite form

capitalization (usually German Braille is not capitalized)

Date

Dates are formatted specially

Time

Dates are also formatted specially in order to increase legibility

Language

for old and new spelling you might need a different Braille translation table. OTOH you could argue that the Braille table needs to handle both spellings.

Discussion:

• which of these needs are general enough to be considered matter for the core grammar?
• ... and which are 100% braille specific, thus not matter for core

Notes during Christians walkthrough:

• What are polite forms? A person addresses the other person, would be the pronoun.
• Homonyms: still not found a way to deal with this properly, currently "dont contract" is the markup added
  • @markus ask Joel what BiD did about homonyms

Already supported (?):

• time element: Christians date and time entries should be covered by this
• name element: represents any name; but @role can be used to refine, for example: name role="personname"
  • @markus make sure we have an issue in the tracker to populate vocab with properties for names
• numbers : discussion on adding a number element using @role for refinements
  • Boris: does MathML cover this?
  • Christian: ISBN and phone numbers could be grouped into one as far as we are concerned
  • Christian: markup to disambiguate periods is generally interesting, not braille specific
  • Matt: in BANA, numbers are reformatted too
  • all to identify the element name and its definition, and a list of properties to use in @role
  • Markus: get Dennis into this discussion
  • Per: But think wider than just numbers; what about zip codes, vehicle registration numbers, etc. Mix of digits and other symbols.

Remaining not solved:

• homonyms (still arguing how to solve it). Markus: sounds 100% Braille specific
  • Kenny: in UEB we use a grade 1 indicator, saying the whole word is not to be contracted
  • Christian: our case is more difficult since we still do contract
• polite form adressing
  • Markus: would a property in the vocab suffice? Christian: sounds reasonable.

Christian: additional thing: sometimes need to suppress emphasis markup in braille markup. @christian check this out with Christian Waldfogel and get back to group.

Running Headers

See issue [44].

Emails: (archive)

 So, here's the problem (as I understand it now):
 - running headers in braille pages cant be autogenerated in all cases because there are contractions, abbreviations and stuff going that need the human touch to be done right
 - the "header string" that is created needs to support markup (a plain string is not always enough)

 And here's how we perhaps could solve it:
 - our head/meta element supports expressing properties not only about the whole document, but also about specific fragments of it, using the about attribute.
 - our head/meta element allows the "content" (the object of the property) to be expressed either using the content attribute *or* element content (you can have markup inside a meta element) 
 - we have an extensible property mechanism through the use of external vocabularies, and can create a property for custom running headers (in an output formatting specific vocab, or even in the default vocab for all I care)

 So, assuming that the running header content is static per section (part, chapter, subchapter, and inwards) we should be able to express head metadata about those sections thusly (where the values of @about refer to IDs of  sections):

  <meta about="#chap1" property="format:braille-running-header">
    <line>Chap1<emph>foo</emph> bar</line>
  </meta>

 Very interesting way of solving the problem!

 I don't see anything wrong or bad in this approach; the only thing that we are doing is pressing ahead beyond what any braille 
 transcription program is capable of (i.e., we're setting a bit of the direction for how software will  have to be developed). I don't 
 think that's necessarily a bad thing, though, because we're still in the realm of providing the information as pure markup (as 
 opposed to requiring a new technology to be plugged in, like when we discussed css parsing).

 There would also be braille volume and page numbers in the header, but those would be dynamically generated by the 
 transcription software as part of the formatting for printing (the running headers can be handled separately).

 For a "global" running header, would we set aside a keyword like #DEFAULT, or would we require the body tag to be 
 ID'd and referenced in the same way?

 Matt
 

Kenny: asked VA braille experts about variables, they could not think of any such.

Christian: can this not be automated? Markus: well, in some locales I think it can, but not in all locales. Both VA and CNIB as examples uses human transcribers to produce meaningful contractions.

Christian: In LaTex you can define a short version of the section title, this might of interest here.

Kenny: VA talking newspaper service uses volunteers; supposed to enter information into data generation application that will eventually generate ZedAI; this will eventually be uploaded to our servers for autogeneration of DAISY and Braille. This data generation app will have a "running header" field. This is one use case.

Remaining MathML work

This issue lingers here til next time Dennis joins

• Math role to vocab (see z3986-core.n3)
  • other similar properties to add?
  • prose to Math RD about the limited use of the role property
• built-in math:switch versus our content selection feature? Think we should choose one. Important to support copy-and-paste.
• (dennis) does the built-in math:switch support mathml-for-css?

Reminder: Dennis on MathML 'dialects':

The variety of schema choices permits use of particular subsets of MathML 3.  As with
MathML 2, MathML 3 provides two major "dialects" - content and presentation.  MathML
3 adds "strict" and "pragmatic" variations to content MathML.


So which schema fragments to use will be determined by which type of MathML we
support in Zed Next: Presentation, Strict Content, or Pragmatic Content.


I suggest we take the same approach as in the existing MathML-in-DAISY spec. It
states that Presentation MathML MUST be used and Content MathML is optional via
parallel mark-up.  In parallel mark-up both Presentation and Content MathML are given
and the rendering agent can choose between them.


If we take this approach, then we should use either the Presentation-only schema or
the complete schema.  To use the Presentation-only schema we use:


include "mathml3.rnc" {MathExpression = semantics | PresentationExpression}


according to http://www.w3.org/TR/MathML3/appendixa.html#parsing.rnc.module.  To use
the complete schema we use:


# A RelaxNG Schema for  XHTML+MathML
include "xhtml.rnc"
math = external "mathml3.rnc"
Inline.class |= math
Block.class |= math

Next call

Monday 8th.