In <747072625(_dot_)433593(_dot_)KLENSIN(_at_)INFOODS(_dot_)UNU(_dot_)EDU>, you
wrote:
I think one could draw some slightly different lessons from this. Maybe
the differences might tell us something.
Proposed alternate main principle: Any time one designs something that
can be extended, it is necessary to be extremely clear about what an
"old" processor should do when it encounters an unrecognized extension.
Absolutely. I passed along the note from RISKS more or less
without comment (I would have drawn slightly different
conclusions, also), but John presents a vitally important
fundamental principle (which I have been known to advocate,
myself). Far too few specifications devote any thought to
evolution and extension mechanisms, perhaps assuming that
implementors of version 1 prototypes will all "do the right
thing." Experience shows, however, that they rarely do.
If that action is "discard", then one has to be hyper-careful about
what extensions are permitted. In some cases, clever design would
make lexical distinctions between (SGML-speak) "safe to discard tag",
"safe to discard element", and "not save to ignore" extensions that
would permit old processors to behave with relative intelligence.
In fact, we had discussions of this sort of issue, with respect
to richtext/enrichedtext, a few months back.
Sometimes it's entirely appropriate to disregard unrecognized
information, but in the case of a markup language it's pretty
obvious that it is not appropriate (especially when the
information is user text which is merely surrounded by an
unrecognized delimiter).
Personally, I am much more interested in the design and
specification issues (i.e. "don't discard unrecognized text,"
or John's deeper "plan a specification for growth, and define
up-front the behavior to be taken by initial implementations in
the face of eventual newer data"), and I would tend to place the
"blame" in the WWW/hypertext anecdote on the misbehavior of the
implementation which silently discarded the italicized text.
But, in the larger picture (which is what the RISKS list often
gives you good glimpses of), it may not matter whether it was a
specification problem or an implementation problem, or whether it
was an uninteresting example of an old problem we'd all seen
before: if the system fails, the system gets the blame.
Steve Summit
scs(_at_)eskimo(_dot_)com