MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] Namespace
Even then, standards or specifications that reference each
other and can depend on earlier specifications anaphorically
can result in disasters. Complexity by reference hides
interpretive and literal bugs.
Let's consider the web:
1. HTML. It is an SGML application language. It grew
like kudzu and that spawned lots of products. Unfortunately
and deliberately, the systems that were implemented for it
aren't compliant SGML systems. HTML designers did not
require validation and SGML does and SGML also conflates
syntax parsing with structural validation. This coupled with a
poor choice of SGML features that when using an SGML system,
one can manage, but if one guts the system, well... read on.
2. Next comes XML. XML was to have learned from the HTML
and SGML experience. The problem here is that the designers
of XML tended to lean toward fixing SGML to accommodate the
poor choices they made in HTML. They dropped the requirement
for validation (made it optional) and kept the requirement for
syntax conformance (well-formedness constraint). They grandfathered
HTML wherever possible but gutted SGML wherever expedient.
3. Now comes the kicker. The HTML implementors created lots and
lots of objects that worked in accordance with the HTML standard.
A good/bad example is the Microsoft DHTMLEditControl. It can
be dropped on any form where one needs light HTML editing and
it was dropped on LOTS of them. Many were database systems
that needed fields with HTML in them. The kicker: it silently
drops tags such as <FONT size=2 > in there. Anyone spot the
problem? No quotes around the 2 in the attribute value pair.
If one takes these out and embeds them in an XML file
via a namespace, that Draconian parse rule comes into effect
and the entire file is non-well-formed. Ok, it's a database
so we should be able to wrap those in comments or CDATA sections
with just a little code. Right?
a) That's a bad practice. It leads to a fragile application
and corrupting data.
b) That won't save you from any stray quotations or combinations
such as --.
Now, depending on the database, you may have thousands and
thousands of fields to clean by hand or cleverness ; or, you
just don't do XML and now your data is stranded like a beached
whale.
One of the tougher tasks in writing standards or in writing
code is to track down and eliminate cyclic graphs. That
is why Dr. Goldfarb always admonished us to "Conserve Nouns!"
because the pronouns will screw us every time. Be wary of
80/20 solutions. To get it out the door faster, you might
be paying the price multiplied exponentially later. The
risk of not getting it done at all without shortcuts might
just be nature's way of saying you don't have a good plan
even if an ambitious one. While we must and always have
designed by version, we seek to future proof our designs
by encapsulation. If that isn't possible, we leave signs
that say "Thar Be Dragons Thar!"
len
From: Bob Wyman [mailto:bob@wyman.us]
There is always a tension between products and standards.
However, those who write standards best serve their constituencies by
writing their standards in the most unambiguous form possible. This
means that you must write every sentence with the precision that a
lawyer would and you must read every clause of your referenced
standards as though they were law. Only by following this method can
you hope to have consistent interpretations of standards.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]