Re: ??? (was RE: A simple guy with a simple problem)

[Kimbro Staken <kstaken@dbxmlgroup.com>]

"Bullard, Claude L (Len)" wrote:
> 
> No.  Simple is good.  Too simple for
> safety is bad.  Knowing which is which
> is the trick.
> 
> DTDs?  Schemas?  How do you know when
> what is simple for you is too simple
> for the next guy?   How do you know
> that what Henry proposes isn't precisely
> what is needed for that guy to get
> his job done?  We can't treat XML
> spec work as an XP programming
> exercise.  There isn't enough
> room in front of the screen for
> everyone involved to sit down and
> write the unit tests.

Perhaps this is exactly what is needed in XML spec work. Within a single
company you can have applications of a significant level of complexity.
However, as soon as you get to the edge of that company and look toward
a global exchange of data the only thing you will find are protocols
that succeed because they are simple and work "good enough". A company
might use Microsoft Exchange for their internal email with all its nice
bells and whistles but as soon as that email needs to leave the company,
bang you're back to SMTP. 

HTTP, SMTP, NNTP, FTP, HTML, POP, DNS all heavily deployed, widely
interoperable and to most technical people pretty simple. They're also
all heavily, heavily flawed in one way or another. So what I say, they
also work very well for a very large set of problems. The development
model for all of them while definitely not "true" XP was certainly far
closer to XP then to any top down methodology. All the developers of
these things cared about was getting something that works for what they
needed at the time and then incrementally improving it from there.
Minimal victory just like XP. Funny how they are still the
specifications that the Internet is based on. 

What happens to the more comprehensive, technically elegant solutions?
In case after case after case they generate big, unwieldy specs that
their inventors think are beautiful but the people who really make
things work simply ignore. These people are simply too busy building
real applications to take the weeks or months required to understand
these monstrosities. The only place these kind of specs can succeed is
in  specific industries where all the players are large enough to foot
the bill. Once you approach the global developer population it simply
will not fly.

XML is supposed to be a general solution for exchanging data on a large
scale. This puts it into the category of global Internet technologies.
If XML is to succeed it must be as simple as absolutely possible. In my
opinion the W3C almost screwed up with the XML 1.0 spec it self, the
only thing that saved them was the option for simple well formed XML.
This allowed the majority of people to just ignore most of the cruft
they didn't understand and still do some very useful things. This gave
XML a minimal victory. Now it is time to build upon it as real world
usage dictates using ideas known to actually work in the wild. This is
where I think the W3C has run off the tracks. They're building on it
alright but I don't know how much of this is really based off of real
world usage and ideas.

I know I'm just echoing what has been said many times in the past, but
the idea that iterative development should not be applied to
specification development I find quite disturbing. That model worked
quite well to create this globally interoperable network called the
Internet. Just because the result isn't perfect doesn't mean that it
isn't incredibly useful. A perfect elegant masterpiece of academic
ingenuity that solves everybody's problems and insures interoperability
at any possible level is in actuality not perfect at all if it isn't
widely implemented AND deployed in the real world. 

> 
> Daring to do less is still a dare.

And it is a dare that the history of the Internet has shown can change
the world.

Just my opinions of course. :-)

-- 
Kimbro Staken
Chief Technology Officer
dbXML Group L.L.C
http://www.dbxmlgroup.com