ZedAI telcon 20100208

From zedwiki

Jump to: navigation, search

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

Contents

Present

Markus (scribe), Josh, Boris, ChristianW, ChristianE, Matt

Regrets

Kenny, Per, James

Previous Telcon

ZedAI_telcon_20100201

Action Items

New

  • ChristianE: add all issues raised by SBS to Google Code issue tracker, reffing wiki pages if existing. [DONE see issues 109, 110, 111, 112, 113, 114, 115, 116, 118, 119, 120, 121]
  • Markus: update num proposal page with more conrete properties, and some kinds of datatype restriction for the value element.

Brought Along

  • 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? [DONE see #emphasis not shown in Braille ]
  • markus make sure we have an issue in the tracker to populate vocab with properties for names
  • 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 Waldvogel, SBS

Refactoring Status Update (short)

In r488:

  • Add new documentation syntax to modules, documented at HowToDocumentASchema. Some cleanup to the syntax used may still happen.

(This rework includes a new approach to what was previously in src/doc; Per's refactoring of user schemadoc still ongoing. Until that is done, the user schemadoc will not contain any prose definitions.)

  • Generate abstract definitions of modules in spec, and Feature Resource Directories (so far, only feature for which this is implemented is SSML). The output layout and syntax (and content) is still provisional.
  • Change the module global classes to five-fold (document, section, block, phrase and text classes) (previous was two-fold: block and inline, as inherited from html)
  • Make the sources for spec examples, doc longdescs and snippets schema-driven to reduce risk for error (see src/spec/examples and src/doc/snippets and src/doc/longdescs).

This weeks Braille Issues

Reminder: list from previous call:

Proper names
need to be contracted slightly differently. See ZedAI_Proper_Name_Proposal. Issue 121
Homographs
Depending on the semantic meaning some contractions are not allowed. See ZedAI_Homograph_Proposal
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). See ZedAI_T–V_distinctions_Proposal
Date and Time
See ZedAI_Date_Proposal for a discussion and use cases

New issues:

emphasis not shown in Braille

in German Braille there is only one form of emphasis, so the transcriber sometimes selectively drops emphasis that she deems not important. This is done on an individual bases and not just for certain contexts.

Markus: correct; we need a way then to annotate emphasis a la "dont use for braille output"

See issue 112

contents move

In Braille we sometimes want to change the order of the contents, i.e. the original ToC should be moved to the end etc. These are not static rules, so need some kind of annotation.

ChristianW: could maybe use some kind of linking in conjunction with the content selection feature.

Boris: could use XInclude and have the TOC externally and use Content Selection feature to make it appear in different places depending on output format.

See issue 113

spacing

sometimes spacing is dropped in Braille, e.g. around an mdash. Do we need a way to mark this up or is this part of the rendering process?

Markus: Is this a static rule? ChristanW: its static with mdash, but not in other situations.

Matt: in BANA same thing for mdash, but ellipses depends on context. Not sure this should handled in markup. At CNIB we built it into a postprocess.

Markus: is that an automatic postprocess? Matt: well, mostly. Ellipses are harder to do with automation.

ChristianE: how do you bring odd spacing requirements in the original over to the Braille.

Markus: could use the Content Selection feature, but would get verbose. Hopefully you can solve this with Unicode...

ChristianE: we will describe the use cases in more detail.

See issue 114

inlines that cross section boundaries

sometimes an italics goes beyond a paragraph boundary but is logically connected. This affects how in Braille the start and the end of the italics are announced. Is there a way to describe that two inlines are logically connected despite being separated by section boundaries for example?

Markus: no way to do this now.

ChristianW: ability to say that one element is a continuation of another.

Matt: could this be done through grouping? CNIB did this with XSLT; check using preceding-element. ChristanE: good way, but it could be that thats an inline that doesnt cross a boundary.

Markus: grouping: we have a "pgroup" property in the core vocab. Would this work?

<block role="pgroup" rend:style="font-style:italics">
 <p>...</p>
 <p>...</p>
</block>

ChristianW: no, the italics can start inside a paragraph and end inside a paragraph, would need to be some kind of start/stop solution.

Markus: we also have the lurking page continuator issue, perhaps could be solved in the same way...

See issue 115

@ChristianW and ChristianE put all issues raised by SBS in tracker, link to wikipage if existing.[DONE]

Towards a num element

Wiki page: ZedAI_Numeral_Element

Issues: issue 118, issue 119, issue 120

ChristianE: how would we deal with ISBN? Markus: <num role="code">{the isbn number}</num>

Matt: "code" may be too broad; braille may have different behaviors. Maybe we need to look at having more specific properties.

Drop the overly generic label, ordering and code, and replace by more concrete properties, included because we know they need special formatting in certain locales.

Towards a complete time element

See ZedAI_Date_Proposal, issue 110 and issue 111

Markus: think we can address this easily by extending the current @time allowed datatypes.

Homograph disambiguation

See ZedAI_Homograph_Proposal and issue 109

ChristianW: the core requirement for Brialle is to have a way to know where a contraction must not occur.

Boris: could we have a for attributes (thinking about two abbreviations spelled the same but pointing to different expansion elements). Would avoid having to repeat for each element.

Boris: does Unicode's zeroWidthNonBreakingSpace work? ChristianE: we looked at it, but seemed to be a bit hackish. Could also have negative effects on other output.

Markus: tricky to find a solution that works for all kinds of output formats that are impacted by this problem

Running Headers

See issue 44.

Previous weeks notes: ZedAI_telcon_20100201#Running_Headers

Index/Biblio (if time allows)

See emails

Remaining MathML work (if time allows)

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

The 15th.

Personal tools