Lists Home |
Date Index |
With the free parsing technology,
SGML isn't that expensive. Without free viewers, it is.
So is XML.
The major problem with SGML over XML is that with its
flexibility comes a greater reliance on coordination
among parties and that does raise costs while lowering
overall reliability. For point to point systems in
the era when SGML was designed (pre-public Internet),
this was reasonable. But XML itself is a core system
technology that other technologies are built over. One
layer of interoperability is available, but above that,
the same problems reemerge as well as the costs. A
barebones HTML browser satisfies no one today. An
XML-enabled web-based operating system is what is wanted.
Had everyone understood that the Internet browsing
and server technology markets would minimize the number
of realistic business options, SGML could have worked but
still would have required some adjustments. Well-formedness
has the ugly cousin, self-description, and that is limited.
We did get a better technology, but not dramatically lower costs.
XML preserved the right to party, but not necessarily,
a 'no door charge' policy. As we see more vendors withdrawing
from the 'freely distributable multi-platform systems',
we are finally seeing the costs of web development emerge
as well as the inevitable pattern of the emergence of
local controls and the attendant costs of controlling their
interoperation as well.
From: Eckenberger Axel [mailto:Extern.Eckenberger@kmweg.de]
> For all the quirks and seemingly-bizarre whitespace rules
> in SGML, it's one of the few markup technologies where
> whitespace handling tends to Just Work (as long as you follow
> best practices like "avoid pernicious mixed content").
True SGML is flexible, extensive and strict, but this also makes it