SGML Books

Almost useless for the techie interested in the internal workings/practicalities of SGML

The full title of this book is *ABCD...SGML A User's Guide to Structured Information*; the author is described as "a writer and consultant in SGML and technical publishing", which is an understatement - Liora Alschuler is an authority on, and an articulate advocate for, SGML. I am impressed by her ability to discuss technical matters in plain language, something that should make the subject of SGML accessible to a wide audience.

The Standard Generalized Markup Language is an ISO standard (ISO 8879:1986) that "originally ... was just another way to set type". Since then it has had a tremendous impact on electronic publishing and served as a template for the ubiquitous HTML.

Who uses SGML? There is a formidable user-base that includes DoD (and the defence establishments of many countries), government instrumentalities world-wide, large corporations (including Intel, Butterworth, Ericsson, Standard & Poor's, and Columbia University Press), and even Microsoft (in Cinemania).

This book describes what SGML is, what it is capable of doing - in both print and electronic media - and discusses the question: Should I use SGML? The author's passion for SGML does not cloud her objectivity; she makes it quite clear that SGML is not an appropriate solution for every application, and her in-depth discussion of the issues should enable readers to make informed assessments.

An extensive chapter entitled, Who Uses It?, presents several detailed case studies and some brief "sketches" covering a wide range of applications. A reading of just this chapter, which does not demand any special technical knowledge, will give a clear picture of SGML's versatility and power. If one wants to persuade management to consider SGML, this is a most lucid and convincing argument.

A chapter, Who Needs It?, opens with the sentence, "The truth is, not everyone needs it". The author then discusses in remarkable detail cost-effectiveness issues; this is no superficial analysis, but sets out the questions that have to be answered in order to make a sound, economic decision.

However, to go back to the beginning. The book opens with a chapter, Understanding SGML and Where It Came From, in which the concept, origins, and its development are described. That flows on to the next chapter, which further elaborates on what SGML is and how it compares with other markup systems, DTP software, and Web publishing systems. There is a very good discussion of how SGML can be applied to database-structured data, an application used by Standard & Poor's. Also briefly discussed are ODA, OpenDoc, OLE, RTF, and PDF.

The author then goes on to discuss the tools, such as parsers and editors. An SGML document can be created using a text editor that produces an ASCII file with embedded markup, but there are now specialist tools that produce SGML files. The book contains a considerable amount of technical and other information about a wide range of SGML tools.

There is a common perception, quite erroneous, of SGML as a complex form of HTML. HTML, in the form familiar to Web users, is about short - very short - documents. SGML can be used for the same purpose, but its real use encompasses document analysis, information management, and team work. Web pages (the term, page, is by no means accidental) are usually the work of one person; SGML documents require input from many sources. Under a heading, "Who Does It?", the author lists:

publications manager, product manager, editor, editorial supervisor, managing editor, production manager, production staff, QA/QC, writer, typographer, layout and design staff, and programmer.

The reason for such an army is that SGML documents are forever, whereasWeb pages using HTML (or any other system, for that matter) are ephemeral. "Documents forever" does not mean the same as "diamonds are forever", which refers to the durability of a virtually indestructible object; it means documents that can sustain changes to content without the need to tinker with the SGML engine that eventually drives them. That is what this book is largely about.

The book addresses theoretical issues and practical considerations, even down to costing. It is all very well to be presented with a persuasive argument about the marvellous things of which some new system or technology is capable - but is it cost-effective? Both sides are fairly presented by the author. It is not an SGML how-to book, but an intelligent analysis of issues and a description of resources.

The case studies are illuminating and describe a number of diverse applications of SGML and, importantly, the considerations and experiences of those who chose the SGML path.

The book is an excellent resource and deserves a place in libraries if only for that. It is also a good read - at least, I found it so - that should capture the attention of anybody with an interest in publishing and document management.

Liora Alschuler is to be congratulated on a well-written, well-presented, and comprehensive book about SGML. The publishers have done an excellent job of design; the illustrations are of a high standard and provide a good supplement to the text, the references are a useful resource, the glossary is helpful, and the index comprehensive.

Reviewed by Major Keary

DISCLAIMER: The opinions expressed are my own. I have no interest, financial or otherwise, in the success or failure of this book, and - apart from a review copy - I have received no compensation from anyone who has. An extensive chapter entitled, Who Uses It?, presents several detailed

I don't mind the format except that it was written by the marketing departments, and not the people who actually do the work. As a technician I found it useless, insulting, and full of wishy-washy statements (no I can't give you examples because I threw the book away a long time ago). However, they are the kind of statements I'm constantly fighting over today (with our company's executives) like "seamless integration." What does that mean? To my company execs it means no more pain. No more money to be spent. We do XML right? Then why can't we import that document format today? What do you mean we can only handle certain XML standards - "the whole company thinks we do XML, and your telling me we don't!"

This book is part of the "do XML B2B and get rich quick" fiasco of 2000.

I like Charles Goldfarb, but he sold out to the wall street MBA types who have completely unrealistic expectations of what technology can and can not do.

The book contains, roughly, 100 pages of introduction to XML; 250 pages of tutorials on XML and its subcultures; and almost 600 pages of corporate presentations, of varying quality, on various aspects of XML application and implementation.

The introduction and tutorials, although good, didn't have the depth I was looking for.

The corporate bit addresses a very broad range of interesting issues, with varying levels of detail, but never enough to "solve the problem".

So for me, the signal-to-noise ratio was pretty low.

Let me give an example of a major gap in the book's coverage: I had hoped to gain much more insight into the relative merits of using attributes as against using element content; but I finished the book no wiser than when I started (other than having seen some examples where I disagreed with the approach taken).

The CD-ROMs didn't add much value, either: the web has moved on very rapidly.

To add to my disappointment, the production of the book is not of a high standard.

- The rendering of low-level headings leaves a lot to be desired (Ex: I looked at 33.2.2.6.4 on page 480 for fully 30 seconds before understanding that it was a heading). So does that of block quotes, which appear to run on to the following paragraph.

- Many footnotes on a left-hand page with callouts on the previous page make reading a chore (Ex: fn #2 on pp 59 and 60). There is a general disdain for any attempt to keep figures on the same left-right page pair as their references.

- It might have been less irritating, too, to use a single numbering space for all Figures, Examples, Tables, and Spec Excerpts, rather than obliging the reader to work out the sometimes subtle difference between "Example 8-1" and "Figure 8-1".

This book, I understand from the Preface, was itself prepared using XML. Unfortunately, good markup for publishing is of little use without excellent rendering. I got a strong impression of unseemly haste to get the book out before getting the rendering up to scratch. So readability was badly crippled (unlike The SGML Handbook).

One last damn. So far, I've read the book just once. Although I'm kind to books, the cover is already dog-eared and de-laminating. It probably doesn't matter, because, in contrast to "The SGML Handbook", reading this book a second time won't add anything. That's another reason I think it wrong to call it a Handbook.

More in sorrow than in anger, then: two stars for Dr. Goldfarb, zero for Prentice-Hall.

As Mr. Douglas states the examples are sparse and poor. I am used to SAMS books providing many concise examples, analogies and exercises that aid in your learning. Not everyone learns best by theory.

Since I have never experienced Mr. Morrison's work my disappointment lies with SAMS. They usually put out a better product. I will return this book tomorrow. There have got to be a number of books that handle this subject better.