[
Lists Home |
Date Index |
Thread Index
]
That's right. It wasn't a replacement for HTML.
HTML is an application language. So, without
XML, you would still have HTML, not XHTML, and
so on.
Had the argument not to simplify carried the
day, HTML would be all that the W3C would have.
Since we're speculating anyway...
The SGML simplification would have carried on
in ISO where the impetus for it was already
well underway for reasons not only based on
web requirements, but because the problems
of profiling SGML systems for conformance were
already obvious (the Unicorn debates). SGML
had considerable growth rings by 1995. One
can call it baggage, but that ill-chosen term
overlooks the requirements that were vital
when it was designed even if overcome later
by hardware, convergences in architectures,
encodings, and so on. The web was just the
latest-breaking-looked-lucrative-but-wasn't
set of requirements.
So the profiling would have been done, would
still be just an SGML profile, would not be the
property of a private consortium, and perhaps,
not as hyped. One of the reasons given to me
for moving to the W3C was to sell it. The best I can
say for that decision is that the W3C was more
practiced as doing this online with a WG that
commented. That brought more talent to the
work even though the SIG still called the shots.
In the end, ISO cooperated by making the ammendments
to ISO 8879 that made it all kosher.
The XML subset or simplification arguments revolve
around ditching DTDs. As much support as has been
brewed for that starting back when the original
SIG/WG was in motion, it will be problematic
because it will be followed quickly or in parallel
for replacing the functionality lost, eg, using
the xml: namespace for things like IDs. A subset
that does something for everyone but fails to
meet the niche requirements of critical groups
will be just as widely criticized. How many
profiles do you think you can live with before
it is just "heck, make sure the parser supports
it all and use profile flags". I get a bit weary
of seeing the nose in the camel's tent without
acknowledging just how far the camel can spit.
Anyway, all spilt milk. I just haven't seen a
convincing argument for creating a subset that
couldn't be met by different means. Rick Jeliffe
and Henry Thompson have offered alternatives that
should be evaluated seriously before a mad dash
to create yet another potentially disruptive
subset of SGML.
len
From: Seairth Jacobs [mailto:seairth@seairth.com]
I must have learned my history wrong. My understanding was that XML came
about as a simplified version of SGML to work for the web. It was no more a
replacement for HTML than a brush and canvas is a replacement for a
painting. People saw the value of bringing SGML to the web, but obviously
felt there was a lot of baggage that needed to be left behind. To my eyes,
this is no different an argument than people are now making for XML.
|
