[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: SML: Second Try

• To: 'Seairth Jacobs' <seairth@s...>, xml-dev <xml-dev@l...>
• Subject: RE: SML: Second Try
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Thu, 6 Feb 2003 13:22:16 -0600

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@s...]

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.

• Prev by Date: RE: SGML->XML->? (was Re: SML: Second Try)
• Next by Date: RE: SGML->XML->? (was Re: SML: Second Try)
• Previous by thread: Re: SML: Second Try
• Next by thread: RE: SML: Second Try
• Index(es):
  • Date
  • Thread