Re: The remaining issues list

Terry Allen (
Wed, 22 Mar 95 14:35:35 EST

Chris writes:
| Terry Allen says
| > Dave writes re colspec in tables:
| > > The latest version of the HTML 3.0 proposal attempts to satisfy many of
| > > the concerns raised in the SGML Open recommendations. I have retained
| > > the COLSPEC attribute after improvements (see below) as I feel this
| > > much more concise, easier to read, and provides the same expressive power
| > > as the sequence of <COLSPEC> elements suggested by the SGML Open team.
| > But the issue here is compatibility with CALS,
| It is? When was that change made?

No, I meant that compatibility with CALS was the issue Paul Grosso was
raising when he said that COLSPEC would be better as an element.

| <> states:
| Simplicity
| ----------
| The first version of HTML was designed to be extremely simple, both to
| author and to write browsers for. This has played a major role in the
| incredibly rapid growth of the World Wide Web. HTML 3.0 provides a
| clean superset of HTML 2.0 adding high value features such as tables,
| text flow around figures and math, while still remaining a simple
| document format. The pressures to adopt the complexities of traditional
| SGML applications has been resisted, for example the Department of
| Defense's CALS table model or the ISO 12083 math DTD.
| And the dtd (Draft: Tues 21-Mar-95 10:16:50) states:
| Design Objectives:
| o Keep HTML - simple don't compete with CALS

Aside from the matter that these design objectives have not been
endorsed by the present group (it would be reasonable to write a
functional requirements spec for HTML N.n), and so are not normative,
what SGML Open has proposed is not to bodge CALS tables into HTML,
but to keep HTML tables a subset of CALS--in a word, simpler.

| > which enables easier
| > interchange, conversion, and use of existing tools. As colspec-as-element
| > "provides the same expressive power," and table markup of the type
| > under consideration is not for the fainthearted anyway, the argument
| > from concision and ease of reading (the latter I would dispute) seems
| > kinda weak.
| But if simplicity is a design goal, and if the colspec-as-element gives
| equivalent expressive power, then converting from many colspecs to
| one colspec should be a fairly straightforward function to add to all the
| other conversions that an SGML authoring environment is going to have to do
| to convert a rich, dense CALS document to the simpler, web-lingua-franca
| that is HTML. So arguing for difficulty in conversion looks a little weak
| also.

Why have to mess with the matter at all? Let me point out that Dave's
table model has a lot in common with CALS already (including the
essential point that they both describe tables in terms of their
formatting, which is not the only way to do it; only AXES in
Dave's model is a step away from that).

Here's Dave's model as of 21 March 95:

<!ELEMENT TABLE - - (CAPTION?, TR*) -- mixed headers and data -->
%needs; -- for control of text flow --
border (border) #IMPLIED -- draw borders --
colspec CDATA #IMPLIED -- column widths and alignment --
units (em|pixels|relative) em -- units for column widths --
dp CDATA #IMPLIED -- decimal point e.g. dp="," --
width NUMBER #IMPLIED -- absolute or percentage width --
%block.align; -- horizontal alignment --
noflow (noflow) #IMPLIED -- noflow around table --
nowrap (nowrap) #IMPLIED -- don't wrap words -- >
<!ENTITY % cell "TH | TD">
<!ENTITY % horiz.align "left|center|right|justify">
<!ENTITY % vert.align "top|middle|bottom|baseline">
<!-- Terry's note: next para in practical terms places a requirement
on browsers that is not expressed in the SGML markup.
Browsers should tolerate an omission of the first <TR>
tag as it is implied by the context. Missing trailing
<TR>s implied by rowspans should be ignored.

The alignment attributes act as defaults for rows
overriding the colspec attribute and being in turn
overridden by alignment attributes on cell elements.
Use valign=baseline when you want to ensure that text
in different cells on the same row is aligned on the
same baseline regardless of fonts. It only applies
when the cells contain a single line of text. -->
<!ELEMENT TR - O (%cell)* -- row container -->
<!ATTLIST TR %attrs;
align (%horiz.align) #IMPLIED -- horizontal alignment --
valign (%vert.align) top -- vertical alignment --
dp CDATA #IMPLIED -- decimal point e.g. dp="," --
nowrap (nowrap) #IMPLIED -- don't wrap words -- >
<!-- Note that table cells can include nested tables.
Missing cells are considered to be empty, while
missing rows should be ignored, i.e. if a cell
spans a row and there are no further TR elements
then the implied row should be ignored. -->
<!ELEMENT (%cell) - O %body.content>
<!ATTLIST (%cell) %attrs;
colspan NUMBER 1 -- columns spanned --
rowspan NUMBER 1 -- rows spanned --
align (%horiz.align) #IMPLIED -- horizontal alignment --
valign (%vert.align) top -- vertical alignment --
dp CDATA #IMPLIED -- decimal point e.g. dp="," --
nowrap (nowrap) #IMPLIED -- don't wrap words --
axis CDATA #IMPLIED -- axis name, defaults to element content --
axes CDATA #IMPLIED -- comma separated list of axis names -- >

And here's the CALS-style table model from the Docbook DTD, with
elements and attributes that do some of the same things
specified in 3.0 marked with asterisks:

<!-- The CALS table specification derived from MIL-M-28001B. The only
difference is the content of Entry. InformalTable was derived
from Table by removing titling and the attributes: Label,
ShortEntry, and ToCentry. -->
<!ELEMENT *Table - - (*Title, TitleAbbrev?, (;))
<!ATTLIST Table *%commonatts;
*Colsep %yesorno; #IMPLIED
*Frame (Top|Bottom|Topbot|All|Sides|None) #IMPLIED
Orient (Port | Land) #IMPLIED
Pgwide %yesorno; #IMPLIED
*Rowsep %yesorno; #IMPLIED
Shortentry %yesorno; #IMPLIED
Tocentry %yesorno; %yes; >
<!-- InformalTable omitted -->
<!ELEMENT TGroup - O (ColSpec*, SpanSpec*, THead?, TFoot?, TBody) >
<!ATTLIST TGroup %commonatts;
*Align (Left|Right|Center|Justify|Char) Left
*Char CDATA ""
*Charoff NUTOKEN "50"
*Colsep %yesorno; #IMPLIED
*Rowsep %yesorno; #IMPLIED
<!ELEMENT *ColSpec - O EMPTY >
<!ATTLIST ColSpec %commonatts;
*Align (Left|Right|Center|Justify|Char) #IMPLIED
*Colsep %yesorno; #IMPLIED
*Rowsep %yesorno; #IMPLIED >
<!ELEMENT *SpanSpec - O EMPTY >
<!ATTLIST SpanSpec %commonatts;
*Align (Left|Right|Center|Justify|Char) "Center"
*Colsep %yesorno; #IMPLIED
*Rowsep %yesorno; #IMPLIED
<!ELEMENT *THead - O (ColSpec*, Row+) -(EntryTbl) >
<!ATTLIST THead %commonatts;
*VAlign (Top | Middle | Bottom) "Bottom" >
<!ELEMENT TFoot - O (ColSpec*, Row+) -(EntryTbl) >
<!ATTLIST TFoot %commonatts;
VAlign (Top | Middle | Bottom) "Top" >
<!ELEMENT *TBody - O (Row+) >
<!ATTLIST TBody %commonatts;
*VAlign (Top | Middle | Bottom) "Top" >
<!ELEMENT *Row - O ((Entry | EntryTbl)+) >
<!ATTLIST Row %commonatts;
*Rowsep %yesorno; #IMPLIED
*VAlign (Top | Middle | Bottom) #IMPLIED >

Yes, it's more complicated than Dave's model, but some of the CALS
stuff can be discarded. Dave's model could be rearranged in CALS
style without much trauma. I am looking forward to the table
DTD fragment SGML Open promised earlier; I'm not arguing for adopting
Docbook tables in HTML; but as the issue has been raised, I have to
says that using a subset of the CALS model has considerable advantages,
and Dave's is not a radically different model to begin with; thus
modifications as suggested by SGML Open are reasonable.

Terry Allen  (   O'Reilly & Associates, Inc.
Editor, Digital Media Group    101 Morris St.
			       Sebastopol, Calif., 95472
occasional column at:

A Davenport Group sponsor. For information on the Davenport Group see or