[
Lists Home |
Date Index |
Thread Index
]
From: "Dave Pawson" <dpawson@nildram.co.uk>
> The design goals for XML are
...
> * XML shall be compatible with SGML.
> Is No. 3 out of date?
Ah, but it is a design goal of SGML to be compatible with XML :-)
It is an industrial standard, not a scriptural text.
Standards go through a cycle with a short phase of responding to the
world followed by a long conservative phase of trying to get the world
to respond to the standard.
SGML standardized a highly fragmented world (hence having to cope
with so many different kinds of markup), then bunkered down so that
the technological base was stable.
XML standardized a converged world, now is bunkered down.
It is dialectical: the contradictions grow to the point where they
are intolerable (and where the best way out it more or less obvious)
and then we get a new standard devised. By the time the
new standard is devised, technology has also changed enough that
rather than merely "correcting" the original, we can expect the new
to also address some different issues, bring in a new constituency. They
will then work as if the original rationale were obsolete, thus creating
a whole new set of contradictory impulses where the old generation
adopters become the rebels. Len might think this is the wheel of life.
In that sense, it is only to be expected that sooner or later a technology
will go through a cycle where it does not meet one's particular needs,
if one hangs around long enough. Technology is organic. If Son of XML
is useless for documents, we dare hope that Grandaughter of XML
might be wonderful. Swings and roundabouts.
The compatability with SGML should be a "deep" compatability:
standardized (public, static, reviewed documents, made by some process
with reviews by independent parties), generalized (separation of content
from processing, information items can be subclassed/augmented/parameterized
by various mechanisms such as attributes and types), markup (using text, with
the central paradigm of pre-existing text being annotated, and a range of kinds
of tags to suit the various participants: humans {comments}, specific processors
{PIs} and everything in between {elements}), language (readable though
not necessarily immediately comprehensible by humans, rigorously described to
the extent that a parser can indeed be written, looking to linguistics for insight
into how humans utter information).
More than that, I think the central "deep" compatability with SGML
that future XMLs should have is to view SGML as a mid 80s attempt to
embody/force software-engineering best-practices: it was a way to promote
validation, contract-based interchange, components, manifest
interfaces, named constants, configurability, portability (rather than
interoperability) and so on.
So removing "compatability with SGML" is not so important at
a superficial level (because a revised XML would get that grandfathered
through compatability with XML 1), but only if it is replaced by
a goal that brings in the same focus on software engineering virtues
which served SGML so well (without denying that sofware engineering
concerns have moved on.)
What are the virtues for 2003? I would say robustness, reliability, redundancy
(enough alternate forms to be gluable), readability, rigour, composability,
compatability, compressability, scalability, parseability, introspectability,
characterisability, usability, testability, usefulness, simplicity-promoting
(in the sense of making the complete system simpler, not meaning it needs be
simple itself, per se) and fool-proofing. (Should I18n fit under usefulness or
foolproofing?)
Maybe even extensibility :-)
In other words, to ask "How robust is XML? Is that enough? How can we
make it more robust?" and so on for each of those virtues. In the absense
of any kind of more thorough review like this (which I would suggest should
have a 1 year deadline), we will just have a succession of XML 1.1-style
bandaid fixes; we will get fragmentation merely by a lack of leadership.
For example, the current idea at W3C that the issues of alternative
ways to do entity referneces (xml:include) and to declare IDs (xml:id
or whatever) can be dealt with independently from the issue of
XML parser conformance levels/subsetting: how can that not just lead
to our collective asses being more halved?
But maybe fragmentation is good at this stage in the cycle: a bigger
gene pool. I wonder how long the cycle is? At least three product
cycles: so 8-15 years is my guess.
Cheers
Rick Jelliffe
|
