Re: techniques for tables (clarifying how to handle nested tables for the ER group)

[Distribution note:  I am sending this separately to ER-IG, GL, UA, PF, and
CG lists because it touches all their turf.  That is too many to
cross-post.  Consult your chairs for how we coordinate follow-up.]

At 10:23 AM 11/29/99 -0500, Wendy A Chisholm wrote:
>hello,
>
>in the Evaluation and Repair Tools working group we have been discussing 
>how to evaluate and repair tables.  Particularly, nested tables.
>
>if nested tables are used to present data, is there a way to associate the 
>cells in the inner table with header cells in the outer table?  I would 
>assume that axis and headers could work  across tables (if a UA was built 
>that way).  However, in HTML 4.0 the only values for "scope" are row, col, 
>rowgroup, and colgroup.  so, it seems that "scope" could *not* be an inner 
>table.
>
>Nested tables seem less of a problem for layout tables. I propose that the 
>evaluation and repair is to handle each table separately, like Mark Novak's 
>HelpDB tool.
>
>--wendy
><>
Cool!  This raises all kinds of dust.

First, we need to distinguish the authoring scenario from the repair
scenario where one can't take guesses back to the author for confirmation.

Second, it seems to me that the ER community, that is to say people
actually implementing authoring tools and accessibility-aiding gateways
(communicating among themselves via the ER groups) should take the lead in
refining guessing algorithms.  This should be done based on what pages on
the web are actually like, and what form of prompting authors actually
respond well to.  So: for guessing algorithms, ER should lead and UA WC
etc. should follow.

Now for some details:  

In the authoring case, where guesses are used to propose interpretations
for the author to confirm, it should be clear that the end result is
explicit header-linkage markup using headers, scope, and axis attributes
until there is not room left for the user agent to have to guess at
anything.  The header associations should be presented to the author in a
prompt something like what Len is talking about coding.

The optimization criterion in the authoring scenario is least author effort
to get to an agreed definiton of what headers go with what data.  If you
don't guess at all, the author has to work too much.  If you guess lots of
wrong stuff, the author has to work too much.  The happy medium takes
testing with authors and in fact is probably good that this should be
policies that are trainable or settable by the author so that they can be
bent to the author's interpretation of how to use tables.

In the pure repair case, the guessing rules are popssibly different from
the rules used if one can ask the author to confirm.  The problem is how to
put the user in control of how much guessing gets applied to what table.

Warning:  There is a big issue here where I have been asleep at the switch.
 This is that RDF is indeed already a W3C recommendation, so the use of RDF
as the medium for annotations which are:

a) advisory in nature, because they are 
b) from a third-party source and not the document author


is technically superior and hence support for some such encoding should be
on our list of things we want UAs to implement and future content
guidelines to explain.

Small GL issue:  Do we have examples of how to use header-threading markup
together with nested sub-tables?  How to interpret the markup?  I guess
that the latter is UA stuff.  But they should agree.  Authoring tools
should produce explicit header threaded markup without reliance on guessing
algorithms.  User agents should at minimum interpret the explicit header
threading markup and for extra credit should implement guessing algorithms.
 The question is the status of implementing RDF which may contain
third-party advisory interpretation of the usage.

Larger GL issue:  Deciding between RDF annotations vs. using the
change-tracking markup available in HTML to indicate what markup is changes
introduced by guessing in the gateway, vs. other options which people may
think of.

Large UA issue:  What support for RDF do we ask for?

Al

Received on Wednesday, 1 December 1999 13:23:58 UTC