At 03:34 AM 3/21/00 -0500, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
If you haven't been in the industry long enough that it takes you more
than 30 seconds to think of at least 5 vendors(*) of software who aren't
dissuaded from doing something just because the standard says explicitly
not to do that, you haven't been around enough to see *seriously* broken
software.
I share your concerns with vendors who stray from standards, and spend far
too much of my time testing implementation conformance.
However, this paranoia about vendors doesn't mean that we shouldn't create
new standards or add new features to existing approaches. It means that we
should be as clear as possible about what is specified, and make certain
that those new features will fit well within the context of those existing
approaches.
Vendors will stray, but at least we'll have something unambiguous to
compare them against.
So far as I can tell, this suffix is actually less prone to 'standards
drift' and has a greater chance of being adopted in the form in which it is
proposed than any of the parameter-based options presented as alternatives.
The existence of '*seriously* broken software' doesn't seem like an
argument against this particular innovation.
Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com