🚀 go-pugleaf

This message runs long.  Consider yourself (yourselves?) warned.


In article <114143@sun.Eng.Sun.COM> tut%cairo@Sun.COM (Bill "Bill" Tuthill) writes:
>The important thing to remember is, SGML isn't.
>
>SGML != standard generalized markup language
>
>It isn't standard, as there are several tag sets, such as APA
>and CALS.  CALS is even a superset of SGML.
>
>It isn't generalized, because it doesn't handle graphics, tables,
>or equations.  CALS does, which is why it's a superset of SGML.
>
>It isn't for page markup, but rather, for describing documents
>hierarchically.  Kinda like TeX or troff macros!
>
>It isn't a language, but a syntax for describing a language,
>like Backus-Naur Form.

Well... SGML is a standard -- it's ISO 8879-1986, as Bruce Cohen pointed
 out in message <3790@orca.WV.TEK.COM>.  And it's not a particular markup
 language, as you point out, but rather a language that can be used to
 define an entire family of markup languages.  As such, it could be used
 for many purposes -- although those that are being tried first are in
 the model of SGML's progenitor, IBM's GML, which was a set of IBM Script
 macros used to describe documents hierarchically.

SGML *can* be used to write languages describing anything.  For instance:
 in a previous job, for a company that no longer exists, I saw an SGML-
 based markup language that included markup for graphics, tables and
 equations.  And there's currently an ISO committee working on something
 called the SPDL -- Standard Page Description Language -- which will be
 an application of SGML to page markup.  (Don't ask me why the world
 needs another page markup language -- that one I don't understand.  But
 if such a thing is necessary, there's no reason it can't be based on SGML.)
 That sounds pretty general to me.

So I think SGML's name describes it pretty well.  And while a name like
 "Standard language for describing generalized markup languages" might
 alleviate some confusion, SLFDGML woould be pretty disastrous as an
 acronym.

>The Holy Grail that everybody's looking for is the ability to
>readily interchange documents.  So far SGML doesn't help much
>in that regard, because common document formatting systems--
>TeX, troff, Frame, Interleaf, MSword, WordPerfect, etc.-- don't
>read or write SGML.  And that's the bottom line.

But you're right about interchange being the Grail, and about SGML not
 being that Grail, not yet at least.  But SGML is a step toward the Grail.
 It allows markup languages to be specified in a vendor-independent manner,
 and that's already a big step forward.  And SGML's companion standard,
 DSSSL (the Document Style and Semantics Specification Language), will
 allow (as you'd expect from the name) style and semantic information to
 be associated with the hierarchically nested tags characteristic of SGML-
 based languages; the combination of an SGML DTD (Document Type Definition,
 really a markup language specification) and its associated output spec
 written in DSSSL should truly allow documents to be interchanged among
 disparate processing systems with matching results.

In the meantime, the world is walking toward SGML usage... slowly.  One
 step is to begin to be able to read, process and output documents marked
 up with particular (non-vendor originated) SGML-based markup languages.
 CALS includes both a "conforming" DTD and a template to be used in building
 similar DTDs, and some vendors (like Interleaf) are shipping systems that
 can read, process and output CALS documents.  (Actually, CALS itself is an
 attempt to leapfrog or accelerate the race to the Grail by setting up a
 total interchange standard, of which the use of SGML-based languages for
 text markup is a part.)

But as for systems that are fully SGML-capable today -- yeah, there aren't
 any, and it's pretty clear why.  It's no trivial matter to create a text
 processing system to begin with, and most text processing systems accor-
 dingly embody some kind of assumption about the amount and kind of struc-
 ture that authors want to associate with their documents.  For many such
 sets of assumptions, it's fairly easy to map those assumptions onto a
 markup language that could be described in SGML.  That's what my old com-
 pany did, and what others have done as well.  But markup languages can
 be written to embody just about any set of assumptions, and automatically
 translating between such sets is no easy matter.

So (and this is now in reference to Bruce Cohen's pointer to Frame's ML
 and Del Armstrong's (message <2304@valhalla.ee.rochester.edu>) pointer
 to Arbortext Publisher) current systems that "output SGML" actually pro-
 duce output in a particular SGML-compatible markup language.  A fully SGML
 capable system would produce output in *any* SGML markup language -- you'd
 just tell it which DTD to use, and it'd produce your output.

Disclaimers: first, I work for Interleaf, so I have a bias and I haven't
 seen the competing products in detail.  (I *do* follow the SGML world,
 however, and I'm pretty sure that if there's a fully SGML-capable system
 around, its manufacturers are keeping *very* quiet.)  Second, my liveli-
 hood *does* depend on SGML, at least to some extent, so I am bound to take
 a more positive view of it than someone who, say, wants document inter-
 change *today* and is disappointed that SGML doesn't by itself suffice.
 I believe that SGML is compatible with, and could be a step on what I hope
 is an inevitable path towards, a future in which authors and readers are
 free from the tyranny of proprietary formats.

Ed Blachman	edb@ileaf.com	(or)	...!mit-eddie!ileaf!edb

If I am not for myself, who will be for me?
If I am only for myself, what am I?
And if not now, when?