On Fri, 26 Sep 1997, Al Gilman wrote:
> This is just a rapid response quick look. But I want to expose
> you these ideas before we lose you if I can.
I now its the weekend, but I couldn't resist having a peek
at email :-)
> There are several categories of functionality where I think we
> might want to explore changing the table capabilities from
> what we have in this draft.
I tried very hard to find richer ways to model the semantics
of data, normally presented in tables. For instance looking
at entity-relationship-attribute (ERA) modeling and related
techniques. In the end I found that this problem is best broken
into two parts: the use of ERA modeling to describe a database,
and specialized scripts that define how a table is generated from
the database or how it can be written back to a database. These
scripts specify relational database queries (SQL) and iterators
that use the results of these queries to generate the table --
row by row, cell by cell. The same approach is used to scan a
table to export its data to a database.
This is all very well, but is far too costly for most people. The
approach presented in the draft was chosen as a much simpler option,
but nonetheless, one which I suggest can be used to effectively
support aural browsing of tables, including table summary, cell
abbreviations, parent-child relationships between cells, and
browsing at different levels of detail.
I am concerned that we remain pragmatic about the kinds of
annotations that most people will be reasonably prepared to add
to the visual presentation of a table. This is why I propose an
algorithm for finding the default value of axes. For many simple
tables this works just fine.
If we ask people to fill in axes on every data cell, I expect this
will cause many authors to see this as much too much of an
imposition, causing them as a result to avoid doing anything to
the table to help non-visual users. I see us as trying to promote
a small set of features that are easy for authors to cater for
whilst making it practical to do an effective job for non-visual
browsers.
And so to the details ...
> Summary: is restricted to a text string. would better allow a
> hypertext block. Guide to the table with jump possibilities. We
> can put the jump targets in the table by embedding A tags in the
> cells. But we can't associate a normally-hidden guide with links
> with the table as is. Very analogous to what I hear Jason saying
> about sensitive maps. I have to admit I have been wondering about
> hiding more general resource definitions [normally hidden hypertext
> blocks] in the HEAD.
When browsers see text they assume the document BODY has started.
As a result you can't hide text safely in the HEAD except as an
attribute value, for instance in META. If a rich text summary is
needed I suggest we add the longdesc attribute as per IMG. In the
draft, I felt this was unnecessary, since the proposed axis, axes
and abbr attributes can be used to make the table accessible itself
unlike an image.
> Cell readout: what one would really like is a "cell readout pattern"
> which is a roughly-sentence-scaled text macro which has variable
> substitution capabilities. Variables would refer to the cell content
> and to HTML elements the cell is associated with by semantic
> relationships. Trying to do this algorithmically is bound to come
> out less natural than letting the author state what a typical cell
> tells you.
> The $outnam of the $innam $inval is $outval.
>
> Here the typical tabular presentation is
>
> $outnam is a TH at the head of the column
> $innam is a TH at the head of column 1
> $inval is a TH or TD in column 1 and same-row-as-self
> $outval is the content of self, the current TD.
>
> The link from self to $outnam is a qualifier link, to $inval
> is a selector or key link.
A good point. Isn't this something that comes under style rather
than content though? I propose we focus on what kind of template
syntax would work, and then decide whether it best fits HTML or CSS.
> Axis association: I haven't fully understood the proposal.
The axes attribute allows you to list header cells that apertain
to a given header or data cell. The axis attribute is used to group
related headers. The abbr attribute provides a abbreviation when
a header is being repeatedly read out, e.g. before the contents of
each data cell.
> Some other names for this distinction
> from other disciplines:
>
> selector qualifier
> abscissa ordinate
> key field_def
> covariant_axis contravariant_axis
> whole(/part) gen(/spec)
I find these terms rather confusing in general, and prefer the
idea of using the axis/axes/abbr attributes together with
style templates for aural rendering.
> For efficiency, it is possible that some of the patterns of
> association would want to be able to be declared in a COL or TR
> and inherited into TH and TD.
I think that the axis/axes proposal is simpler and more expressive.
> SCHEME: In general one would like to be able to link a table to a
> more-semantic layer and not just a less-semantic style of
> presentation. c.f. the SCHEME for META. An ability to link a
> specific table to a data dictionary or information model would be
> a positive capability, and if we have to hide all the rest of
> this there, so be it.
See above. My studies suggest a combination of ERA models and
scripts for table generation and for extracting table data from
Web pages to insert into databases. I could go into more detail
at a later date if anyone is interested.
> Explicit order-of-reading markup: My kneejerk on this is that it
> is desirable, and wondering if we should address this by allowing
> LINK and META in the BODY where they would by default qualify the
> immediately enclosing container. Then we could put a
>
> in a TD and it would be
> known.
My feeling is a simple solution would be best. The most obvious
is an attribute that takes a number indicating reading order by
ascending value, e.g.
order=1 order=2 ... order=19
The "order" attribute can be placed on cells, rows or columns.
This is simple for wysiwyg table editors to support. The aural
browser finds the highest number for each cell by looking for
order attributes on the row, column or cell.
What do you think?
Regards,
-- Dave Raggett 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)
-------------------------------------------------------------
On Fri, 26 Sep 1997, Al Gilman wrote:
> For efficiency, it is possible that some of the patterns of
> association would want to be able to be declared in a COL or TR
> and inherited into TH and TD.
An alternative to the algorithm for computing axes values is,
as Al suggests, a way of annotating headers with information
that indicates which cells they apply to. I have experimented
with a simple way to achieve this using a "scope" attribute.
The scope attribute can be used with TD and TH elements.
Its permitted values are:
row all cells in the row
column (or col) all cells in the column
rowgroup all cells in the same row group
colgroup all cells in the same column group
column groups are marked up using the COLGROUP element.
row groups are marked up using THEAD, TFOOT and TBODY elements.
Here is the table markup for the example show in the attached image:
Travel Expense Report
Meals
Hotels
Transport
subtotal
San Jose
25-Aug-97
37.74
12.00
45.00
26-Aug-97
27.28
112.00
45.00
subtotal
65.02
224.00
90.00
379.02
Seattle
27-Aug-97
96.25
109.00
36.00
28-Aug-97
35.00
109.00
36.00
subtotal
131.25
218.00
72.00
421.25
Totals
196.27
442.00
162.00
800.27
Regards,
-- Dave Raggett 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)