Newsgroups: comp.text.sgml
Date: 22 Jan 1995 15:13:55 MET
From: Paul Grosso <>
Subject: DSSSL & FOSI
To recap this thread (pardon the necessary glossing over of details as I capture admittedly only part of each person's previous posting):
  1. Bob Agnew considers that DSSSL has impeded the progress of SGML and wishes FOSIs had "won out."
  2. Len Bullard says that FOSI (that is, the Output Specification or OS) is an application of SGML, not a standard; that the OS was a stopgap application developed while waiting for DSSSL; that there was an overlap of people working on the OS and DSSSL (and kindly mentions myself and Paula Angerstein as examples); that FOSIs have been implemented by two vendors while the rest waited for DSSSL.
  3. Erik Naggum speaks of companies out there who try to destroy DSSSL to protect their own interests (and thoughtfully adds that he's not speaking of those who have implemented FOSIs).
  4. Glenda Jeffrey quotes some of ArborText's whitepaper "pap" about how the FOSI and DSSSL standards groups are working together to ensure a conversion path from FOSI to DSSSL and wonders if she'll be left high and dry if she goes with FOSIs (or more specifically, with ArborText) and then DSSSL gets off the ground.
The SGML standard (ISO 8879) does not define a formatting language. For SGML-encoded information to get composed, various application semantics (e.g., style sheets in the simplest case) must be associated with the various markup constructs used to encode the given information.

There are various ways to do this, and to date almost all of them have been "proprietary" -- by that I mean developed and used by a single for-profit company. In theory, there is really nothing inherently wrong with this, and SGML has been used to great advantage for almost a decade with mostly proprietary methods of attaching (formatting and other) semantics. However, way back before 8879 was passed in 1986, it was realized that a standard way of attaching (at least formatting) semantics to SGML applications was a worthwhile thing, and work toward the standard which later became known as Document Style Semantics and Specification Language (DSSSL) began at the ISO standards level.

Meanwhile, in the late 1980's a lot of SGML-related action in the US was concentrated on the US government's CALS initiative. The CALS Industry Steering Group's Electronic Publishing Committee (EPC) became the key driving force behind the development of the CALS standard called MIL-M-28001, "Markup Requirements and Generic Style Specification for Electronic Printed Output and Exchange of Text." It was realized at the time by members of the EPC that CALS would benefit from agreeing on a standard way to describe and interchange "style and format requirements." It was also realized that the DSSSL effort, with its complex international and wide-ranging scope, would be a while in coming, so the EPC formed an OS subcommittee to develop an Output Specification that addressed the smaller scope of specifying the formatting of documents with composition requirements that were defined mostly by US government technical manuals.

It was assumed that CALS would use FOSIs until DSSSL could be evaluated for possible (in fact, probable) CALS use. Several members of the original OS committee were also members of the ISO DSSSL committee, and the overlap between the committees has continued to varying degrees through to today. The OS was developed by a multi-vendor industry committee. For whatever reasons, many companies that participated in the development of the OS did not create products that supported the OS. Many companies indicated that they were "waiting for DSSSL" (though it is interesting to note that many of those vendors with proprietary methods of attaching formatting semantics to SGML-encoded information were not participating on the DSSSL committee whereas the two commercial vendors who now support FOSIs were both represented on the DSSSL committee for most of its existence).

In the late 1980's when ArborText was designing its editor and composition tools that could handle any SGML DTD, we had to address the issue of attaching formatting semantics to arbitrary SGML markup. Our choices at the time were to do something proprietary or to use the OS defined in MIL-M-28001. While the latter wasn't/isn't an International Standard, it was/is a US government standard and was (and, in fact, remains with the exception of the DSSSL Draft International Standard published last fall) the only non-proprietary option. ArborText decided in favor of the OS and since that time has been actively involved in both the EPC/OS standards process and the DSSSL standards process. We continue to work on the OS standard; an important milestone has just been finalized (amendment 1 to MIL-M-28001B), and cooperation among the various implementors of FOSI-based composition systems has dramatically increased over the last year.

Meanwhile, along with many of the experts in the SGML area, ArborText in general and myself in particular are very interested in DSSSL. I was one of the key instigators of the SGML Open/WWW effort to develop a practical DSSSL subset (known as DSSSL Lite) that could form a basis for specifying simple formatting semantics that would be usable by SGML vendors as well as Web browsers, and ArborText has plans to add some subset DSSSL support in its upcoming releases. The CALS community plans to develop its own subset of DSSSL with generally equivalent functionality to the current OS. Since, by definition, every single ArborText customer is a FOSI user, and since we are heavily involved in the development of DSSSL, it is clearly in our best interest to support FOSI users with respect to the transition to DSSSL. We plan to make the use of DSSSL by our customers as painless as possible, and our ongoing work on both standards as helped to ensure that this will be feasible. It will take some effort before DSSSL use is widespread, and I still believe that effective use of FOSIs will continue for some time. ArborText is committed to supporting its customers' use of standards such as the OS and DSSSL that improve the interoperability of SGML.

In summary, FOSIs are good, DSSSL has the potential (and every expectation) to be better, the transition is feasible and of crucial importance to vendors such as ArborText, and I believe the progress of SGML continues to the benefit of a very large and rapidly growing community.


Paul Grosso
VP Research, ArborText, Inc.    
Chief Technical Officer, SGML Open                  
Chairperson, OS/FOSI/DSSSL subcommittee of the CALS EPC
Member, ISO JTC1/SC18/WG8 (the SGML/HyTime/SPDL/DSSSL working group)


This page was last changed on Jan 23 1995, 16:28 by Comments and corrections welcome.