Re: RS/RE: basic questions
At 12:35 PM 10/2/96, W. Eliot Kimber wrote:
>At 01:44 PM 10/2/96 -0400, David G. Durand" (David G. Durand wrote:
>>My argument against quoting is that SGML compatibility should not be _more_
>>important than user utility (and familiarity is a significant component of
>>utility for most busy people who aren't toolsmiths).
>David has, I think, crisply defined the key to this issue. Either XML is
>completely compatible with SGML or it isn't. A review of the ERB's stated
>principles shows that SGML compatibility gets higher priority over ease of
Well, in that case the principles are wrong.
If we make the solution upalatable to the majority of internet users, we
have not advanced from the past. I am not arguing that hand entry is
important because it saves typing -- If that were the reason, I would agree
But Bill Smith's and others' comments about acceptance cut more deeply
than technical quirks of 8879. XML is the SGML community's last chance
create something good and _popular_ that implements the basic abstractions
of content markup. We know a lot about the semantic task of describing text
structures. We also know that the mainframe-era syntax of SGML has hobbled
it badly in achieving wide acceptance, despite clear and obvious technical,
philosophical and business advantages. Why preserve those liabilities when
making a pitch to a more naive, short-term-oriented, community. There are a
lot of "PERL-based lifeforms" out there, to use Erik Naggum's resonant
phrase. We don't need to pander to them, but we offend them at our own
We would be better off using my entity manager tricks and requiring
declarations for element content if you want to use non-significant
If we have to quote, then let's use shortref, NET and the like to make a
syntax like LISP -- if we're going to be unfamiliar, we might as well use
the simplest possible syntax.
>I certainly agree that quoting data will make authoring *by hand* more
>difficult (I hated it the first time I tried it), and we do have to be
>sensitive to the marketing implications of requiring it, but I feel very
>strongly that the cost of not having SGML compatibility in this case is
>much greater than the cost of authoring.
If XML tools are cheap and easy to write, preserving our investment in SGML
editors etc. should be a minor factor -- we can just write conversion
scripts. Just why is compatibility at this level so important?
If we need to preserve the minutiae of whitespace handling in XML then we
are doing a strict subset of SGML without any possibility of relaxing the
requirement. If we add onto that the use of a huge pile of arcane SGML
features so that the resulting syntax does not even capitalize on the
acceptance that SGML already has (through HTML) we are dooming ourselves to
a tiny nich within our same old insular community.
The internet is different and we must adapt or die. HTML paragraphs with
explicit style attachment let me do (slightly crippled) generic markup on
top of HTML. That kind of alternative will drown us unless we can leverage
the stuff that's already out there.
RE delenda est.
David Durand email@example.com \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________