[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] The tragedy of the commons
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).
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|