Harvey Bingham
Original public version 1.3 2000-06-30
The "CALS Table Model" is the most widely adopted industry SGML representation for tables. It was developed by the CALS Industry Steering Group Electronic Publishing Committee (EPC). Its basis was a minimal description and example of a table from the prior Mil-M-38784B specification for producing technical manuals. The incomplete specification of the semantics associated with the table model allowed too much freedom for vendor interpretation, and resulted in problems with interchange. SGML-Open (now OASIS) surveyed the implementing vendors to identify differences, as the initial step toward reaching a common interpretation. The next step was an updated CALS Table Model Document Type Definition and semantics. Both are now available from OASIS.
1. EPC Table Subcommittee |
2. Table Guidance from MIL-M-38784B |
3. Beyond Guidance, Existing Tables |
4. Mistakes with the CALS Table Model |
5. DoD Abandoned the Generic Technical Manual DTD |
6. Implementation Differences |
7. Corrective Action |
8. Biographic Data
The EPC was made up of industry and military service representatives. Some represented traditional military document printing agencies. Others represented electronic publishing organizations. SGML itself was new. The EPC was responsible for the SGML technical content of the MIL-M-28001A overriding SGML specification for CALS. The "MIL-M-38784B conforming" DTD was part of 28001A. At that time, the CALS intent for all their technical manuals was to use that DTD to achieve system-neutral interchange of content and structure.
An EPC subcommittee, of which I was co-chair and a major contributor, designed the CALS Table Model in 1989-1990. Our minimal requirements guidance came from MIL-M-38784B, Technical Manuals, Guide for the Preparation. That guidance was in essence, do what the prototype table did:
Many legacy technical manuals included far richer table models, even though they had been approved as 38784-conforming (often to an earlier version.) We examined tables in a sample of other technical manuals and noted significant variety. Often the tables appeared as artwork, with marks such as revision indications added wherever whitespace was available.
The military wished to preserve their change-page model for legacy paper document updating. This had some impact on the table model design:
We rejected the desire for some table pages as graphics with only the changed pages of that table tagged. Instead, a legacy table design that doesn't match the DTD can be tagged as a complete sequence of full-page graphics. In the published CALS Table Model, such a table could not have an explicit title, as it was part of the graphic.
The means to associate presentation to that DTD was designed in 28001A. The Output Specification was a DTD for specifying formatting characteristics. A Formatted Output Specification Instance (FOSI) written to that OS DTD would convey the presentation information for any document tagged to that 38784 DTD. Many of the geometric attributes in the CALS Table Model were provided with the expectation that they would simplify the preparation of a FOSI for it that would be reusable in other FOSIs.
We did not have detailed implementation experience with the CALS Table Model, though several other members and I had done prototypes as it evolved. None of us were funded by government contract to develop the model.
The consequence of this decision was loss of design control. That table model was nominally adopted by most other groups preparing industry or DoD DTDs. Most of the elements and attributes were copied into the other DTDs, and modified for the perceived needs of the individual DTDs.
Many of those changes had significant impact on the table implementations. Some added to interoperability problems.
Writing the containing specification MIL-M-28001A was the responsibility of the government. The assigned staff did not understand the nuances of SGML nor the DTD, much less the table model. After EPC repeatedly expressed concern, cognizance for 28001 went to the Air Force. Their contractor made major improvements, but several errors crept into the table model when 28001B was released 26 June 1993.
About that time, MIL-M-38784C was evolving, based on the example DTD of 28001A, rather than the 38784B-conforming DTD. That example DTD had significant SGML shortcomings compared to the one the EPC had focused on when the 38784B conforming DTD was part of 28001. A single set of semantics was used to cover both DTDs, regardless of their differences. No consistency checks were apparent. Progressively less rigorous review of the semantics occurred in these several flavors. The errors in 28001A were repeated later when the example DTD was moved into MIL-HDBK-28001 (30 June 1995).
The inheritance choices and ordering were not clear for those attributes whose values could be specified in several tags. Different vendors made different choices for inheritance.
Design by committee retained each of the several interested parties' ways of doing things. For examples:
colname and colnum are alternative ways to
identify columns
spanspec referenced by
<entry spanname="spanname">
is shorthand for
<entry namest="colname1"
nameend="colname2">
The redundancy resulted in partial and different implementations. Some systems accept either of redundant forms, but export only one. Thus, the table tagging from one vendor may be successfully imported, but changed to its favored choices when re-exported. Another vendor may not accept that alternative.
The DoD decided that many individual technical manual specifications should continue to exist, and each should include its own DTDs and FOSIs. This diffused the talent available to augment those documents, and their DTDs and FOSIs. Limited tools were available to check them. Content specific tags replaced generic ones. Little was shared. Leverage from reusable material was lost. Entropy won.
The structural part of the CALS Table Model was a principal transplant into most of these DTDs. The cell content generally differed. Sometimes the content models of the geometric tags were altered. Global inclusions were overlooked or allowed, and exclusions eliminated such as the table exclusion from table, Some variation in the kind of forced breaks occurred.
As implementations of the CALS Table Model came along, a number of ambiguities and omissions were detected and reported to the EPC committee, These were forwarded to the appropriate custodians. There was no longer a single place to resolve these. The versions in the different specs got out of step, since they were on different update cycles. Each application required custom changes to accommodate to those differences. Consequently the implementations of the table model diverged in the details, and the attempts at interchange of tables resulted in different appearance.
Since SGML is not primarily about presentation, some of those differences were ignored, as the style descriptions would determine the presentation. However, few vendors adopted the FOSI style mechanism, and those that did noted the weakness in its table style description, particularly when guided by the attributes from the table DTD model. Other vendors applied their proprietary presentation systems, to different effect.
The differences in interpretation had lead to serious interoperability problems. OASIS identified these in candid cooperative contributions from the vendors who claimed to have implementations of the CALS Table Model. See Table Interoperability Issues for the CALS Table Model, OASIS Technical Research Paper 9501:1995, Eric Severson and Harvey Bingham, November 21, 1995 for details.
One result of that survey is the OASIS completion of the CALS Table Model Document Type Definition OASIS Technical Memorandum TM 9502:1995.
A second result of that survey is a subset of the full CALS table model that has high probability of interoperability among the OASIS vendor products. It is the Exchange Table Model Document Type Definition OASIS Technical Resolution TR 9503:1995.
Harvey Bingham worked on SGML applications for eight years at Interleaf. He has been implementor, designer, CALS Electronic Publishing Committee member, and advocate for the use of the CALS Table Model. He influenced its acceptance by other industries including commercial aviation ATA 2100, automotive J2008, semiconductor Pinnacles, and software documentation Docbook. He chaired or co-chaired the OASIS technical subcommittee on tables. He has had significant influence on HTML tables. He also contributed to the development of DSSSL. He is now an independent consultant, and remains active in the W3C Web Accessibility Initiative, and the Library of Congress National Library Service for the Blind and Physically Handicapped consulting responsible for the digital talking book XML application. His primary interest is accessible document design. He can be reached by email: hbingham@ACM.org. His homepage, http://users.rcn.com/hwbingham/ndex.htm, also contains syntax summaries for SGML and DSSSL, and some of his work on accessibility of information for everyone.
Version 1.3 1998/06/30
Version 1.4 repaired broken oasis link, eliminated tiac 2001-09-28
Version 2.0 Updated content references 2002-02-27