Re: HTML/CALS/ICADD Table Prop

Harvey Bingham (bingham@amos.HQ.ileaf.com)
Sun, 30 Apr 95 01:24:34 EDT

----- Yuri writes on AXIS/AXES hierarchy conceptually in one dimension only----
>From ileaf.prospect.com!cicerone.uunet.ca:yuri@sq.com! Sat Apr 29 22:50:53 1995
From: yuri@sq.com
To: bingham@amos.HQ.Ileaf.COM, tables@sgmlopen.org
Subject: Re: HTML/CALS/ICADD Table Prop
Cc: davep@acm.org, dsr@hplb.hpl.hp.com, dsr@w3.org,
harvey@navysgml.dt.navy.mil, html-wg@oclc.org, montulli@netscape.com
...

... In the use I had imagined,
the set of AXES, (that is, the set of AXIS names) which led to a specific
TD would have to be unique, but in the common example

_______________________________________________________________
| | |
| Tea | Coffee |
|______________________________|______________________________|
| | | | |
| Loose | Bagged | Loose | Bagged |
|______________|_______________|_______________|______________|
| | | | |
| 123 | 234 | 654 | 987 |
|______________|_______________|_______________|______________|
| | | | |
| 124 | 235 | 864 | 8879 |
|______________|_______________|_______________|______________|

I expect the markup would be something like:

