OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Remembering the original XML vision

[ Lists Home | Date Index | Thread Index ]

Other than that without the old guard, 
you'd be doing C++ programming without 
a name to brand, in most of what you 
say I'd agree.  But let's not be too 
self-congratulatory.  XML was a bit 
of hacking on a mature tree to make 
planks.  The XML WG was a sawmill, 
not a forest.

1.  XML has to be able to work with non-web 
systems if SGML is to be sandbagged at the 
same time.  Some of these systems do not 
use MIME or even URLs.  There is life Off 
The Web.  The old guard saved markup from 
the likes of those who believed that only the
Web was important to the future of computing 
and markup.  That was heroic because it 
cost them dearly.

2.  The SGML Way was more of a problem than 
SGML.  This includes notions such as fully-easily 
readable tag names which document users appreciate 
but which are anathema to messaging systems where
size does matter (try an RF system).  The authors 
of some guideline documents based on thinking that 
only applies to document systems are doing the 
wrong thing.  Too much form over function and fit. 
Too much appeasement over engineering.

3.  What the vendors did was rush to the next 
new thing that had a chance of selling.  XML 
was captured by lemmings.  We traded some notions 
of flexibility for cheap tools and ubiquity.  

So far so good.

But be very wary of believing that is proof of 
good decisions because the day is long and many 
events will transpire before one retires.

XML may be overbuilt for any given application and
a bit under built for others, but experience old 
and new is proving that without this slightly 
contracted but still core SGML system (aka XML), 
we would need another markup system and we would 
probably set out again to subset SGML.

The SGML vision is inclusive.  That made it an 
ideal place to start.  The XML vision is narrowed 
and is increasingly narrowing.  That will be its 
death knell.  What isn't explicit in the markup 
will become explicit in the code.

Still, it didn't bother some of us to 
narrow SGML as needed before there was an XML, 
and it will not bother us to refocus XML for 
our own applications, broad or narrow, if that 
is what we have to do to get performance and 
maintainability.  We need neither permission 
nor sanction.  In the interests of the 
health of the information, most will attempt 
to do as the specification insists one must, 
and one will use the applications such as 
XML Schema as they are designed to be used.

Until they don't work.  Then screw them.  The 
XML WG/ERB taught all how to do this without 
apologies whereas in the SGML systems that predated 
XML, we were always defending sound technical 
judgment against tradition and view-specific 
guidance.  No more.

But we will stay on good terms with the horse.


-----Original Message-----
From: David Megginson [mailto:david@megginson.com]

It is true that there is some useless cruft in XML that was included
only for political reasons: public identifiers, notations and external
entities serve no function that MIME types (or URIs -- sorry, Simon)
and URLs couldn't serve, but we had to keep them in XML as part of an
unwritten ceasefire agreement with the SGML old guard (*), which was
still powerful at the time and could have seriously hindered
acceptance of XML both inside and outside the W3C; the other part of
that ceasefire was to pretend that XML and SGML would coexist, with
XML for lightweight Web and SGML for so-called "serious enterprise
applications" (the vendors put paid to that idea by abandoning SGML so
fast that we couldn't keep up with the press releases).


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS