Harvey Bingham
Links updated Version 2.1 2002-02-27,
Version 2.2 2002-04-19
1. Background
2. Oasis Addresses the Issues
2.1. Table Interoperability
2.2. CALS Table Model Completion
2.3. Oasis Exchange Table Model
3. Comparison of CALS and Exchange Table Models
3.1. Typographic Conventions
3.2. Parameter Entities
3.3. Element and Attlist Comparison
3.4. Attribute Inheritance
4. Conclusions
5. Acknowledgments
6. References
7. Biographic Data
Oasis is an international consortium of over 50 users, vendors, and consultants dedicated to the furtherance of SGML applications. The Marketing Committee addresses the benefits from using SGML for applications through white-papers, case studies, seminars, and education. The Technical Committee has among its objectives the identification of technical issues that impede open interchange of SGML documents between users. One major issue is the representation of tables.
A table provides a compact way to represent relationships, and to present them in two dimensions. The SGML representation of a document instance is linear, so a table is linear too (unless a non-SGML notation is used to represent the table final form as a graphic.) The two-dimensional table structure maps into table rows and columns. The cell at the intersection has content. When linearly tagged, only one of row or column appears in the strict hierarchy common to naturally hierarchic linear tagging. The other is implied from the ordinal position of each cell. Most SGML table tags convey structure and their attributes may indicate some geometrical aspects. The cells also contain content.
The CALS Table Model was the first to receive significant implementation by multiple SGML vendors. I have recorded my recollection of the history of the CALS Table Model including the technical design decisions. That model was adopted by many industry and government SGML applications. Each vendor claimed support for it, sufficient to meet a "check-list" requirement in a request for proposal. Later, however, users had difficulty exchanging tables tagged to that model between vendor products.
The different implementors had used their own interpretations of the ambiguities in its incomplete specification, and the constraints of their individual systems. Differences occurred. No effective test suite was developed.
The users used their vendor's implementation and accepted their vendor interpretations where semantics were weak. The users detected differences when they used more than one vendor product. Oasis reallized this was an obstacle to wider use of SGML, so we decided to find out what those differences were.
We started by developing a vendor survey of their implementations to determine table interoperability differences and significant issues of interpretation. We submitted through the EPC to CALS completed semantics and corrected several errors in the CALS Table Model. We identified the Exchange Table Model, the subset of the CALS Table Model appropriate for interchange of tagged tables.
Oasis identified as a major issue the need for interchange among users of tagged tables. All vendors who claimed support for the CALS Table Model had made major investment in their implementations. Having a consistent implementation of a standard table model simplified the development of other SGML applications that included that table model. We reallized the advantage to all users in having a consistently understood and supported table model.
At a finer technical level of granularity exposed by the survey, many qualifications and limitations appeared. Some elements were not universally supported. Other elements and attributes were recognized on import, but not exported. Some attributes were ignored. Others were interpreted differently.
Eric Severson and I produced a list of 130 detailed interpretation questions. Six vendors examined their implementations to determine what tagged input they accepted, how they interpreted that input for presentation, what tagged output they produced, and what changes occur with comparable effect from import to export. Our analysis of the responses and suggestions from contributors lead to additional questions and clarifications, then another round of vendor survey. One more vendor participated in that round.
At this microscopic level we found that all vendors answered "in the minority" on several dozen questions, with little similarity in those difference sets. No wonder the users were having trouble using SGML tables in an open manner across implementations.
This experience in cooperation among the vendors in admitting the limitations and exposing their disagreements in implementations is an important contribution of Oasis. Each vendor became aware of how its implementation was different. Most agreed that consistent repairs were important. So, we needed to determine what would be consistent. Product reengineering would be needed to achieve that consistency. Also, vendors starting to implement the table model gained a basis for avoiding the mistakes earlier implementations had made.
We realized that the geometric part of the CALS Table Model was the most important focus for clarification. In contrast, the inner-most cell content model and exceptions to it were subject to change. So were the outer-most table content model, and its non-geometric attributes.
As a result of understanding how the vendors had interpreted the partial semantics conveyed in the Tag Descriptions of MIL-HDBK-28001, we revised and completed the semantics of the table tags. We carefully identified the inheritance path for each of the attributes. We identified a few technical errors in the original table model.
We decided to express the CALS Table Model DTD using parameter entities so such changes could be explicitly contrasted in a particular application, and could override a reference to the public entity of the underlying CALS or Exchange Table Models.
The resulting technical memorandum TM9502 has been approved by the CALS Industry Steering Group and the Defense Information Systems Agency Center for Standards Information Processing Directorate as "the" CALS Table Model. It will be officially registered.
This subset of the full CALS Table Model has been generally implemented by the vendors. Tables tagged to this subset have high likelihood of common interpretation by systems from any of the vendors. This report was balloted by the Oasis members and approved. Implicit in that approval is that vendor products in their next releases should implement those capabilities according to the semantics included in the report if they don't already.
The Exchange Table Model does not replace the CALS Table Model. Since it is a proper subset, systems that support the CALS Table Model should be able to support the Exchange Table Model. Users who have no need to interchange with different vendors' systems may use its interpretations and additional capabilities, without the short-term consequences of the different interpretations of the full CALS Table Model semantics. In the longer term, should exchange with or migration to a different vendor be desired, the tables will work better if they are constrained to use the Exchange Table Model.
In the Exchange Table Model the definitions of element types and attribute lists contain many parameter entities. Using the restrictive definitions of those parameter entities, the Exchange Table Model results. Using the inclusive definitions, the CALS Table Model results. Other variations are possible, though such changes may cause interchange problems.
The Oasis updating for the CALS Table Model appears in this section in expanded parameter entity form. This presentation simplifies the comparison with the subset in the Exchange Table Model.
The standard SGML representations apply. However, terms are differentiated by typeface:
| roman | CALS parameter entities, element types, and attlists in both CALS and Exchange |
| italic | CALS material omitted from Exchange. |
In the element and attribute definitions for the CALS Table Model and the Exchange Table Model, parameter entities are used extensively. These are named with prefix "tbl." element type, and suffix to indicate usage:
| ".name" | name of element type or ATTLIST associated element type |
| ".mdl" | content model or declared content |
| ".excep" | exceptions |
| ".att" | attribute definition list |
The first five parameter entities below are defined in the DTDs outside the CALS Table Model. The values below are simplified, as they do not affect the geometric aspects of the table models.
ENTITY % bodyatt ""
ENTITY % secur ""
ENTITY % paracon "(para|warning|caution|note|legend|#PCDATA)*"
ENTITY % titles "title?"
ENTITY % yesorno "NUMBER"
ENTITY % tbl.table.name "(table|chart)"
ENTITY % tbl.table-titles.mdl "%titles;,"
expanded: "title?,"
ENTITY % tbl.table-main.mdl "(tgroup+|graphic+)"
ENTITY % tbl.table.mdl "%tbl.table-titles.mdl; %tbl.tbl-main.mdl;"
expanded: titles;, (tgroup+|graphic+)"
ENTITY % tbl.table.excep "-(table|chart|figure)"
ENTITY % tbl.table.att '
tabstyle NMTOKEN #IMPLIED
tocentry NUMBER #IMPLIED
shortentry NUMBER #IMPLIED
orient (port|land) #IMPLIED
pgwide NUMBER #IMPLIED'
ENTITY % tbl.tgroup.mdl "colspec*,spanspec*,thead?,tfoot?,tbody"
ENTITY % tbl.tgroup.att '
tgroupstyle NMTOKEN #IMPLIED'
ENTITY % tbl.hdft.name "(thead|tfoot)"
ENTITY % tbl.hdft.mdl "colspec*,row+"
ENTITY % tbl.hdft.excep "-(entrytbl)"
ENTITY % tbl.row.mdl "(entry|entrytbl)+"
ENTITY % tbl.row.excep "-(pgbrk)"
ENTITY % tbl.entrytbl.mdl "colspec*,spanspec*,thead?,tbody"
ENTITY % tbl.entrytbl.excep "-(entrytbl|pgbrk)"
ENTITY % tbl.entry.mdl "(%paracon)*"
expanded: "(para|warning|caution|note|legend|#PCDATA)*"
ENTITY % tbl.entry.excep ""
ENTITY % tbl.entry.att ""
Changes to these parameter entities should be carefully justified. They may have significant effect on the ability to interchange table information. These changes may manifest themselves in useability, presentation, and possible structure information degradation.
The elements and attributes of the CALS Table Model appear below, ordered top-down. Italic indicates material that is only in the CALS Table Model, but not in the Exchange Table Model.
<!ELEMENT (table|chart) - - (title?, (tgroup+|graphic+)) -(table|chart|figure) > <!ATTLIST table frame (top|bottom|topbot|all|sides|none) #IMPLIED colsep NUMBER #IMPLIED rowsep NUMBER #IMPLIED tabstyle NMTOKEN #IMPLIED tocentry NUMBER #IMPLIED shortentry NUMBER #IMPLIED orient (port|land) #IMPLIED pgwide NUMBER #IMPLIED > <!ELEMENT tgroup - O (colspec*,spanspec*,thead?,tfoot?,tbody) > <!ATTLIST tgroup cols NUMBER #REQUIRED tgroupstyle NMTOKEN #IMPLIED colsep NUMBER #IMPLIED rowsep NUMBER #IMPLIED align (left|right|center|justify|char) #IMPLIED char CDATA #IMPLIED charoff NUTOKEN #IMPLIED > <!ELEMENT colspec - O EMPTY > <!ATTLIST colspec colnum NUMBER #IMPLIED colname NMTOKEN #IMPLIED colwidth CDATA #IMPLIED colsep NUMBER #IMPLIED rowsep NUMBER #IMPLIED align (left|right|center|justify|char) #IMPLIED char CDATA #IMPLIED charoff NUTOKEN #IMPLIED > <!ELEMENT spanspec - O EMPTY > <!ATTLIST spanspec namest NMTOKEN #REQUIRED nameend NMTOKEN #REQUIRED spanname NMTOKEN #REQUIRED colsep NUMBER #IMPLIED rowsep NUMBER #IMPLIED align (left|right|center|justify|char) #IMPLIED char CDATA #IMPLIED charoff NUTOKEN #IMPLIED > <!ELEMENT (thead|tfoot) - O (colspec*,row+) -(entrytbl)> <!ATTLIST (thead|tfoot) valign (top|middle|bottom) #IMPLIED > <!ELEMENT tbody - O (row+)> <!ATTLIST tbody valign (top|middle|bottom) #IMPLIED > <!ELEMENT row - O ((entry|entrytbl)+) -(pgbrk)> <!ATTLIST row rowsep NUMBER #IMPLIED valign (top|middle|bottom) #IMPLIED > <!ELEMENT entrytbl - - (colspec*,spanspec*,thead?,tbody) -(entrytbl|pgbrk) > <!ATTLIST entrytbl cols NUMBER #REQUIRED tgroupstyle NMTOKEN #IMPLIED colname NMTOKEN #IMPLIED spanname NMTOKEN #IMPLIED namest NMTOKEN #IMPLIED nameend NMTOKEN #IMPLIED colsep NUMBER #IMPLIED rowsep NUMBER #IMPLIED align (left|right|center|justify|char) #IMPLIED char CDATA #IMPLIED charoff NUTOKEN #IMPLIED > <!ELEMENT entry - O ((para|warning|caution|note|legend|#PCDATA)*) -(pgbrk) > <!ATTLIST entry colname NMTOKEN #IMPLIED namest NMTOKEN #IMPLIED nameend NMTOKEN #IMPLIED spanname NMTOKEN #IMPLIED morerows NUMBER #IMPLIED colsep NUMBER #IMPLIED rowsep NUMBER #IMPLIED align (left|right|center|justify|char) #IMPLIED char CDATA #IMPLIED charoff NUTOKEN #IMPLIED rotate NUMBER #IMPLIED valign (top|middle|bottom) #IMPLIED >
The value of an attribute is taken from the most specific tag that has a value from like-named attributes in the different associated element lists. In the attribute lists below, the full potential inheritance is shown, general to specific, left to right. Material in parentheses separated by "|" are alternatives. Material followed by "?" may appear, though it needn't.
Note that the inheritance is not strictly hierarchic: no particular colspec is in the lineage for a particular entry. For an entry in an entrytbl, additional elements from its definition analogous to those to the right of tgroup appear and may affect the entry. Also, only one of thead, tfoot, or tbody is appropriate as parent of the row containing the entry (or entrytbl).
| Parameter Entity or Attribute Name |
In ATTLISTs of Associated Element Lists |
Comments |
|---|---|---|
| %bodyatt; | table | placeholder for
information about table in containing document context, Exchange set content to "" |
| %secur; | table tgroup (thead | tfoot | tbody) row (entrytbl (thead | tfoot | tbody) row)? entry | no attempt to model security inheritance, Exchange set content to "" |
| align | tgroup colspec spanspec (entrytbl colspec spanspec)? entry | horizontal alignment of entry content |
| char | tgroup colspec spanspec (entrytbl colspec spanspec)? entry | alignment character if align="char" |
| charoff | tgroup colspec spanspec (entrytbl colspec spanspec)? entry | percent from left edge of cell for char alignment |
| colname | colspec (entrytbl colspec)? entry | name of column |
| colnum | colspec | redundant to preferred colname, starting with 1 at left |
| cols | tgroup entrytbl | max columns |
| colsep | table tgroup colspec spanspec (entrytbl colspec spanspec)? entry | vertical rule to right of entry |
| colwidth | colspec | proportional "N*", fixed "Nu", mixed "N*+Mu", multiple "Nu+Mv" where M and N are integer, u and v a unit of measure |
| frame | table | ruling around outside of table |
| morerows | entry | vertical spanning down if positive integer number value |
| nameend | spanspec (entrytbl spanspec)? entry | end of horizontal span, a colname from colspec |
| namest | spanspec (entrytbl spanspec)? entry | begin a horizontal span, to left of nameend, a colname from colspec |
| orient | table | "port"=portrait by default, or "land"=rotate table 90 degrees counterclockwise |
| pgwide | table | table width: 0=galley column, 1=page |
| rotate | entry | content rotate 90 degrees counterclockwise |
| rowsep | table tgroup colspec spanspec row (entrytbl colspec spanspec row)? entry | horizontal rule below entry |
| shortentry | table | external to table use text for alternative shorttitle |
| spanname | spanspec (entrytbl spanspec)? entry | use namest nameend pair instead |
| tabstyle | table | table style attributes source, overridden by explicit table attribute values |
| tgroupstyle | tgroup entrytbl | tgroup style attributes source, overridden by explicit tgroup attribute values |
| tocentry | table | include table title in list of tables if =1 |
| valign | (thead | tfoot | tbody) row entry | vertically align content in entry |
Oasis has responded to significant user interchange issues. This technical work is the result of excellent cooperation among competing vendors. We determined the limits of our understanding. We sought consensus. We balloted the Table Interoperability Technical Research Paper TRP 9501:1995. We provided the CALS Table Model DTD Technical Memorandum TM 9502:1995 to the CALS EPC, completing work that should have been properly contracted several years ago. We identified the common supported parts of the CALS Table Model, and produced and balloted the Exchange Table Model, Technical Resolution TR 9503:1995 from it. This work benefits the other industry SGML applications that will get interchangeable tables.
I thank the many contributors to these studies. In particular Eric Severson, Oasis Chairman, initiated this effort, formulated the detailed vendor survey questions, and generalized the survey responses. Paul Grosso, Oasis Chief Technical Officer, provided thorough technical and editorial work. He produced much of TR9503, by extracting the material from TR9502, and reformatting it to avoid the table format for the semantic descriptions.
The following papers are available for downloading from Oasis, in either the online version in HTML, or by FTP. Either tar or zip forms are available in source SGML or PostScript from OASIS.
The following papers contain further history and comparisons on the above. They are available in the url "http://www.hbingham.com/tables/".
Harvey Bingham worked on SGML applications for 8 years at Interleaf till 1996. He has been table model implementor, designer, CALS Electronic Publishing Committee member, and advocate for the use of the CALS Table Model by other industries including ATA 2100, automotive J2008, semiconductor Pinnacles, and software Docbook. He has had significant influence on HTML tables. He also contributed to the development of DSSSL. He is now an independent consultant, focusing on accessibility for all. He may be reached by email: hbingham@ACM.org. His homepage, http://hbingham.com/ contains in subdirectories the extensively hyperlinked syntax summaries for SGML and DSSSL that he created as learning aids, and information on accessibility, as well as information on the CALS and Exchange Table Models.
Version tblmdcmp.htm 1.2.2 2000-03-01
Version 2.0 Updated doctype and links 2002-02-27
Version 2.1 Updated links 2002-02-27
Version 2.2 Updated links 2002-04-19.