Re: operational concept for table browsing

On Wed, 8 Oct 1997, Al Gilman wrote:

> 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.

I think we are working from different mind sets. A phone conference
would be a great way to clarify things and speed our work along.
Daniel can you help with organizing this?

I believe that the number of rows and columns and the placement
of headers in tables is largely dictated on the grounds of how
it will appear visually. I share this perspective with at least
Murray Malone. The choice for visual users may be inappropriate
for users browsing with speech or Braille-based user agents.
As a result, I feel we should encourage authors to include
information describing the relationships between header and
data cells, and for designating groups of related headers acting
as marks along one or more semantically meaningful axes.

For non-visual browsing of complex tables, I believe it is
preferable to map the table to a hierarchy, where each branch
corresponds to choosing a header from a group. The leaf nodes
correspond to data cells. The header groups are determined by either
child-parent relationships between headers or by explicitly
labelling the group using an "axis" name.

In this approach you can hide the children of a give node. This
gives you the means to explore the table aurally at different
levels of detail, without regard to how the table is arranged
for visual users into rows and columns.

Note that I am not forcing speech-based user agents to work
this way. Some vendors may choose to provide something that
follows the visual layout with up/down and left/right commands.
The key thing is to find a way of annotating the visual layout
of the table in a way that is inexpensive for authors to deal
with and which allows for flexible treatment for speech and
Braille-based user agents.

Perhaps I have a clue as to what you mean by "keys". One way to
think of headers is as the names of fields in a table in the sense
of a relational database. Typically, most such tables have one field
that serves to uniquely identify rows, for instance an order number,
a product number, or a line-item number in a customer order database
application. These key fields can also be usefully considered as
headers. This intuition explains why I feel that its sometimes
appropriate to use TD cells for such headers, reserving TH for
"field" names.

> 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.

For some data, there will be a clear "causal" relationship
between fields, while others are best treated as declarative,
allowing you to pick and choose relationships as you wish.

> Is any of this getting across?

Past experience shows that clear concrete examples work wonders
for building shared understanding. I would be very happy to
include new examples in the spec where these would make the
abstract conceptions easier to understand.

> 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)

What do you mean by minimum here? I may just wish to hear the
table spoken in row order, in which case it may not make sense
to have the A_{i,1} cells spoken before each X_{i,n} for each n.

The model proposed in the current drafts for HTML 4.0 and CSS2
give just this kind of flexibility. You choose via the style
sheet whether you want the A_{i,1} cells spoken or not before
the other cells. This assumes of course that the A_{i,1} cells
are marked up as acting as header cells for the X_{i,j} cells.
This can be done using the the axis/axes/scope attributes for
instance:

  <th scope=row>a1</th>...<td>x14</td>...
or
  <td axis=input>a1</td>...<td>x14</td>...
or
  <td id=a1>a1</td>...<td axes=a1>x14</td>...

The middle example relies on the specified algorithm for
identifying axes values, while the last example makes this
explicit. The first example uses the scope attribute which
turns this around -- you specify which cells are covered
by a given header, rather than the other way around.

> 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. 

You need to specify the relationship between the An and the Xn
using one of the methods shown above. The designated headers
act as "explanations" for each cell. Whether these are spoken
with each data cell is then a style sheet issue.

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

My belief is that it does. Lets try and meet by phone to
discuss this further. In the meantime, I will add the scope
attribute to the draft to make it easier to assess vis a vis
other ideas. I hope to have this ready today. Do all of the
people on the WAI-HC list have access to W3C member only
pages? If not I can put just the revised table chapter up
somewhere publically accessible on the Web.

Regards,

-- Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
phone: +44 122 578 2521 (office) +44 385 320 444 (gsm mobile)
World Wide Web Consortium (on assignment from HP Labs)

Received on Thursday, 9 October 1997 08:27:51 UTC