I would tend to disagree. I have talked to a number of people who are
antagonistic against SGML because the standard is so complicated. The fact
that it takes a book that large to really give an implementor enough
information to build a parser says something. As does the fact that SP is
roughtly 1Mb compiled. There are reasons for all of this, but people tend
to avoid things which take too long to understand, and react adversely when
they are forced to use something which they don't understand. Part of the
problem falls back to the tools, but if the initial standard had been more
directed to a specific audience, then the tools would have been easier.
Generality has its pros and cons. SGML was so general that it was
extremely complicated and only the determined could wade through the
initial waves of confusion. Thus there were very few people who
'understood' this SGML thing, so organizations trying to use SGML had to
get by with people who "didn't get SGML," and as a result had a horrid time
at it. Thus there are a number of people who think SGML is "a bad thing"
because 3/4 projects using it crashed and burned... (the preceeding figure
is purely random. I personnaly have watched a number of projects fail, but
I claim no knowledge of a general success/failure rate....)
This is not to say SGML is a bad thing. SGML is based on some extreemly
sound ideas, which are real driving requirements in a number of industries.
(otherwise SGML would have been dead a long time ago) XML (hopefully) is
the necessary compromises to get SGML used in more of the cases where it
can really provide benefit.
-derek
Derek E. Denny-Brown II || ddb@criinc.com
"Reality is that which, || Seattle, WA USA
when you stop believing in it, || WWW/SGML/HyTime/XML
doesn't go away." -- P. K. Dick || Java/Perl/Scheme/C/C++