Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@l... Cc: Simon St.Laurent Subject: Re: 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
