Re: [emergency] Namespace

[R. Allen Wyke <emergency-tc@earthlink.net>]

I think I just shed a tear. Oh happy days are here again :)

Sorry for the moment of joy, but I have sought for months to try and 
say/describe/convey/whatever what these last two emails have done. 
Notice that there is no real discussion of CAP (ie: not talking 
elements here), but rather the process of creating something that can 
stand on its own two legs (ie: doesn't need a lot of outside help to 
understand how to properly implement) and has some degree of foresight 
of what happens when you do not do such.

On Mar 31, 2004, at 12:49 PM, 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.
--
R. Allen Wyke
Chair, OASIS Emergency Management TC
emergency-tc@earthlink.net