[Mirrored from: http://www.mcs.net/~dken/dslintro.htm. See a related version of the article in <TAG>, February 1997.]
One of the newest ISO standards positioned to impact the publishing world is ISO/IEC 10179. In 1988, ISO/IEC JTC1 SC18/WG8, the working group which developed SGML, HyTime, and some of the other SGML-related ISO standards, began writing this new standard. The working group had representatives from the United States, France, Japan, Germany, Ireland, Norway, the United Kingdom, and other countries as well. The new standard, also known as Document Style Semantics and Specification Language (DSSSL), became international standard in April 1996.
So, what exactly is DSSSL? How does it fit with SGML and HyTime? And why do we need DSSSL anyway?
Most readers clearly understand that the role of SGML is to provide a representation of document structure and content without regard to format or page layout. It turns out that neutral data encoding with SGML is quite valuable. Coding data in SGML means that from a single data source we can create our monthly publication, a yearly cumulative volume, and also deliver the data via CD-ROM or on the Web. We can share data, we can reuse data, and we can update data easily. Yet the issue of how to output data with a prescribed look and feel remains problematic. SGML defines no standardized formatting semantics. So if you must output, interchange, or archive data with associated style information, you require a standardized mechanism to do so. You need what has often been called the sister standard for SGML. You need DSSSL!
As an SGML consultant, I often work with clients to create document models. We create highly detailed document type definitions that define both document hierarchy and critical data constructs. We define what elements exist, what elements are made up of, and how elements relate to one another. And when the SGML definition is complete, the client usually moves on to focus on final output presentation:
At this point in the process, I must carefully re-explain that SGML cannot be used to specify style. "SGML", I explain, "separates content from format." I continue the litany, "SGML allows one to encode data independently of final output format." And the client replies, "But how can I specify output style? I need to print books. I need to deliver CD-ROM products. I want control over the style."
Without DSSSL the answer of how to specify style is weak and cumbersome. Most people are surprised to find out that they must prepare individual style sheets for each of the tools which make up an SGML system. So one style sheet must be created for the editorial interface, another for the composition engine, and another for electronic delivery. Three or more different style specification mechanisms must be employed. This means increased time and cost. And in addition, inconsistencies may occur which complicate the entire publication process.
In the past, publishers focused upon the benefits to be gained from standardizing text encoding with SGML. Today, with the maturity of SGML methodologies, tools, and systems, focus is shifting to the benefits that can be derived from using a standardized specification for document style. What people want is a single style sheet mechanism to work for all tools and all output media. More and more people today find they have a requirement for DSSSL.
The requirement to provide a mechanism to specify the style and format of an SGML document has been important to users since the initial adoption of SGML. Early adopters of SGML, lacking any way to specify style, added elements and/or attributes to DTDs which supported required stylistic features. It is not uncommon to find elements such as The requirement to provide a standardized style specification for SGML data became so important that an interim style specification standard was developed as part of the DoD CALS standards. This mechanism, based upon an SGML DTD designed to communicate style for military documentation, is known as the Output Specification. To use the Output Specification, or OS, one must create instance files (i.e. SGML coded style sheets) to accompany any particular DTD. These style sheets are known as Formatting Output Specification Instances (FOSIs). FOSIs were an improvement over compromising DTDs by adding style elements and attributes because FOSIs provide a mechanism to communicate style which is separate from the coding found in the SGML instance file.
The OS was intended to be a place-holder standard to communicate style/format for CALS documents. The OS was to be used until DSSSL was completed. Because FOSIs are really interim style sheets, they were not widely adopted outside the Department of Defense. And even within the DoD environment, implementation of FOSI stylesheets has been very limited. In fact, only two products support FOSI as a mechanism to communicate style. ArborText Adept Editor provides a FOSI creation mechanism and uses the FOSI to drive both their editorial interface and print output. Datalogics Composer is a high-speed batch composition engine which takes a DTD, a FOSI, and a document instance as inputs. Composer outputs PostScript pages complete with automatically generated tables of contents, indices and cross references. Implementation of FOSI tools was further impaired due to the lack of preciseness and rules which typify this interim industry standard. Now that DSSSL is an ISO standard, the DoD CALS activity must decide whether to make the shift to DSSSL or remain reliant upon FOSI to specify document style. While NATO is urging the adoption of the ISO standard DSSSL, the final DoD decision is pending.
So what is DSSSL? Well, DSSSL provides standardized syntax and standardized semantics to specify style and layout for SGML documents or SGML document fragments. Using DSSSL we can specify the style for an element or attribute, interchange that style specification, and reproduce that style within certain limitations.
DSSSL, like SGML is declarative in nature, and has no biases toward national language, writing direction, or character set. All style specifications in DSSSL are made by describing final formatting results, not by describing the algorithms to be used create the formatting result. In other words, DSSSL enables us to specify how data appears in output (print or electronic) but not how to create that format.
DSSSL has a clearly defined scope for output. First, of course, is hard copy output. This includes printed screens from SGML editors and both interactive (What-You-See-Is-What-You-Get (WYSIWYG)) and batch formatters. Soft copy, or electronic delivery, is also within the scope of a DSSSL specification. This includes both simple screen formatting and complex screen layout complete with fonts, colors, and multi-column text. Finally, the output of SGML document transformations is within the scope of the standard.
It is important to note that the scope of DSSSL is limited in certain ways. First there is no support for hand-crafted page layout such as wraparounds or frame placement. And because the standard does not define formatting algorithms, no support for page or line fidelity is intended. This means that while DSSSL enables us to specify the style and layout of an SGML document, it cannot guarantee line-for-line breaks nor exact page break points.
Within the style specification portion of DSSSL, the specification of very robust typographic style is supported. Yet, for many publishing applications a large number of DSSSL's typographic features are not required. The designers of DSSSL therefore designated certain features of the style specification language as optional and created a Core Expression Language and Core Query Language in order to make the development of limited DSSSL applications possible. Rather than defining the limited subsets of DSSSL within the standard, the designers left that activity to interested industry organizations and standards bodies. The DSSSL Online Application Profile (DSSSL-O) is one such subset.
DSSSL-O was begun in December 1995 by SGML tools vendors and other interested parties. This subset of DSSSL was designed specifically to support the requirements of on-line browsers and editors. In addition to the core features required by ISO/IEC 10179, DSSSL-O adds DSSSL options required to support vertical scrolling and basic print output. The basic motivation behind the development of DSSSL-O is to provide the semantics to serve generic SGML documents over the Internet. DSSSL-O is available at:
http://occam.sjf.novell.com:8080/docs/dsssl-o/do951212.htm
The success of any new standard depends in great part on two factors. First is education of the user community, without which little if any acceptance of the standard can be achieved. And second is the availability of tools(without which use of any standard is tedious and error-prone.
For SGML, the free availability of sgmls and later SP authored by James Clark provided the community with a technology base upon which to grow. Now James Clark is making a DSSSL style engine available to the community as well. Jade is a free, high-performance implementation of the DSSSL style language which allows you to get formatted output from an SGML document by using a DSSSL style sheet. Jade has a modular design that allows new output types to be supported by simply adding a new backend output module. Currently RTF is supported with backends for TeX and HTML under development.
When I saw Jade demonstrated at GCA's InfoTech Week in Seattle, it brought DSSSL to life for me. An SGML document and a DSSSL Style Specification were input to Jade and out came formatted page in RTF! Changes in the DSSSL Style Specification were immediately mirrored in new formatted output from Jade. DSSSL was real! DSSSL could work!
Now of course, Jade alone is not enough. Jade, in fact, is merely the starting point. Jade demonstrates the viability of DSSSL to specify style for existing publishing systems (one of the stated goals of DSSSL) and the capability of using DSSSL to format SGML text. Many challenges still exist. New "backends" or other Jade-like engines must be written to support the host of delivery media available today. And authoring a DSSSL style specification is no small task! One of the greatest challenges will be to develop an easy-to-use DSSSL style-sheet editor. Writing a DSSSL style sheet with DOS-Edit or VI is neither fun nor efficient. The DSSSL style sheet editor is the next breakthrough that DSSSL-based publishers require if DSSSL is to thrive as a viable ISO standard.
Jade is among the first early implementations of DSSSL. Other tools, including DSSSL syntax checkers, style engines, and SGML transformation engines are currently being developed as well. However, market demand is required before vendors commit to serious DSSSL tools development. DSSSL tools will only become readily available if people make DSSSL functionality a requirement for their new publishing system procurements.
(Return to Home Page)
What is DSSSL?
Scope of DSSSL Output
What About DSSSL Online (DSSSL-O)?
DSSSL Style Language Tools