[tei-council] Comments on Chapter 18, Tables, Formulae, and Graphics.

Sat Sep 8 11:26:19 EDT 2007

Dear Council,

Comments on Chapter 18, Tables, Formulae, and Graphics.

Best,

David
_______

18 Tables, Formulae, and Graphics

1) Inconsistency in the use of serial commas, e.g.,

a) ... include not only text but also graphics, artwork, and other images.

b) .. representation of graphics, formulae and tables in electronic form.

Whether a comma occurs before "and" in such constructions should be made 
consistent (within the Guidelines in general, and not only within the 
chapter, where both versions occurs more than once).

Additionally, a comma before "but" in a would be an improvement.

2) Inconsistency in the plural of formala (formulae or formulas). Search 
and replace.

3) Section 18.1 speaks of encoding one column as containing names and 
another as containing dates, but as the chapter notes, the TEI doesn't 
actually encode column semantics directly.

4) Section 18.1 says that a table is generally viewed as "a special text 
element, made up of row elements (or, sometimes, column elements, 
themselves composed of cells." I know of no column-major table markup in 
wide use, so unless I've overlooked something, perhaps this would be 
more accurately say not that column-major markup occurs sometimes, but 
that it is a theoretical possibility.

5) Section 18.1.1 ways "Where cells span more than one column or row, 
the encoder must determine whether this is a purely presentational 
effect (in which case the @rend attribute may be more appropriate), ..." 
Can we give an example of how one might use the @rend attribute to 
specify spanning?

6) Toward the end of 18.1.1 we say that semantically meaningful names 
for the contents of cells, such as <name> or <num>, may be more useful 
than mere cell data. We might also want to remind readers that the @role 
attribute is another way to achieve this end.

7) In the content models toward the end of Section 18.1.1 it looks as if 
a <row> can contain a <table> but a <cell> can't. I think this means 
that where we expect a cell, we might find a subtable, but my 
understanding of those semantics is that the subtable is the contents of 
the cell where it occurs, which I would model by saying that a <row> can 
contain only <cell> elements but a <cell> may contain either 
macro.paraContent or a <table> element. I think the effect is the same; 
the difference is whether we conceptualize an embedded subtable as 
occupying a cell or taking the place of a cell.

8) 18.1.2 In the first paragraph, I'd change "These often provide ..." 
to "These may provide ..." (to avoid the repetition of often later in 
the sentence).

9) 18.1.2 This may be a trans-Atlantic difference of which I am merely 
ignorant, but I don't hyphenate after adverbs in "ly", as in 
"publically-available." Likewise "semantically-rich" in Section 18.2.

10) In the discussion of the HTML table model in this section, we need a 
comma before "ranging from desktop computers."

11) In the discussion of the XHTML table model in this section, I'd drop 
the "should" in "It is recommended that tables should not be used ..." 
and I'd spell "layout" as two words in the continuation of that 
sentence. Toward the end of that paragraph I'd remove the comma in "... 
other visual characteristics, in both HTML ...."

12) In Section 18.2, first paragraph: change "pose similar problems to" 
to "pose problems similar to."

13) In Section 18.2 I'd change "facilitate mapping across both 
standards" to "facilitate mapping between the two standards."

14) In the description of <figure> at the beginning of Section 18.3, we 
say that <figure> contains a block containing graphics, illustrations, 
or figures. Since <figure> contains those things directly, and does not 
contain a block that contains them, perhaps we should change the 
wording. Additionally, <figure> contains information about the graphics, 
illutrations, and figures (e.g., <head>, <figDesc>, and not just the 
graphics, illutrations, and figures themselves.

15) In the list of elements at the beginning of Section 18.3, there's a 
slash after "graphic". If this is intended to indicate an empty element, 
it isn't a problem, but I wanted to mention it in case it was an oversight.

16) In Section 18.5 we say that only CGM, JPEG, PNG, and SVG are not 
proprietary, but isn't SMIL non-proprietary, as well?