[tei-council] Chapter 14 - Tables, Formulae, and Graphics

[Lou's Laptop]

Brett Zamir wrote:
> For note 44 occurring within 14.1 Tables, "A markup scheme could 
> equally well define tables as being composed of columns of cells, but 
> this is rarely if ever done in practice", this information seems to be 
> conveyed just a little while later in 14.1.1 TEI Tables: "It is to a 
> large extent arbitrary whether a table should be regarded as a series 
> of rows or as a series of columns.  For compatibility with currently 
> available systems, however, these Guidelines require a row-by-row 
> description of a table."

Yes. I removed the footnote.
>
> For note 45, "In this case additional redefinitions may also be needed 
> to avoid name clashes with existing TEI elements.", won't name clashes 
> be avoided by the use of namespaces?
>
Yes. This footnote predates the existence of namespaces, of course. Removed.

> For note 46, "We do not show here how the MathML names are to be 
> included in the TEI namespace", why would they be included in the same 
> namespace? If they actually would be, how about a reference to where 
> it is explained how this would be done?
> *
> *
This chapter really has not been brought up to date! The note is 
particularly stupid becaiuse it is immediately followed by an example 
which shows precisely how you embed MathML within a TEI document! 
Removed note again.


> *14.1.1 TEI Tables*
>
> 1) For the line, "For both tables and cells, rows and columns are 
> always given in top-to-bottom, left-to-right order.", maybe this could 
> be qualified with something to the effect that CSS can be used to 
> reverse the order of a table's presentation? (e.g., for Arabic, 
> Hebrew, etc.)
OK, added a phrase to that effect

>
> 2) Why are there no examples using @role="data"?
>
It's the default, I suppose.


> *14.2 Formulae and Mathematical Expressions*
>
> 1) What about the idea of making certain elements such as <formula> 
> belong to a schema type "ANY"?  It seems that for such information as 
> formula (with MathML, etc.) and graphics (e.g,. SVG), it would be 
> pretty common to wish to allow external grammars, and doing so 
> wouldn't force documents to become non-conformant, and could be easily 
> ignored by TEI-conformant processors which weren't enhanced to 
> understand whatever vocabularies might be used within the tags.... 
> Projects that wished to have a stricter schema could make a stricter 
> customization with no effect on conformance... I really feel this 
> would be a very helpful change and could promote more flexibility for 
> documents' expressiveness...
>

I'm not sure what you mean by "a schema type ANY": do you mean "having a 
content model of ANY"? That's possible, but doesn't preclude you from 
the need to define the elements which might appear there in your schema. 
The use of namespaces is a much more effective solution to this problem, 
and is also fully standards compliant, so that a document can be 
validated against an appropriate schema. And using a non TEI namespace 
for element content is not necessarily "non-conformant": see further the 
discussion in the chapter on this topic.

> 2) For the line, "It [MathML 2.0] also provided a modularized version 
> of the MathML DTD so that MathML fragments 
> <soCalled>embedded</soCalled> in XHTML 1.1 documents *as data islands* 
> can be correctly validated.", I wonder whether use of the term "data 
> islands" may convey the impression (as the term is used in Explorer 
> with XML data islands) that the MathML is simply stored as a reservoir 
> for Javascript manipulations, etc., rather than as something which can 
> be read directly (by MathML-aware processors).
>
I've removed the phrase "as data islands" in the interests of simplicity


> *14.3 Specific Elements for Graphic Images
> *
> Any thought to the idea of requiring <figDesc> when it is added, for 
> the sake of accessibility? This kind of requirement has become 
> standard in languages such as XHTML.
>
Again, this is a proposal you should submit as a sourceforge feature 
request!








> best wishes,
> Brett