Newsgroups: comp.text.sgml Date: 22 Jan 1995 15:13:55 MET From: Paul Grosso <pbg@texcel.no> Subject: DSSSL & FOSITo recap this thread (pardon the necessary glossing over of details as I capture admittedly only part of each person's previous posting):
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
-- 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) Email: paul@arbortext.com or pbg@texcel.no