Re: Use of Axis in data-table for categorizing cells

At 05:29 PM 2004-01-07, Wendy A Chisholm wrote:

>Sailesh,
>
>Interesting questions. I think your questions are best directed to the 
>Protocols and Formats Working Group (PFWG) [1].  I'm ccing Al on my response.

Thanks, Wendy.

>Related tidbits:
>- A good discussion of the benefits and drawbacks of axis is section 4.4 
>of "Techniques for Accessible HTML Tables" by Stephen Ferg (2002). [2]

Yes, that's good.

A few remarks:

I would go further and say that techniques dependent on 'axis' should not be
promoted for general use.  It represents a failed experiment in providing
for fine-grain metadata in tables.  Future efforts to support this
capability will look more like XForms and Annotea than HTML4 'tables.'

The highest and best way to implement the _intent_ of the 'axis' attribute
today is to use XForms.  The table is a layout of a two-dimensional array of
read-only fields.  The schemas behind the 'model' for the form provides all
the category traceability one could wish in a standardized and fully
machine-interpretable form.

>- Since axis is not supported, I can't find a good, real-world example of 
>an axis attribute that has more than one value.

Multiple category names are appropriate when you wish to describe more than
one aspect of the data cells governed by this 'th' cell.

Examples:

axis="length, English units"

axis="toxic waste, into watershed"

axis="toxic waste, into atmosphere"

axis="greenhouse gasses, into atmosphere"

axis="nutrients, into watershed"

The kind of the 'category names' you would put in an 'axis' attribute are
things that you could have put in higher-level header cells in a
hierarchically structured set of rows or columns, but you didn't want to
waste the page space on the extra row of column heads or column of row
heads.  The 'axis' attribute provided a way to bury this information in the
page.  As with the rest of our 'hidden messages' that we put in HTML 4.0, it
has not been used.  "Out of sight, out of mind" has been borne out in the
authoring of HTML content except for the specific cases of dire need like
html:img.alt where there is a clear role for something that should be
present but is normally hidden.

If the full, pedantic explanation of the data cells would have included more
than one layer of these suppressed headers, then there will be more than
one category name in the list in the 'axis' attribute value.

>- Looking at the XHTML 2.0 drafts and the HTML WG issues list, there 
>doesn't seem to be any indication of clarifying the axis attribute.

There is an outstanding work item to define the best way to integrate RDF 
metadata into XHTML documents.  In the current climate of forward-looking
work in W3C, this is the favored approach over ad-hoc metadata such as 'axis.'

The kind of 'filtering' that we were vaguely ruminating about in HTML4 is
happening today in multi-channel publishing tools.  The people who develop
these tools are gathered in the W3C Device Independence activity to create
publicly available specifications for core common practices in this 
area.  Content selection is one of their core functions.  This is the 
process of picking and choosing among the 'conditional content' that is 
available in the language of the User Agent Accessibility Guidelines 1.0.

Looking to the future this query function will be related to RDF Query
and/or XQuery.  The respective roles of these two are not well defined
in the view of PF at this time and we are slowly nibbling away at that
problem.

Al

PS:  Some HTML specification interpretation corrections below.

>Best,
>--wendy
>
>[1] <http://www.w3.org/WAI/PF/>
>[2] <http://www.ferg.org/section508/accessible_tables.html#contents_item_4.4>
>
>At 03:57 PM 1/7/2004, Sailesh Panchang wrote:
>>As I understand, it makes sense to associate a single concept with a 
>>particular table header (th) cell  using the id and axis  for the cell. 
>>While reading the specs for the axis attribute (HTML  4.01 specs)I was 
>>perplexed by the statement:
>>"The value of this attribute is a comma-separated list of category names."
>><http://www.w3.org/TR/html401/struct/tables.html#adef-axis>http://www.w3.org/TR/html401/struct/tables.html#adef-axis
>>  How is it possible to associate more than one concept with a  single 
>> cell with one id attribute?

The 'axis' attribute associates a cell with one *or more* category names
by definition.

Further, the 'id' attribute plays no role in the cell-to-concepts binding
provided by the 'axis' attribute.  The element bearing the 'axis' attribute
is associated with the one or more category concepts named in the list of
category names which is the value of the 'axis' attribute.

If this cell in question is a header cell, this association is inherited by 
data cells characterized by this header cell.  This extension of 
association may follow id-headers links in the document.  This is well 
explained in Steve Ferg's document.

Multiple categories may be associated with the same collection of data values
in a multi-aspect concept space.  Examples above.

>>See the given example for instance:
>>  <TH id="a2" axis="expenses">Meals</TH>
>>So any data cell that refers to  this cell in its headers attribute 
>>(headers=a2") will categorize this data cell as Meals.

No, it will categorize it as "expenses, meals" which to the human 
interpreter is fairly reliably re-flowed as "expenses for meals"  All data 
cells governed by this header cell will be selected in a query seeking 
expenses in general.  The 'meals' information will be carried along as data 
in the query response.

>>One cannot  use the same a2  reference for another data cell and expect 
>>it to be related to  anything other than meals. Whatever is enclosed 
>>within quotes following axis= is interpreted as a single concept  even if 
>>two words are separated by a comma.

Where did you get this idea?  This is strictly contrary to the intent of 
the HTML specification in providing for a list of category names.

>>1. So is this  an error in the specs?

No, in the reading of the specs.

>>2. The specs for  headers attribute (in the HTML specs) say that multiple 
>>cell-names (referencing id values of table header cells) should be 
>>separated by  a space.  Assistive technologies (like JAWS and HPR) have 
>>in fact implemented this and work correctly when a space is used as a 
>>separator.... and a comma separator does not   produce expected results. 
>>The question is: mostly programmers are used to comma as a separator and 
>>specifying a space as the legal separator makes the specs  inconsistent. 
>>(For axis it says comma is the separator.) Additionally, there is a 
>>problem ifthe id value itself contains a space like in
>>id="office stationery".

Start with the last.

The problem with id="office stationary" is that 'id' values are not allowed
to contain spaces.  They must statisfy the syntax of the 'name' construct in
the HTML DTD.  This does not allow space characters.

   http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#adef-id

The 'headers' attribute can use spaces as separators because the items in 
the list are not supposed to contain spaces.  The 'axis' list uses commas 
for separation to allow category names containing spaces.  The programmers 
who designed the HTML4 format were willing to accept this diversity of list 
structures to allow more efficiency in processing 'headers' and more 
functionality in processing 'axis.'

Hope this helps,

Al

>>Thanks,
>>Sailesh Panchang
>>Senior Accessibility Engineer
>>Deque Systems,11180  Sunrise Valley Drive,
>>4th Floor, Reston VA 20191
>>Tel: 703-225-0380 Extension 105
>>E-mail: <mailto:sailesh.panchang@deque.com>sailesh.panchang@deque.com
>>Fax: 703-225-0387
>>* Look up <<http://www.deque.com>http://www.deque.com> *
>>
>>
>
>--
>wendy a chisholm
>world wide web consortium
>web accessibility initiative
>http://www.w3.org/WAI/
>/--

Received on Thursday, 8 January 2004 10:20:03 UTC