The tragedy of the commons

[Jeff Lowery <jlowery@scenicsoft.com>]

Not being a card-carrying member of the XML Brain Trust, nonetheless I can't
help but think that a wide-eyed simpleminded perspective might offer a
detachment from the nitty-gritty of technical debate and pull things up to a
bit more philisophical level:

The success of XML in a wide variety of domains and purposes may have lulled
some people into thinking that such astounding and unmitigated success is
reproducible. As we build technologies on top of this achievement, it is
becoming more apparent that such success is an exception rather than a rule.


That's not to say that XML was a hit overnight, but its acceptance is
largely attributable to its simplicity and utility. XML was not ahead of its
time, but was perhaps a belated technology whose arrival on the scene met
pent-up demand for the solutions it offered. 

What were the original requirements? Simplistically put, that it be simpler
that SGML but retain the most-used 80% of its functionality; requirements
which were met and exceeded.

Now, however, there are new requirements, ones that have not appeared on the
scene until recently. These requirements come from various groups with
different needs. How much of these requirements are common? The assumption
seems to be that they all are. This is folly.

On the one hand, we have the foundation: XML. XML is not perfect for
everybody, or even anybody, but it is Good Enough for many domains and uses.
It is truly a general-purpose tool. But now we have taken that simple,
general-purpose tool and tried to turn it into a power tool. More is better,
right?

It not a bad desire to want more powerful tools, but it is presumptious to
think that these more powerful tools will find the same audience that the
simpler on did. Some will, some won't. Hardly anyone uses a hand drill, but
plenty of people still find use for old-fashioned screwdrivers. Sometimes
power gets in your way.

It's obvious to most people that there are two main camps that exist in
XML-land, "data-heads" and "doc-heads" as Sean McGrath put it (object-heads
and infoset-heads appear to be data-head variants; their requirements can be
dealt with as an internal matter). There are signs of these being hostile
camps, which is a shame. The doc-heads got here first, and now the
data-heads are pushing their noses into everybody's business. Such
resentment can lead to the establishment of a political border in XML-land,
with the inevitable divergence that will arise from that split. What we need
is to understand the common interest, and respect and accomodate the
divergent ones.

Of common, established de facto interest is XML (minus DTDs, which I'll get
to). There are warts, to be sure, but none that can't be lived with for the
time being; there are bigger fish to fry. XML can be a foundation for
further commmon tools, but to be successful we first must recognize the
disparate interests of the two main parties involved, and recognize that not
all parties will agree on what is needed. That's fine, because the
requirements are different.

One common requirement is the need to validate XML documents. The two camps
don't have the same requirements, though. Doc-heads want flexibility and
simplicity, data-heads want rigor and extendability. That's not to say that
there isn't common ground. What's needed (and what should be a pattern for
all XML tool development) it the understanding of what is common, what is
not, and that there are three technologies that need to be developed:
common, document-oriented, and data-oriented. It's a tough cut, to be sure,
but it will be the most flexible way to handle new camps when they arrive,
as they inevitably will.

Namespaces are another troublesome area. I just read 100 postings on the
subject and I would say that the doc and data camps seem just as apparent
there as elsewhere. Finding out what is common there is going to be tricky,
it seems. The data-heads want semantic consistency, the doc-heads want
cut-and-paste flexibility independent of semantics (and I know that's
simplifying it quite a bit).

Nobody should foist the solutions to their requirements onto those who don't
need them.  Another truism is that you should only pay for what you need.
Some will argue that XML adheres to that philosophy, but the recent
arguement about namespaces and PSVI indicate otherwise. Let's not alienate
people who are honestly trying to use the technology as best they see fit.
Let's agree to disagree, but let's also 1) understand that there are
different, incompatible requirements from two main factions; 2) understand
that divergence is inevitable, but can be controlled and accommodated in a
rational, well-ordered way.

Otherwise, I fear that the tools will collapse of their own conflicting
requirements, that the technology will become a jumble of useless
initialisms, and that stances will become hardened and recalcitrant. 

Find out what requirements are common, parcel out what aren't. The result
will be general-purpose tools (XML-core), specialized tools (XML-data and
XML-doc), and tools that are custom-made by the masses (XML-whatever).