ZedAI telcon 20090622
From zedwiki
Note: this meeting will be held at 1300h UTC. Find the meeting time in your geographical location.
Contents |
Present
Markus (scribe), James, Ole, Kenny, Boris, Sam
Regrets
Marisa
Previous Telcon
Action Items
New
- Boris come up with initial set of properties for use in annotation@role.
- markus remove summary from table
- markus change object content model back to dual block/inline
- Kate provide concrete examples and desc of problem to emailing list.
- Markus book date with James for core element set + feature exposed elements discussion
- Markus book date with Per to move on with content selection feature
Brought Along
- markus add all math issues clearly to tracker
- Dennis/Josh contact QTI and ask about replacing the HTML with host language text content set.
- Markus to add spec prose on cascading level for inline styles: "For the purposes of the CSS cascade, these values are considered author-level"
- Markus to create wiki page devoted to level issue
Agenda/Minutes
(Note - ZedAI_Iteration4_TaskLog created)
Item-of-the-week: object/table/annotation (#39)
Email from Boris:
Here's a proposed resolution of tracker issue 39. Disagreements and comments welcome! 1. Table will contain a <summary> element, as it does in XHTML2. Content model will allow paragraphs, maybe other simple text objects (but presumably no nested tables, images, etc). In the most common case, it would be something like: <table>resourcedirectory <summary><p>blah blah</p></summary> <thead>...</thead> <tbody>...</tbody> </table>
2. Objects (such as images) can contain, other than another nested <object>, a slightly wider assortment of text elements - eg, it is reasonable to have a table as the fallback for an image. Simple case: <object src="image.png"> <p>blah blah</p> </object>
3. For the record, an annotation looks like this: <annotation about="#a123" property="republisherAnno"> <p>blah blah</p> </annotation> and is generally *not* contained inside the element that it is commenting about.
Some prose description: Annotations are additional, supplementary content, generally created by someone other than the author of the main body of the work. This may be an editor, translator, republisher, etc, and these are distinguished by the "property" attribute of the annotation element. The annotation also must have an "about" property pointing to the section of the original work that they are commenting on. This enables the annotation itself to be physically and structurally in a different location from its target (eg, a note in the margin or at the end of a chapter). Key attributes: supplemental content, different authorship, out-of-line location.
The fallback(s) for an object are supposed to contain all the significant information content of that object, though in a different form, and they occur inline in the same context; they can be used as a direct replacement by the user agent. Object fallbacks are often added on later by a different person, though that's not necessarily the case - especially if our authoring format starts to get used for authoring as well as for print republishing. So object fallback is different from annotations in several ways: it is primary, not supplemental content, inline location (so no IDREF needed); authorship can be the same or different.
Table summaries are, according to XHTML2, "a summary of the table's purpose and structure for user agents rendering to non-visual media such as speech and Braille." So they are not intended as replacements for the content of the table, they are actually intended more as hints on how to navigate it (is this consistent with what people are thinking of for ZedAI?) This does feel more like supplemental meta-content, thus more similar to annotation. The location is inline, and they are presumably most often added by a republisher. So these seem fairly similar to <annotation>, more so than object fallbacks do. But the suggestion I'm putting forward here is to use a dedicated <summary> element, since unlike annotation, the purpose of a summary is not flexible; it is not optional; it can't contain a nested table; and the name "summary" is consistent with XHTML.
Comments during con:
Boris: this represents a simple solution, accepting things as they are at face value, not trying to assimilate everything into the annotation element.
... tried to unify them, couldnt find anything that worked.
... object fallback and table summary very different.
Boris: html5 wg is talking about this too, in that spec they also do the same thing with object, but explicit that its not a longdesc.
Markus: ok with object approach, but would like to see table/summary be replaced by our generic annotation.
James: summary in table is there for historic reasons, we dont really have that requirement to retain legacy idioms.
Decision to remove summary from table, instead refer to our generic annotation. The role attribute is free for use to refine the nature/subcategories of annotations.
@Boris brainstorm some properties for use in annotation@role.
@markus remove summary from table
@markus change object content model back to dual block/inline
Item-of-the-coming-week
Running headers @Kate provide concrete examples and desc of problem to emailing list.
Periodicals profile: status update
Kenny: decided to create sample documents, Kate and I working on that. Sat down with magazine.
... different to the feeds profile; seems to have resemblance to book profile; toc, frontmatter, titlepage.
Using three components:
1) Concepts from book profile (aka reusing modules that the book profile also uses).
2) Wiki page that amalgamates concepts CMOS periodicals and Kenny/Kates earlier walkthrough
3) Article module from feeds profile; might have to be enhanced.
Feeds profile metadata is not going to be relevant to the periodicals profile.
Ole: in periodicals you may even want to have an article without a head and body. Should probably be a choice.
Kenny: is it possible to do that with RelaxNG. Markus: yes.
