Lists Home |
Date Index |
3/8/2002 3:44:02 AM, "Rob Lugt" <email@example.com> wrote:
>Remember, one feature that made XML attractive and that set it above
>proprietary formats was the proposition that XML 1.0 documents would be
>readable for many years to come.
Well, they will be readable by XML 1.0 parsers, not to mention
ISO 11879 parsers. If there is no market for such things in many
years, that is not something under the control of the XML community.
*IF* XML 2.0 or 3.0 or whatever makes changes that break backward
compatibility, the obvious solution for people who really need DTD
features is to use SGML. Ability to read "legacy" documents is
very much a part of its core mission and values.
IMHO, XML needs to think more about going forward than looking back. SOAP,
for better or worse, has oriented itself on a profile of XML that
doesn't included entities (or anything else you need a DTD for).
In many other ways, "the market" seems to be voting against the
traditional SGML way of building compound documents [zipping up flameproof
suit ...]. I think we've all seen enough "standards" with insufficient
support in the market to realize their promises to know that the
W3C, nor anyone else, can guarantee long-term interoperability.
Also, to the best of my knowledge, relatively little of the
massive amounts of XML that are being produced today would "break" if
entities were deprecated; most of what would break is being produced by
systems that still support SGML (XMetaL and Epic come to mind).
I'm reminded of the rather significant and painful "refactoring" that
Java went through between version 1.0 and 1.1. (or was it 1.1 and 1.2?)
At the time, there were lots of complaints that Sun had violated trust
by breaking working code, a deadly sin from a standards perspective.
But in retrospect, causing early adopters pain in the short term in order
to increase the long-term viability of the platform was almost certainly
the right decision.
I'll point to everyone's current favorite marketing book, THE
INNOVATOR'S DILEMMA again -- "Disruptive" innovations come from outside
because companies invested in the current paradigm won't inconvenience
their customers (or their bottom line) for their long-term benefit.
XML will either refactor itself to reflect the lessons we learn about
the real value of specific components and features, or somebody out there
will do it for us.