Last unstructured discussion: SGML compatibility

   I'm just going to say a few things, since this is the official last day
of open discussion (though how to keep this bunch in line is an open
question, I'd say). I got kind of burned out by RS/RE, though it continues
to am(us)(az)e me how whitespace and character sets dependably bring up the
highest heat in discussion. So I've just got to toss out a little bag of
thoughts before the end.

   Looking through the requirements the first time, I was really
disappointed at the talk of "biting the bullet" for SGML compatibility. One
of the things that I think we were able to see from the RS/RE discussion is
that the strictest level of SGML compatibility is impossible. Not only were
the solutions that made compatibility a primary goal unnattractive, but
there was still no agreement at the end as to what the standard even
_means_ on some crucial issues, like what the entity manager is constrained
to do. I had hoped that, seeing this, we would start to slip down the
slippery slope to a clean, sensible, vanilla syntax with the same or
greater expressive power. SGML is important because of extensible markup
and document grammars (things none of us would willingly give up). It is
also important becuase is is a standard, and that enforces a uniform
neutral platform for people to build systems on.

    But XML has a different standardization model to work with.
Compatibility with SGML via automated translations would not significantly
impair the big SGML players with big databases. Compiling to any kind of
XML rather than HTML, would be a snap -- and the process-to-publish bullet
has already been bitten. We could just cherry-coat the bullet and stick it
back in.

    However, for the 99% of the world that doesn't care a bit about SGML,
fixing quirks, syntactic oddities, and inflexibilities is a real boon. They
know HTML, so we must make things look like HTML. But when it comes to
adding the important things that HTML doesn't have, we should make tehm as
attractive as possible. So losing a restrictive, not-quite RE syntax
language would be a win, for instance. The SGML folks need a standard, as
well as capability so they will continue to need SGML. But for the rest of
the world, clean extendible markup is the biggest need, not SGML
compatibility. Not only that but the internet process encourages
independent innovation (ie. potentially incompatible new stuff). We need to
remember that the whole SGML world is a bump on a log. We may have more
documents (or not) but they have far more decision-making agents that need
to be swayed. And the decision-making agents are what counts, not how big
your database is. So we either adapt, or keep living in our cozy little
world, spitting HTML out of servers. If we manage to make XML a success
compatibility wiht SGML syntax will not be the core issue. How many of you
would rather deliver an HTML document than some XML document with a DTD,
even with a syntax that you hate?

    -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________
http://www.dynamicdiagrams.com/services_map_main.html

Received on Wednesday, 9 October 1996 00:11:39 UTC