Misc. notes from meeting 2007/04/26
Document Actions
div element ...
... will now be added to basic blocks class.
alt attribute for accessibility
At present, authors can supply alternative text for graphics by adding a param child with a name of alt and a value that contains the desired text, e.g.:
<media src="blorgy.png" type="image/png">
<param name="alt" value="The Blorg"/>
</media>
Perhaps ease of authoring for accessibility would be enhanced by supporting an alt attribute directly on media, in analogy with HTML's img:
<media src="blorgy.png" type="image/png"
alt="The Blorg"/>
Other approaches were mentioned, e.g. a separate alt element:
<media src="blorgy.png" type="image/png">
<alt target="print" value="The Blorg"/>
</media>
Optionally, the alt element could enclose further elements to be rendered to the specified target:
<media src="blorgy.png" type="image/png">
<alt target="paid">
<media src="blorgy++.png" alt="Fancy Blorg"/>
<note>Blorgs are fun!</note>
<alt>
</media>
The consensus at the end of the meeting was, I think, that using alt for accessibility is probably sufficiently different from specifying alternative content for different output targets not related to accessibility needs, and that the immediate accessibility needs are best filled by the alt attribute on media. Alternative media files and content for other output targets may best be treated separately, perhaps through an overlay system wired together by XPointers (though that brings with it the fragility of XPointers in a context where content may be updated frequently). The solution to this problem is not yet clear.
Are there other CNXML elements that need alt?
Namespaces
Various topics were discussed under this rubric.
- our present way of using namespaces, namely by grafting them explicitly into the schema
- the possibility of letting users supply a well-formed fragment of an XML namespace
- either within a mandatory CNXML wrapper element, or not
- either within a pointer to a relevant schema, or not
- the assigning of specialized subsets of CNXML to their own namespaces
But what about DocBook or TEI? Authors are most likely going to want to use not whole documents of these types, but rather excerpts from them: a paragraph or two from a narrative work; a few stanzas of a poem; an exchange from a drama. These document types don't define schemas with root elements of all of these kinds--instead, the root elements typically represent whole articles or books--so validation of CNXML plus pieces of either of these doctypes is problematic. Unless we build formal support of DocBook or TEI elements into our schemas, it may only be possible to insist upon their well-formedness.
One proposal was to stipulate that such foreign XML elements must be inside a special container element, something like foreignXml. Another was to include in these foreign XML elements an optional URI pointing to a schema according to which they should be valid.
RelaxNG allows for elements of arbitrary namespaces to be included at given points within a schema-conformant document. The costs as well as the benefits of this approach should be investigated.
Regarding the 3rd topic, Kathi felt that moving specialized CNXML elements to their own namespaces would make it easier for authors to learn and use the language.
Book indexing
We discussed the limitations of the term element for supporting quality book indexing.
- What we presently do with term is more properly concordancing rather than indexing.
- Good book indexes from Connexions collections would include at least these features:
- single form of entry for a concept that occurs in the text under more than one term
- page ranges, (including ranges that cut across what in Connexions would be several modules)
- hierarchical entries
- the need for a given module to be indexed different ways in different contexts
- indexing a word or phrase without changing its appearance in the module
