SCOPE on TD

to follow up on what Dave Raggett said:

> On Tue, 14 Oct 1997, Jason White wrote:
> 
> > SCOPE needs to be added to both TH and TD, since TD elements can
> > act as row headers. This should not be a problem, since if I
> > recall correctly, TH and TD share the same element and attribute
> > definitions in the DTD. 
> 
> Indeed the scope attribute is valid on both and allows one to
> treat some TD cells as acting as kind of like headers. An example
> is given in the Sept 10th draft:
> 
>     <TR>
>       <TD scope="row">An Introduction to Anglo-Saxon England</TD>
>       <TD>Mark Cottle</TD>
>       <TD>
>          One day course introducing the early medieval
>          period reconstruction the Anglo-Saxons and
>          their society. <EM>Saturday 18th October.</EM>
>       </TD>
>       <TD>H28</TD>
>       <TD>&pound;18</TD>
>     </TR>
> 
> Although the first cell in the row is treated visually as
> a data cell, it is marked up with scope=row so that an aural
> browser can "explain" later cells in the same row in terms
> of the cell that gives the course name. I think Al thought
> of this in terms of inputs and outputs, but I may be wrong.
> 

<floodgate warning>

1. Do we want SCOPE on TD?  In the context of the current draft,
yes.  

Given that we have only the AXES attribute to connect a table
cell to other cells to form a "keep-with" constraint, I believe
that in practical terms we do want SCOPE on TD as well as TH.

There will be table cells holding data values in the list of AXES
IDs along with cells holding data descriptions.  At that point
it does not make sense to start a crusade about when to call
something a TD versus a TH.

I had been stingy with the SCOPE attribute because at the moment
I did that I was under the influence of the hope that if
an author cares enough to put SCOPE marking on a cell, they
might be willing to use a TH cell for headers.  But I realize
that one wants to indicate SCOPE for cells that I would call
key values and you would call de-facto headers.

2. Al thought of this as ...

Yes, Al tried to explain this via inputs and outputs, in which
case the key data are all the inputs and the self data is one
among possibly several outputs.

On the other hand, it may be clearer to say it this way:

AXES ties a cell to other cells that you want to keep with the
current cell in non-visual cell query, baloon help, or whatever.
These other cells comprise a rough definition of the logical
vicinity of the current cell.

I wanted to subdivide these links to logically-close cells into
CONDS links that tell you "when" about the current cell and TYPE
links that tell you "what" about the current cell.

The AXES attribute definition as it stands lumps all these
relationships as "what."  You can do that because "what" is a
very permissive category under which you can classify anything
you have no better home for.

I still believe that for general utility of the semantic markup
there should be at least two classes of semantic links among
table cells and that when/what is the most obviously useful
dichotomy.  

That is because the semantics where you really need tables is
when the message involves significant second-order relationships.

Analogies of the form 

"Beer is to television as popcorn is to movies and hot-dogs to
baseball."

and statements such as

"Joe is more distant in age from his closest sibling than Mary is
from hers."

are second-order relationships.  They show up in tables as an H
pattern overlaid on the table.  Each arm of the H is terminated
by some local cluster or pod of cells which form an atom for they
purposes of the H (like a short stack of descriptors cascaded to
form a composite description of the data in the row or column
subject to this description).  It may be a single cell, as is
common in the case of a TD in the body of the table.

One of the key capabilities of tables which is why we don't just
use indented table-of-contents lists all the time is the
capability to compactly communicate lots of second-order
relationships; via the parallelism between a pair of pod-pairs,
i.e. the visual H.

To keep the H's straight, it is desirable to view the cells on a
two-dimensional semantic grid.  By lumping key data and data
descriptors under one class of links, valuable information has
been lost.  You have collapsed the H into a star topology with me
at the center and keep-with-me ringed around.  The shape of the
relationship has been lost.

-- Al

Received on Tuesday, 14 October 1997 13:40:35 UTC