[
Lists Home |
Date Index |
Thread Index
]
Yes, and in their day and on the system for which they
are re-architected, they thrive and dominate. That's
directed evolution in action.
Yet hindsight has to be as accurate as we can make it,
or we make the wrong decisions. Again, there are conceptual
and systemic issues for the technical decisions. SGML is
big by comparison to XML. The re-architecting to make
SGML work on the web was based on decisions that are themselves
being reviewed. XML fixes an SGML Declaration in code. Wise?
For a very large percentage of XML developers, yes. For some,
no. Now the question becomes does XML get larger to meet the
needs of those who have a use for the declaration, or do we
say, "no, that's SGML and you should use the right tool".
Then the responsibility to upgrade SGML in response to that
user's needs is clear and XML stays targeted.
But if we go down a path of "SGML doesn't matter; SGML is
document-centric and we all KNOW that data centric is the
way", then XML becomes bastardized. SGML like any other
standard targeted to too broad a set of surface
similar applications becomes too big. Do that to XML and
we miss the value of the lessons of history, but how
to stay simple and stay pertinent is hard. We could restrict
the content scope (somewhat like saying the WWW should be
English-only) and get a simplification. Anyone really
want that? Some did but it's stupid on the face of it.
It murders the reason for having the web to begin with:
to create, preserve, and disseminate knowledge.
So where we simplify matters. To make that decision,
we need a clean history and it must include both conceptual
and systemic information. It's no good to say "SGML
doesn't matter" if we don't put that in a systemic
context. XML's design would not have mattered in
1986. It would have been understood as too loose.
Validation mattered then. Character set descriptions
at the document locale mattered. Memory storage size
mattered. Depth of recursion mattered. EBCDIC mattered.
Hypertext didn't matter. The Internet didn't matter.
Five years later, when hypertext became something more
than a lab curiosity and desktops became more than
toys, it was time to rethink that. Five years after
that with some experience with a very large distributed
hypertext, the lessons were clear. At that point,
many of the SGML Way decisions clearly did not apply
any longer for THAT SYSTEM in the majority of uses.
Now almost five years after that, some more rethinking
is happening. As a result of that, we may see more
SGML-like features reemerging. Should they be in
XML or should SGML be reworked with a seamless path
between the two factored in as has been done to date?
In hindsight, what are the lessons, what are the
requirements, and what are the ways forward? The
human dimension of this is that we have to be extremely
cognizant, and I for one do not trust those decisions
to be made by any person or group who thinks that revisionism
of history is needed to sell their case. If we go
down that path, we simply repeat mistakes. Clarity matters.
len
From: Jonathan Robie [mailto:jonathan.robie@softwareag.com]
At 01:06 PM 3/18/2002 -0600, Bullard, Claude L (Len) wrote:
>Except in hindsight. Everyone is an expert at that.
>XML was designed "in hindsight".
>
>Hindsight matters.
There's a lot of truth to that.
Everyone knows about Occam's Razor, and most designers say simplicity,
conceptual integrity, etc. are important to them. Still, most of our
initial designs are more complex than we would like. If we're lucky, our
colleagues point out potential simplifications. More likely, they point out
all the important cases that our initial solution did not cover. A good
designer then goes back to the drawing board, looking for a solution
general enough to cover these cases without a bunch of special casing,
using hindsight as a tool for knowing what to throw out (grin!).
One set of technologies that matter are the break-through technologies that
show how something new can be done. These generally have warts, but they
show the way. Ten years later, we may want to use something else. Another
set of technologies that matter are less brilliant, simple reworkings of
the original ideas. XML was not creative or original. Neither was Java,
really. Both are excellent examples of hindsight in action.
|
