RE: more on TABLEs

Woa
This is good stuff but..

 How much of this can be either
 - be done automatically (no author intervention needed)
 - or bbe done by the author by making a simple gesture  or dealing with it 
in very simple english terms.

I am concerned that people laying out tables will do it WYSIWYG and won't 
even know what a spanning title is (even if they use one) much less be able 
to tell the program whether the table is row or column dominant.

Can you help me by saying what this would look like to an author?

What would they be asked to tell the web author tool about the table in 
order to get the tool to code the table html correctly? (assuming the best 
case with regard to html being able to code the info)

Gregg


-----Original Message-----
From:	Al Gilman [SMTP:asgilman@access.digex.net]
Sent:	Wednesday, October 01, 1997 1:12 PM
To:	HC team
Subject:	more on TABLEs

to follow up on what T. V. Raman said:
> Subject: operational concept for table browsing
>  >
> Good start-- I'll add things in to your original message below:

Edits accepted as friendly amendment.  Let's make Raman's edit
our baseline as of now.

>  In addition, many tables are not meaningful unless the user
> has the ability to produce customized renderings where these
> minimally include speaking a cell with its row/column headers
> and in the ideal world include renderings of the form
> "Total population growth in %s was %s " cell (i,2) , cell (i,1)

Dave and I have kicked around investigating what the requirements
are for a readout script that generates this verbalization of
the meaning of a cell's value.  At last mention it was considered
worth working on some more.  It may be deemed a styling statement
in the end but it dominates my thinking on how to capture core
semantics.

My thinking revolves around defining self.attribute variable
names or relationship names that one would cite in such a script
in lieu of the cell (i,2) , cell (i,1) coordinate-wise references
above.  Maybe we should look at relative position coordinates as
an alternatives to what I am doing which is attribute names in an
information model.

But to continue on the logical-relationship-name path for a
moment, I want to distinguish two kinds of relationships from
the current [TD | TH] cell to other [TD | TH] cells.
For each kind of relationship, there is a variable and an
attribute that are related but not identical.
Consider

	A variable self.is_a which is a tree of cells.
	A cell attribute IS-A= which is a set of TH cells.

The value of the variable is the tree of one [TH or TD] cell
"self" as root and multiple TH cells which are directly or
indirectly the targets of is-a relationships from the starting
cell.  Is-a relationships can be created explicity by attribute
assertions in [TD | TH] cells or implicity by rules based on
information asserted at the row, column, or table level.

The TH cells in the self.is-a tree define how to interpret the
value in the cell.  Example: in the expense account table that
Dave put together, the self.is-a for all cells in rows 2 and up
and columns B and up is [the current TD cell linked to a TH cell
at (row=1,col=A)] For clarity please imagine this upper-left TH
cell contains the text "actual cost in US$."  Here the simplest
way to capture the global effectivity of this TH is to have an
effectivity indictation such as DOMAIN="2,,B," marked in the TH
cell.

Note: If I have it right, both the AXIS and AXES attributes
defined in the current draft are special cases of IS-A.

Then I want to define

	A variable self.keys which is a set of [TD | TH] cells
	A cell attribute KEYS= which is likewise a set of [TD | TH] cells

In this case, continued relationships are illegal.  A given cell
can be the source or target of a keys relationship, but not both.

Sources of "keys" relationships are interpreted as dependent variables.
Targets of "keys" relationships are interpreted as independent variables.

But the value of the self.keys variable is not limited to what is
explicitly asserted in a KEYS= attribute indication in the cell.
One possible shorthand form for establishing keys is that
columns may be designated key in which case the values in that
column are keys for all non-key values in the same row.

The keys completely define the conditions under which the cell value
is valid.  To return to the Travel Expense Report example, for the
subtotal of expenses for meals in San Jose which is the content of
cell (5,B) we have (5.B).keys={(2,A),(1,B)}.  In this table there
are keys to the left and above and qualifiers only at the table-global
level.

This brings us to the next suggestion:

CLASSES of TABLES.

Greg Lowney has suggested row-major, column-major, and "both," as
I recall.  I want to try out an alternative explanation in terms
of which grouping within the table has the strongest cell wall or
bonding strength.  Thus there are four cases: rows, columns,
whole, or cell.  Think about what the default rules would be for
populating self.is-a and self.keys under each of these four
cases.  Note that I think Dave's expense report gets classified
as having strongest bonding at the whole table level.  And that
"layout tables" get classified as having strongest bonding at the
cell level.

Note that if it is just a matter of driving browser-specific
presentation algorithms, we can handle this by CLASS indications
on the TABLE element and the HTML document is untouched; on the
other hand, to predefine the cell-context variables I discussed
above on a class-by-class basis, we have to at least predefine
some CLASS values, or else define an attribute to capture this
distinction.

-- Al

Received on Thursday, 2 October 1997 09:58:22 UTC