Closed martindholmes closed 8 years ago
No quarrel here. Might also point out that now that we've regularized (at least to some extent) the anomalous semantics of @type on <list>
, and given the close relationship between <list>
and <table>
(a list being essentially a one- or two-column table), considerations of symmetry and fitness suggest that <table>
s deserve to be typed and subtyped as well as <list>
s do.
Good point about the parallel with lists; it gives us something to be cautious about too, because the same potential confusion between rendering (list[@rend='numbered']) and type (list[@type='gloss']) may bite us. Truth tables and tide tables are definitely types of table, but tables-with-alternating-row-colours or double-bordered tables are not. This arises out of some personal work I'm doing on encoding crosswords, which involves encoding grids. A crossword grid is clearly (IMHO) a specific type of table, but it also has particular rendering features associated with it (square boxes, black or white backgrounds, tiny numbers in the top left corner and so on). We have to keep those notions separate, if we choose to provide sample values for @type.
Yep!
I'm curious about this way of encoding a crossword. If you treat it as a table, is each cell in the table a cell in the grid? If so, how do you represent the words -- as spanned columns or what? I'd be tempted to explore using surface and zone rather.
It's early days, but the project is here:
https://github.com/martindholmes/cryptic
I'm keeping clues and answers separate from the grid table, and just marking the cells in which answers begin (using @n on <cell>
in the TEI); it's trivial to put answers into the grid if you need to. My main interest is encoding the components and types of cryptic clues; I want to see how they've developed over time since the start of cryptics in the 20s. I'm interested in grids too, so I'll want to compare those mechanically to see how the ratio of lights to black squares varies over time and between publications, that sort of thing. Right now, I'm focused on creating a simple HTML interface for creating grids and entering clues and answers, from which I can generate a TEI file. It's the sort of thing that's very well suited to a GUI.
I'm so pleased no-one has said that @type should be provided by att.global that I (also) vote for adding <table> to att.typed ...
Perhaps I'm pursuing a different strategy here: a steady flow of individual requests for @type on one element after another, so that eventually, within a couple of decades, it'll be global without anyone noticing. :-) Nyaahahahaha.
Implemented this without telling anyone, nhaahahahahaha
There are lots of different types of table: spreadsheets, data tables, analytic tables, truth tables, periodic tables, tide tables, and lots more. @type and @subtype would be very handy.