ZedAI telcon 20100315
From zedwiki
Note: this meeting will be held at 1300h UTC. Find the meeting time in your geographical location.
Contents |
Present
Markus (scribe), Christian, Matt, Boris
Regrets
IRC Channel
IRC Address: irc.a11y.org
Channel: #zedai
Previous Telcon
Action Items
New
- Markus - ask ViewPlus about the SVG namespace -inject issue [ONGOING @markus]
-
Matt add a longdesc for num that shows basic examples (perhaps from Christians wiki page), then close issues 118, 119, and 120, with a cc to Christian for confirmation. -
Matt: add choice to code: either linegroup(+/line) or p, block, list - Christian: ask Kenny about clarification of Issue 132 as part of Christians wiki page on continuations
Brought Along
-
Matt add documentation to num module and numeral section in core.n3; longdesc as well (should stress clearly; not used for mathematics) - Christian start wiki page that discusses and gives examples of the continuation IDREF attribute in the context of 115, 124, 132.
Braille-centric
- ChristianW: come up with a proposal for a clear definition of scope distribution between MathML and <num>; use emailing list so Dennis et al can react. (Note that z3986-num.rng also refers to this distinction (line 48)). Note also: this is now Issue 134
- markus: on meta+properties for braille/formatting annotations: summarize to list
- markus: check with Joel re homonyms in BiD
MathML-centric
-
markus: implement MathML changes that we've agreed on so far, and add an issue for the list of the encoding attribute. - Dennis: suggest reasonable set of "ZedAI recognized" values for @encoding on mathml:annotation-xml. Note that other values beyond these would be allowed from a document validity perspective, but tools would not be required to support anything beyond the given set. (Note that the list could be empty, ie tools are compliant without supporting any value). Note also that values for mathml:annotation are also possibly of interest. Note: this is now Issue 135
- ChristianE, remind ChristianW to send suggestion about Mathml vs num distinction.
Other
-
Matt: change the semantics of code to be more generic (not only computer programming, also covering things like morse). - matt: review inline markup in bibliography, glossary, index {ONGOING}
- markus add issue to tracker: may be necessary with publisher address in inline reqd metadata.
-
markus check how math/@id and else/@xml:id works in RelaxNG and XSD. -
markus investigate pros/cons of going back to using id? - @Markus - ask ViewPlus et al about the SVG namespace -inject issue [ONGOING @markus]
Agenda/Minutes
Action Item review/update
See #Brought_Along above.
Matt: only longdesc remaining on num.
Matt: on change the semantics of code: content model mods remain. Thinking of a restricted general list of block level elements. Thinking of adding a choice: either linegroup+line or p, bloc:k, list
@Matt: add choice to code: either linegroup(+/line) or p, block, list
Markus: suggest that we live with this for now. Keep xml:id generally, and allow @id in MathML. (The same applies href attribute, where we have xlink:href attribute).
MathML Feature commits
See r657:
First stab at cleanup of mathml feature schema and resource directory. Needs review. Remaining issues: * add zedai markup as content-xml alternative, excluding nested mathml * @encoding values for annotation? * @encoding value for mathml-in-css? * explicit support for openMath in annotation-xml? * copy over the new W3C XSD when doing Issue 117
- The feature schema now only allows Presentation MathML except inside annotation-xml
- annotation-xml has a co-occurence constraint added for values of @encoding (allows Content MathML only if @encoding has the Content MathML identifiers
- Sample doc
SchemaDoc 2.0
New version out, review comments from group?
None of the present have had time to review yet.
Per:
I have just committed a new version of the schemadoc transform. Please update, and take a look at it. As before, the schemadoc file is located in a schemadoc subfolder to the profile folder. Comments on some of the changes: - The main XSLT file itself is renamed from rng-doc2.xsl to schemadoc2.xsl, and the actual code is spread over several files, all included in the main file. If we want to have it in one single file, that’s a trivial copy-and-paste operation. - Wherever possible (basically everywhere, except for the meta element), I have replaced the listing of RDFa attributes with a link to a presentation of these attributes. - I have rewritten completely the content model presentation (CMP) for the elements. Currently, both the new version and the old version of the CMP are presented, for easy comparison. Eventually, the old one (I hope) will be removed. The new version has a more compact, clearer and less verbose presentation. - If you compare the new and the old versions, you will for some elements (m:glyph, noteref, separator, to name just a few) spot more than just cosmetic changes. Obviously, the old version of CMP was doing a rather bad job in some cases, and I have used the opportunity to fix these bugs. That’s obviously a good thing. The bad thing about is that when I did CMP-old, I was rather happy and satisfied about the work I had done. Now, I have just the same feeling with CPM-new, so it’s likely that there still are some undiscovered errors out there…. Please review the schemadoc, and report back: - any wrong presentations of the schema - any suggestions for improving the language, both the plain English and also the special vocabulary I have introduced to represent RelaxNG grammar (“a mix of” might perhaps not be the best representation of “interleave”?) - any accessibility issues - etc
This weeks Braille issues
Proper Names, status update, done?
Issue 121 is closed and verified
T-V distinctions, status update, done?
Issue 116 is closed and verified
Num element, status update, done?
Issues 118, 119 and 120 still open
Separate Issue (133) for Num-MathML distinction. (Note that z3986-num.rng also refers to this distinction (line 48))
- num module is added
- properties added to line 837 of core.n3
@Matt add a longdesc for num that shows basic examples (perhaps from Christians wiki page), then close issues 118, 119, and 120, with a cc to Christian for confirmation.
Continuation Issues
From previous call:
''We probably wont have the time to solve this one on the call, but as a starter:'' The below issues are related in that they in one way or another relate to the notion of connecting non-contiguous content chunks or points with each other. These issues should be solved using a uniform mechanism. * [http://code.google.com/p/zednext/issues/detail?id=115 115: inlines that cross section boundaries] * [http://code.google.com/p/zednext/issues/detail?id=124 124: paragraph continuations] * [http://code.google.com/p/zednext/issues/detail?id=132 132: articles: page continuation] Boris: would it solve a few of these problems to have a "continues" IDREF attribute? Rather just saying "continuation" with a class Christian: continuationOf would also solve 115 @Christian start wiki page that discusses and gives examples of the continuation IDREF attribute in the context of 132, 124, 115.
Matt (email):
I like the idea of continuations, but I’m not sure if they’ll elegantly solve the problem (except for paragraphs). To iterate and re-iterate a few previous thoughts, embedding objects etc. at the point of the page break is just nasty. As I said yesterday, they have no point being embedded at those spots except for being a slave to print layout. A different print version and that image (or whatever) will be “embedded” at a completely different and equally arbitrary point. This is where it becomes impossible to make meaningful data to represent something that was never originally in a similar form (i.e., the object on its own page probably was an element with a floating layout context in its original source). But the above only adds to the reasons Markus mentioned about allowing everything inside everything. The real problem I’m having with continuations is that they will only work for a simple structure like a paragraph. Otherwise, we need to allow objects, tables, quotes, whatever between list items or between table cells or rows. Or we have to completely end the current structure and re-open it again after. This approach is brutal in its own right and you get all kinds of sticky problems like list item numbering, table headings, etc. having to be restarted but not necessarily rendered. I also have trouble with continuation for emphasis only because we’re going to have to make two kinds of distinction: emphasis that is actually joined together because of an element being broken in the middle of emphasized text and emphasis that is conceptually joined together. If that makes no sense, and I’m probably writing too fast so I expect it won’t, consider that the point of continuation is (ostensibly) to be able to join the split element back to its parent. For a para broken in the middle of emphasized text, first you need to join the two halves of the paragraph back together then you need to join the two halves of emphasized text back together. This is different from a continuation of emphasis where you aren’t joining anything, simply creating a logical connection.
Matt: two kinds of continuations:
* splitting lists, splitting tables, etc, the notion of "merging" * emphasis continuations are a different thing entirely
... with @continuationOf, we are solving two problems with the same attribute...
Christian: agree in the usual use case, we shouldn't be forced to be slaves to print layout.
... but there really is a use case for emphasis that goes across paragraphs.
Matt: prose for @continuation should be clear that that it is not about merging. We need to remove this ambiguity.
Markus: do we want two attributes then? @continuation and '@merge'
Next call
Starting with todays call we are doing 13:00 UTC
Next call is the 22nd.