<TH COLSPAN="2" AXIS="Tea">Tea</TH>
<TH COLSPAN="2" AXIS="Coffee">Coffee</TH>
[it would be the same if the actual content
of the cell were "The Best Coffees in the
World, Organized Alphabetically"]
<TH AXIS="Loose">Loose</TH>
<TH AXIS="Bagged">Bagged</TH>
<TH AXIS="Loose">Loose</TH>
<TH AXIS="Bagged">Bagged</TH>

<TD AXES="Tea Loose">123</TD>
<TD AXES="Tea Bagged">234</TD>
<TD AXES="Coffee Loose">654</TD>
and so forth

------- End Yuri ---------

Yuri's example table showed AXIS name repetition, with AXES showing the
disambiguation by the distinct prefix used with the AXIS names of the
prior COLSPANs. The key insight I get from his example is that the
AXIS mapping to AXES are independent of the physical ordering.
His example could have been presented reversing the two axis rows
with suitable change to column order.

I had been associating AXES with (column, row) and had proposed
a hierarchic ordering top down the header rows, and analogously
left to right for stub columns. I realise now that that ordering
may be a convenience, but more important is that the set of
qualifying names for a TD are unique, their order may be only
a matter of convenience.

However in some tables the column axis may have a particular
relationship to the row axis, and the set of TH axis values
might appear the same, say in an antisymmetric table of distances
between villages, where there are some one-way roads. Each
village would appear in one row and one column. So the axis values
could be augmented by source or destination. This might be a use
for the axes value on TH.

An implicit use of THEAD in CALS was to group the rows providing
heads to all subsequent pages. The same semantic use could be applied
here to provide all the TH axis information for subsequent columns of
TBODY. Single tables of hundreds of pages were deemed necessary for
CALS.

Preferably such TH in a row would be all before the TD in that row.
Then the axis information would be all available before needed in
a row. The example above doesn't do that.
That would suggest the content model might change to
<!ELEMENT TR - o (TH*,TD*)>
...
In the present general placement of TH and TD, and their
association to axes of TD some significant recognition is required
to determine the contribution of the various phrases that comprise an
axes value.

The method Yuri applied can be extended to include an AXIS value from
THs in TBODY rows that name the row AXIS as well. The hierarchy of row
TH with an earlier ROWSPAN TH to provide the row hierarchy.

I presume the left and right columns are TH columns, providing
row hierarcy AXIS. Here
________________________________________________
| | | | |
| Process | Tea | Coffee | Package |
|_________|_________________|________|_________|
| | | | | |
| Regular | 123 | 234 | 654 | |
|_________|________|________|________| Glass |
| | | | | |
| Decaf | 124 | 235 | 864 | |
|_________|________|________|________|_________|
| | | | | |
| Regular | 1234 | 1234 | 6543 | |
|_________|________|________|________| Plastic |
| | | | | |
| Decaf | 1245 | 2355 | 8642 | |
|_________|________|________|________|_________|
| | | | | |
| | Loose | Bagged | Loose | |
|_________|________|________|________|_________|

<TH AXIS="Process">"Process</TH>
<TH COLSPAN="2" AXIS="Tea">Tea</TH>
<TH AXIS="Coffee">Coffee</TH>
<TD AXIS="Package">"Package</TD>
<!--TD, not TH as not used in any axes-->

<TH AXIS="Process Regular" VALIGN="middle">Regular</TH>
<!-- or should Process be picked up from an axes? -->
<TD AXES="Tea, Loose, Process Regular, Glass">123</TD>
<TD AXES="Tea, Bagged, Process Regular, Glass">234</TD>
<TD AXES="Coffee, Loose, Process Regular, Glass">654</TD>
<!--Loose redundant-->
<TH ROWSPAN="2" AXIS="Glass" VALIGN="middle">Glass</TH>
<!--omitted Package-->
and so forth

<!--final row can provide axis values needed previously-->
<TD></TD> <!-- empty positioner -->
<TH AXIS="Loose">Loose</TH>
<TH AXIS="Bagged">Bagged</TH>
<TH AXIS="Loose">Loose</TH>

More complexities:

Should "Process" and "Package" be part of the Axes qualification?
If so, hard to automatically know the "route to traverse such hierarchy"
I have shown "Process" but not "Package" included in the content of the
AXIS on the TH. Not needed if the AXIS set of names are sufficiently
distinguishing.

Putting the TH in the first and last column is allowed by the model
for TR. I have here put the ones with the ROWSPANs to the right.

Likewise putting the TH spans in rows is arbitrary. Here I've put
the rows that define the AXIS on top and bottom,

The Yuri insight for these is that with reasonably chosen axis names
or phrases, the arbitrarily ordered comma separated AXIS phrases
are sufficient to identify the individual TD cells.

It is not clear to me that TH need or can benefit from axes. One
possible use would provide qualification for an axis provided in the
TH. Then the effective contribution from that TH axis would be the
fully qualified axes.

Then should the value for that axes attribute have any axis value postpended?

It is not clear what use axis has on TD.

Consider eliminating axis from TD and axes from TH.

What happens if phrases in axes have no correspondent from
orthogonal axis specifications?

The amount of qualification needed isn't always the same, as the
example has one more level for tea than coffee.
A non-rectangular specification of axes is appropriate for this.
A good prototype for understanding this kind of TD addressing is the
modeling of ragged arrays in the language APL.

The implied use of TH value as its axis value is useful.

The implied use of TD value as its axis value is confusing.
Is the use of axis value on a TD the place to put a descriptor like
"graphic of the dancing dog". That use may be different than as a locator
for the implicit descriptive information from a TH axis that helps to
complete the definition of the TD.

So far the focus has been on axis and axes use on traditional tables.
That conceptual model has come from the geometric use of the words
axis, and axes, as being orthogonal (Euclidean different dimensions).
In that pure geometric use, there is no particular relation identified
between (or among) the axes. We have presumed a mapping onto 2-dimensional
table presentation regardless of the number of axes in the description.

When we use the axes mechanism in its unconstrained but allowed forms,
the table as organizing structure breaks down. We may need a
more general database model.

The axes mechanism can refer to any name of any axis, whether or not
it appears in a THEAD or a comparable set of stub columns. The
model allows any TH or TD to have an axis specified by which a
relation from any other TD can be established (though what that
relation is depends on the phrases used in those axis values.)
In that context, the sematics of the words axis and axes get
in the way, as there is no assured orthogonolity, nor is there any
need for the axes to specify only a single TD: partial axes could
yield all TD matching that partial specification.

Regards/Harvey Bingham
SGML Open Tables Committee Collator
CALS Table model coauthor

Standards Manager
Interleaf Inc. | tel +1 617 290 4990 x3419
Prospect Place, 9 Hillside Avenue | fax +1 617 290 4970
Waltham, MA 02154 USA | bingham@ileaf.com