Lists Home |
Date Index |
- From: "Rick Jelliffe" <firstname.lastname@example.org>
- To: "Simon St.Laurent" <SimonStL@classic.msn.com>, "Xml-Dev (E-mail)" <email@example.com>
- Date: Thu, 27 Nov 1997 01:18:57 +1100
> From: Simon St.Laurent <SimonStL@classic.msn.com>
> I gave a seminar
> two weeks ago in Washington DC to the ACM - a place and an organization that I
> would tend to think of as friendly to SGML. Of 50 people in the seminar
> (which was on Dynamic HTML), 15 had worked with SGML. Every time I brought up
> SGML (in connection with XML, CSS, and the DOM), I was greeted with questions
> about "is that really necessary?" "Are those SGML people trying to change
> _our_ world?" These questions didn't just come from the HTML beginners; many
> of them came from the developers who had worked with SGML, some quite
> extensively. At lunch the discussion quickly turned to XML, and I had to do a
> lot of convincing to get people 'past' SGML.
> For public relations reasons, it seems like XML needs to be able to have it
> both ways.
> As you may have
> detected, I do have a certain amount of hostility toward SGML and SGML
> culture, while remaining very enthusiastic about XML.
So you are a speaker with hostility to SGML, and your audience picks up on it.
Maybe that just means you are a sympathetic and hypnotic speaker :-)
However, I do think that a lot of the antagonism against SGML is actually
antagonism against the standard ISO 8879 (which is not intended to be remotely
entry-level or novice-friendly) mixed with antagonism against the early HTML
DTDs (which were overly-complicated, IMHO, in structure for their readerships,
as it turned out).
Plus the fact that SGML implementations often involve
converting peoples minds from presentation structure to logical structure,
which many people find is a big change in discipline and job description
(XML wont alter that!). Plus many SGML editing environments are not set up
to simulate element structures with different formatting, so an operator cannot
use simple visual cues of presentation to keep track of their progress.
I worked for a company (Allette) that gets most of its jobs from SGML projects
that had failed at other companies. When we looked at what made them fail,
it was very often because the DTD did not describe the structures required,
or because of invalid documents which reflect poor QC, and because not smart
enough programming systems were used. XML does not address any of these issues,
so I think that the kinds of projects Allette was troubleshooting (which are
presumably ones that will feed out disgruntled programmers to ACM meetings)
would not have been helped.
Which is in no way to deny that SGML the technology does not have some dross,
and that its wording can be improved.
> This is an improvement, and the SGML community deserves great credit for the
> effort they have poured into building a simple but useful toolkit, which
> avoided the byzantine complexity SGML proposals are known for.
> XML is more
> than just SGML, however. XML is going to bring a lot of 'bozos' into the
> field of markup, people who care neither about the history nor the theory and
> just want to get things done. A different attitude and different needs will
> very likely increase the demands for XML to find its own voice.
Yes. And all the questions "are declarations good", "should we remove constants
to headers, or allow inline declarations?", "why isnt everything an element,
wouldnt that be simpler?", and "why cant we leave out these strings, since they
are not needed for parsing?" and so on.
The trouble with slagging off at SGML is that because there is no
difference in technology between XML and WebSGML, it all ends
up in personal attacks on people who have been able to use SGML, or
on the people who invented it, or even just us innocent bystanders who
happen to go to committee meetings. I have seen this happen many times
before. (I am not saying you are doing this Simon, merely that I have
seen it many times. In anycase, you are writing a book and your antagonism
will teach a new generation of XML people, who may therefore feel
less likely to buy my book :-)
Please say "XML is simpler than SGML '86" and "XML is better for small
systems than SGML '86" and "SGML has many things that are not needed"
but not "SGML people are trying to make everything complicated and make
XML as bad, complex, over-engineered and stinky as SGML". This demonizing
of "SGML people" is a bad way to win people over to XML.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)