Re: [xml-dev] Do you enjoy neighborhoods where every house looks the sam

["Bill Kearney" <wkearney@gmail.com>]

My counter wasn't so much about complicating, just further illustrating the 
rather pointless analogy being flogged.

I mean, really, what's the POV being espoused here?  What argument is being 
made, but being hidden behind a seemingly 'easy to digest' analogy?

-Bill

-----Original Message----- 
From: Wendell Piez
Sent: Wednesday, August 28, 2013 7:19 PM
To: xml-dev@lists.xml.org
Cc: Simon St.Laurent
Subject: Re: [xml-dev] Do you enjoy neighborhoods where every house looks 
the same?

Hi,

I almost never post to this list, mainly because the wattage shorts
out my brain. I find that even reading it gets me freaky, to say
nothing of writing for it.

Nevertheless I have to write this time, mainly because I've been
thinking about these issues for so long.

Bill's counterexample is not only interesting because it undermines
the evident logic of Mike's door example, but also because it doesn't
actually demonstrate anything conclusive; it only complicates it. A
real counterexample would have a carpenter hand-making a door to fit
without the benefit of any specialized tools for measuring, making,
and hanging doors: it would be done entirely by hand using tape, saw,
drill (hand drill only please), plane, sandpaper, varnish and
I-don't-know-what-else you use to make and hang a door. This John
Henry of a carpenter would do as well as the factory, as cheaply, and
(unlike John Henry in the song) would live to do it again and again at
competitive rates.

But the local lumber yard has its own door-and-trim shop! They are
able to do custom work at a fraction of the expense and trouble you'd
expect otherwise because ... because there is apparently a commodity
market for specialized tools and materials for door-and-trim
construction, and because there's enough of a local market where Bill
lives to support this activity with enough work to employ carpenters
who soon become experts in doors and trim. In turn, this commodity
market depends on standards. When their circular saw goes down, they
don't have to make another one from scratch.

Yes, standards crowd out customization and expressiveness, as do
monopolies (which are merely the subjection of dominant standards to
proprietary interests not beholden to the commonwealth, commandeering
many of the benefits of their network effects). But they also enable
customization and expressiveness at higher levels. (Of course we all
know this, right?) XML represents an advance over SGML because by
specifying a syntax without consideration of constraints enforced by a
schema, it enables the sort of expressiveness that Simon and I prize.
This expressiveness isn't the formal sort (XML can't say anything that
SGML can't) but only in a practical sense: I couldn't deploy a new tag
set every week (with or without a schema) if I didn't have tools that
reliably process XML syntax, allowing me to iterate my design and my
processing logic without having to pay schema overhead until I need to
enforce more rules to scale up gracefully. In other words, XML
(meaning both the standard and the commodity toolkit built on top of
it) allows me to do more with less. On the other hand, using XML also
limits me in some significant ways. The tool shapes the hand, and
pretty soon I think every data structure is a tree.

Unfortunately for me, this puts me on both sides of the debate here.
Standards are great, except when they're not. I depend on them, but
I'm also skeptical of one-size-fits-all solutions to any problem at
any level -- and most especially of one-size-fits-all ideologies or
formulas that promise to solve entire classes of problems without
getting in there and dealing with them. We see this in XML all the
time. Schema validation by itself doesn't warrant a document instance
for fitness for any process other than ... schema validation. At best,
it's a convenient proxy for helping to manage some issues of fitness
and isolate them early; and *maybe* it's an orthogonal indicator of
the likeliness of problems it doesn't detect. These capabilities can
make a schema useful at certain kinds of system boundaries. Does this
make a schema worth the effort of development, maintenance and
support? It depends. And even when it is, a schema (most especially
when elevated to the status of a standard in name or in fact) can
quickly become a sacred cow. Which is probably all by itself a good
reason for Simon not to like them.