[Mirrored from: http://www.sgmlbelux.be/96/schietek.htm]
Raf Schietekat
Fotek NV
Entrepotstraat 3
B-9100 Sint-Niklaas
E-mail : raf@fotek.com
SGML (Standard Generalized Markup Language) is designed to encode information at the content level, abstracting away from formatting issues. In a well-designed SGML application, font details are not part of the SGML document, and contents may be rearranged or automatically generated.
In this light, for professional purposes HTML (HyperText Markup Language) is better considered to be a presentation language for contents that have been stored separately (e.g. in a dedicated SGML environment) than a reliable repository data storage format in itself. This now probably well understood, at least in the SGML community. HTML is tied to a particular, very limited DTD (even ignoring the reality of emerging Microsoft and Netscape dialects), and requires independently specified semantics (i.e. how the Web browser has to interpret the HTML tags).
In general, SGML documents will be typeset using informal descriptions of the style semantics for the various elements that occur in a document instance, which requires good communication between the document publisher and the document typesetter. Once a system is set up to process a particular kind of SGML input, that style specification is generally not portable.
The new ISO standard DSSSL (Document Style Semantics and Specification Language) aims to become the standard way of linking up SGML information containers with their graphical representation, as part of a suite of complementary ISO standards: SGML, HyTime, SPDL (Standard Page Description Language, based in part on the PostScript language from Adobe).
This paper will elaborate on the details of how DSSSL achieves this, how it fits into a complete document production process, how detailed the specification is and what it leaves open, what other functionality is available, and why it was worth waiting for.
Keywords: SGML, DSSSL, formatting
If you thought you understood SGML by now, if you thought you more or less knew all the nooks and crannies of that delightful bedside reading known as The SGML Handbook (by Charles F. Goldfarb), if you were getting slightly bored explaining to lesser mortals yet again the difference between an omitted end tag, an empty end tag and a null end tag, you have been crying victory too soon.
Take cover: DSSSL is upon us (pronounce "dissel"), with wonderful new toys like groves, flow objects, sosofos, areas and Standard Document Query Languages. Now we don't just have these boring element attributes anymore, but also properties and characteristics (some of the latter can even be inherited).
But enough scare mongering. If you take the amount of documentation about a standard as a measure of its complexity, DSSSL is indeed twice as complex as SGML itself. It contains forty pages of very terse formal specifications (clause 9.6), and remains very vague in other topics (just compare clause 12.3 about areas with a PostScript manual). It introduces a complete programming language, and a whole lot of details that can only be mastered through hands-on experience.
Put in very simple terms, this is what happens when DSSSL is used to format a document. A piece of text is parsed by an SGML parser which is contained in the DSSSL formatter. Parsing means: making sense of all the parts to extract a structure that goes beyond a simple succession of character codes, similar to finding subjects, verbs, and other parts, in a natural language like English. Conceptually, the structure emerges in the form of a tree decorated with attributes, data, and perhaps markup details. Starting with this tree, a second tree is formed which is a modification of the first tree, with pieces omitted, generated, or rearranged. It is also possible to make a third tree, and a fourth or more, if it turns out that this is a good way to reduce complexity or to recycle other document format specifications, but just one new tree may also be sufficient. The last tree corresponds to a very specific document type, as it were, which should be understood by the formatter to be conformant to the formatting language.
Of course, if you look at the DSSSL standard, you will see a difference between groves, and flow object trees, in the two parts of the process (transformation and layout), but that's just syntax. DSSSL formatting is essentially a transformation to a standard DTD (describing the structure of a flow object tree), and after that a formatter can take over. The fact that this standard DTD is not made explicit is just done to confuse you.
Life for an SGML professional would be so much easier if some things were unified that are now fragmented. Just look at the number of possible document transformations that we now have to deal with:
(Architectural forms handle an oversight in the original specification of SGML: it was not possible, as in TeX, to define one's own macros for a particular feature, and have this feature inherit the formatting of a more general feature.)
Far from specifying how a document should be formatted with platform-invariant accuracy (which is something you can expect from a conformant TeX implementation), DSSSL leaves a great deal up to the underlying engine. An example:
In TeX, a paragraph is taken as a whole, and all possible ways of breaking it up into lines are evaluated. Unreasonable choices are eliminated early enough to avoid wasting too much time on this otherwise NP-complete problem (where NP-complete in simple terms means taking an awfully long time to solve). If the result is not satisfying even then, TeX will try a second time, considering hyphenated breaks as well. The net result, in general, is an evenly spaced-out text, with very few hyphenated breaks, if TeX gets enough maneuvering space. DSSSL does not even mention the subject. That means that you could have an underlying formatter that very straightforwardly tries the best next break for the current line, sets it, and starts again with the following one, even if the result looks awful. In TeX, a different line break may be chosen if one letter is changed five lines further down.
As described above, DSSSL does not require the sophisticated paragraph formatting that TeX delivers. As a result, you may expect paragraphs which look rather ugly, on simple formatters based on word-processor code. On the other hand, TeX won't consider kerning as a possibility to format text in narrow columns, as in a newspaper, nor will it be able, for example, to consider (without manual intervention) sacrificing all of the space after a comma, if that would be the solution to a nasty problem.
Also, TeX simply takes a minimum bounding box around the contents of lines. Consider, however, the situation where a line has a large descender on one line (an integral sign in inlined mathematics), and a large ascender on the next (an exponent to an exponent). If these don't occur right above each other, the lines may not need to be spaced apart as they are in TeX, which takes a bounding box around each line and forgets what was inside them. Although DSSSL doesn't explicitly provide for a better-looking "skyline" formatting method, a formatter could use it if min-leading were implemented.
In general, the formatting quality depends on the formatter used with DSSSL, and may be better or worse than what you're used to with TeX.
Obviously, since DSSSL is an application of SGML, it will be most efficient in situations where a lot of text needs to be formatted in a way that best expresses the underlying structure. However, that does not preclude other uses, although these might become very troublesome if they have to coded as text by an operator. Consider an extreme case, the poetry of Paul Van Ostaeyen, where every single letter may be formatted differently from the next; this effect may be achieved by having individual rules for all of those letters, using query-construction-rule's. Also possible are id-construction-rule's, which apply to elements with a particular ID value. Maybe a vendor could come up with a useable GUI interface for this, although I doubt that this would make much sense.
Normally, you would get an SGML document together with a DSSSL specification for that class of documents, and you would feed both to your formatting engine, which would produce some output, and that's that.
If you are responsible for the design of a client's work, based on some informal guidelines (or none at all), then you would have to evaluate the DTD that is being used, and develop a DSSSL specification for it, using all the typographical skills at your disposal.
DSSSL in its raw form (computer code) may be fairly difficult for an operator to deal with, not just because an artistically talented person may not care very much about writing programs, but also because it is simply less efficient than the direct, on-screen layout manipulation we have come to expect from our DTP publishing tools.
We therefore look forward to the first publishing systems that combine this direct manipulation of a style specification with the content-driven formatting of a professional typesetting system.
DSSSL: Document Style Semantics and Specification Language
FOSI: Formatting Output Specification Instance