Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!oliveb!sun!cairo!tut From: tut%cairo@Sun.COM (Bill "Bill" Tuthill) Newsgroups: comp.text Subject: SGML Message-ID: <61024@sun.uucp> Date: 22 Jul 88 18:59:06 GMT Sender: news@sun.uucp Lines: 98 I'm moving a discussion of SGML started in comp.text.desktop into this newsgroup, because I think the issues are larger than a desktop. I feel SGML would be helpful if it were a de facto (rather than merely a de jure) standard. However, since most document publishing systems cannot at present exchange SGML text with each other, SGML is pointless, kind of like Esperanto. Furthermore, even if SGML were more widespread, incompatible tag sets would still pose interchange problems. Here is an excerpt from a memo I wrote a while back. Goldfarb (an IBM employee) is the principal perpetrator of SGML. References are to an article he published in "SIGPLAN Notices," June 1981. ----- SGML is a solution to a non-problem. Goldfarb believes that descriptive markup languages (such as SGML) are superior to procedural ones (such as IBM SCRIPT). Even though this may be true, it is a specious comparison because SCRIPT really stinks. Instead, SGML should be compared to decent procedural languages such as troff and TeX. There are good reasons why troff and TeX macro packages were invented: well-designed macros provide writers with a descriptive layer over a procedural language. When the descriptive layer isn't powerful enough, troff and TeX already have escape hatches so writers can achieve special effects. SGML apparently provides no escape hatches. SGML is no panacea for portability. Being a metalanguage, SGML does not provide one syntax, but only a method for describing different syntaxes. On p. 68 Goldfarb states, "SGML allows variant concrete syntaxes." This is tantamount to saying it isn't really standard. It would probably be as difficult to translate between variant syntaxes as to translate between troff and Interleaf or Frame. SGML was born obsolete. Graphics are missing from the specification, as are provisions for tables and equations. On p. 100 Goldfarb talks about WYSIWYG, but what he apparently means is typewriter input: something like -ms's .DS/.DE macros. Furthermore, every SGML document I've ever seen is extremely ugly. It doesn't say much for a documentation standard when it can't even produce handsome documents. SGML represents no great advance. I was a consultant at UC Berkeley when IBM SCRIPT/GML arrived, and most users said "so what? We already have troff." The specially-hired SCRIPT/GML consultant had no clients-- none. There was no evidence that SGML was superior to other batch systems. A few comparisons in Goldfarb's article make SGML seem inferior: ----- SGML -----

Text processing and word processing systems typically require additional information to be interspersed among the natural text of the document being processed. This added information, called markup, serves two purposes:

  1. Separating the logical elements of the document; and
  2. Specifying the processing functions to be performed on those elements.
This figure represents divine document intervention.

Three Angles Dancing ----- troff ----- .LP Text processing and word processing systems typically require additional information to be interspersed among the natural text of the document being processed. This added information, called \*Qmarkup\*U, serves two purposes: .NP Separating the logical elements of the document; and .NP Specifying the processing functions to be performed on those elements. .LP This figure represents divine document intervention. .FN "Three Angels Dancing" .CP angelfig 24P SGML's jargon shows intellectual bankrupcty. As far as I can tell, the term "generic identifier" means tag, and the term "entity reference" means file. Why does Goldfarb have to resort to obfuscatory terminology, if not to hide intellectual deficiencies in the design? SGML embraces pointless data structures. Documents seem to be stored (or conceptualized) in a hierarchical tree, right down to individual words and letters. There is no compelling reason why words and letters cannot be strings and characters. In the concrete syntax described, the ASCII characters < > & % ; appear to be reserved symbols, but Goldfarb offers no method for printing these characters literally. In troff at least only the \ is reserved. Note that < > & % are heavily used in UNIX documentation. SGML requires a guru. SGML documents are supposed to be rigorous, but rigorous means inflexible. If writers want to change the least thing, they will have to consult an SGML guru. It seems that SGML gurus will have to be just as knowledgeable as a TeX or troff macro guru, or a Scribe database administrator.