RE: [emergency] Namespace

[Rex Brooks <rexb@starbourne.com>]

Hi Len,

I always like to hear from you. I don't have time today to say much, 
but thanks for keeping us on our toes.

Ciao,
Rex


At 11:49 AM -0600 3/31/04, Bullard, Claude L (Len) wrote:
>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.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request