[
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.
len
-----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).
|
