Re: operational concept for table browsing

to follow up on what Dave Raggett said:
> > One is that, while it is well and good to talk about how one
> > would do a full readout of a table under different sub-class
> > hypotheses, that interactive browsing of the table is more
> > critical to successful use by speech users.
> Absolutely. I feel it is critical to enable browsing, including
> the ability to suppress and expand levels of detail.

When you say "suppress levels of detail" I hear you assuming that
there is a semantically valid way to form a composite or summary
for some set or rows or columns.  That requires a special kind of
table to start with.  Maybe you mean what I have been thinking
about in terms of the construction of reduced tables by hiding
selected rows and columns.

In the meantime, I still haven't got closed-loop confirmation
that you grok what I am calling "keys."  I would like to know
	- you have got the concept but don't think it's important
	enough to waste an attribute and default rule on, or
	- I haven't make the concept clear enough yet.

One way to explain the "keys" concept is the idea that keys are
[for example columns] that you can't suppress without destroying
the validity of the data.  These are necessary preconditions for
the data in some related cell to be valid.  You can suppress some
of the columns in a table, but if you have a multi-column set of
keys required to isolate a[n entity or] unique case, then hiding
one of the key columns results in an invalid relation.

Another way to explain the concept is the idea that most tables
people actually use are not just relations but are actually
tabulations of _functions_.  In terms of the gut appreciation
of the table, the reader and writer know which dimensions are
inputs and which are outputs.  The inputs are the keys.  Knowing
which dimensions are the inputs, and span the domain of the
function, is essential to interpreting the data in the cells.

Is any of this getting across?

I am not sure that you are thinking about the simplest form of
table, one which is just a list of records with a sufficient key
in column 1, and other attributes of the entities keyed by column
1 presented in further columns.  In this case, the minimal
reduced table that goes with each cell is cells

	(A1)  (X1)

	(An)  (Xn)

Here X and n are arbitrary columns and rows (>A and >1),
respectively.  The axes attribute for cell Xn is just the TH at
X1, and it can be made so efficiently by putting a scope
indication of "column" on the X1 cell.  For that matter, the
default in absence of any overt indication is probably that
"axes" defaults to TH cells above the TD cell, so we probably
don't need any markup in this case.  [Maybe this is just true for
the row-major or rows-are-the-dominant-substructure classes of

I don't see how the AXES/AXIS markup would tell me that I need to
read the data in An together with Xn to make Xn valid.  And the
data that are necessary to establish the validity of the data in
column X are not always just what is in column A.  It may take
several of the other columns [or more generally, other cells] to
completely describe the conditions under which the data in cell
Xn are valid.

The minimum reduced table includes the current cell and any other
cells that are axes _or keys_ for that cell, together with
[abbr's for] the axes of the keys.

Does the AXIS/AXES attribute set convey what I am calling key
relationships and I am just missing it?

-- Al

Received on Wednesday, 8 October 1997 00:40:31 UTC