Re: SGML's Virtues and Vulnerabilities (again)

Subject: Re: SGML's Virtues and Vulnerabilities (again)
From: Chet Ensign <Chet_Ensign%LDS -at- NOTES -dot- WORLDCOM -dot- COM>
Date: Tue, 13 Dec 1994 16:09:56 EDT

<-- The "SOAPBOX = ON" reference was meant to be humorous;
Chet--and perhaps others--perceived it otherwise. -->

This is true. I suppose I've been involved in too many discussions where it was

<-- and which Chet didn't request -->

Yes, this is true, too, and I stand chastened.

<-- point out the problems inherent in its 1970s technology which assumes that
documents can be reduced to ASCII text -->

This raises an interesting point. The original design of SGML wasn't based on
notion that all documents could be reduced to text -- ASCII, EBCDIC, etc. It
instead based on a bias to keep SGML documents people, as well as machine,
readable. Now, there has been pressure, movement, arguments, what-have-you
recently that this slant towards people should be jettisoned, and SGML
to be a binary format. I wouldn't want to see it go that way. There is still
value, I believe,
in having an underlying data structure that people can access without some
system or another acting as an intermediary. But gosh, don't I sound old

<-- let's look forward to the day when we can create them without resorting to
primitive technology -->

I think that this points to one of the key issues that has hampered broader
of SGML. The tools that people use to create SGML are still evolving. With a
exceptions, they are still operating on the word processing GUI model. Right
they appear to be little more than word processors with collar tabs in the
display and
they give no hint of the power that the SGML offers. Given that fact, and the
fact that
they don't even offer a pretty printout (hence, they actually *rob* the writer
of ease-
of-use) why should anybody adopt them?

<--and without doing violence to the totality of the document, which includes
physical appearance. -->

Interesting issue. I was thinking about that this morning. Most writers still
their job as producing an output -- paper, hypertext, Web doc, whatever.
This naturally makes the physical appearance of the output a key concern for

I'm interested in a future where we identify our job as producing rich
webs that can be accessed in a variety of ways. The appearance of any one
part of the information will be less of an issue of concern than its usefulness
in a variety of deliverable forms and manifestations. Long way off, perhaps,
but SGML is far more likely to get us there than our current crop of
proprietary tools.

I guess all-in-all, we are no so very far apart. I apologize to George for
taking his
soapbox too literally.

Best regards to all,


Previous by Author: Re: Style Guide Products
Next by Author: Re: Full text search in WinHelp?
Previous by Thread: SGML's Virtues and Vulnerabilities (again)
Next by Thread: l18N

What this post helpful? Share it with friends and colleagues:

Sponsored Ads