Re: SGML's Virtues and Vulnerabilities (again)

[Chet Ensign <Chet_Ensign%LDS -at- NOTES -dot- WORLDCOM -dot- COM>]

<-- 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
not.

<-- 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
the
notion that all documents could be reduced to text -- ASCII, EBCDIC, etc. It
was
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
redesigned
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
software
system or another acting as an intermediary. But gosh, don't I sound old
fashioned.

<-- 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
adoption
of SGML. The tools that people use to create SGML are still evolving. With a
few
exceptions, they are still operating on the word processing GUI model. Right
now,
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
its
physical appearance. -->

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

I'm interested in a future where we identify our job as producing rich
information
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,

/chet