- From: Al Gilman <asgilman@access.digex.net>
- Date: Fri, 10 Oct 1997 00:52:38 -0400 (EDT)
- To: w3c-wai-hc@w3.org (HC team)
Raman's edit of my "operational concept" is still a pretty good baseline, or rough statement of where we are, for what it decides. I think that the capability to tie a table to some sort of a document that gives more information about the data discipline that is behind the table is something that has a high likelihood of being part of the answer, if we can work out the implementation. A minority will use it, but for those who are interested in providing web pages which are competent to transfer database fragments, it is a necessary option. People writing tables out of database systems will not find it hard to provide some dictionary support. We should at least have the capability to refer to it, and tie a particular "dictionary" specifically to an individual table. It is too likely that several tables in one document will be drawn from different databases each with a different data model. I have little doubt that the IG would fail to back up the desirability of such a capability, so I want to get to work with the browser people and the RDF people to work on implementation options. [more on this in a separate mail]. Dave and I had a good talk today. This is an attempt to reflect points of agreement and non-agreement from that talk. For a browser to be able to present the contents of a table as a hierarchical list is a valuable function. - sometimes (to most of the time) you can do this with existing tables without the need of additional markup such as the AXES, AXIS, ABBR in the current draft. - adding that markup will increase the effectiveness We don't really know how much. The "probe a single cell" scenario matters. It is desirable for the table to make clear what other cells are closely related to the current cell and how, enough so that a CSS macro could compose a sentence that give the complete message of the cell [content value] including what it needs to carry along from the context provided by the table. The biggest area of confusion has to do with how one finds the other cells related to one "anchor" cell needed to provide a complete statement of what the "anchor" cell tells you. Dave feels the AXIS/AXES markup does this. I am still not sure. We agreed to seek examples from life for analysis to aid the discussion. There is a representative of the list-of-records table at http://www.jammed.com/~newzbot/sorted-group-table.html for which there is a straight text alternate at http://www.jammed.com/~newzbot/sorted-group.html in case you can't follow the table version. This is the highly guessable case where the first column is the key or "what else in the row you always want to read with any cell." I have not yet located a page where it takes multiple columns to form a sufficient key. This table is interesting in that it uses TD markup throughout for cells that are field descriptors and cells that are field values without distinction. I had almost started to believe that I could interpret an AXES link from a TD to a TH as an IS-A relationship and an AXES link from a TD to another TD as a KEY relationship. But this example reminds me that just as some people will put the first column in as all TH's for cosmetic reasons even 'though that column contains data below the top row or so, there are others who will produce tables where what I would call a field descriptor is in a TD element and not a TH element. I don't think we can trust that TD and TH fields will be used for data values and field descriptors respectively, with any real consistently. For the record, there is another table I want in the evidence. This is found at http://www.faqs.org/faqs/ This illustrates a table that I would give a class of SET. If you state that the semantic structure of this collection is at the SET level, then the fact that it has been spread out in a table for cosmetic purposes will not mislead one into thinking that there is any deep order or connectedness semantics between neighbors, rows, or columns. ...Too late. More examples, more organization tomorrow. -- Al
Received on Friday, 10 October 1997 00:52:55 UTC