RE: [emergency] Namespace

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

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.