RE: The tragedy of the commons

[Michael Brennan <Michael_Brennan@allegis.com>]

Nicely put, Jeff, and I agree with your sentiments. I have tried to say some
of the same things in different language. However, the divisions are not
always just between the two camps; sometimes they cut across the camps.

I would also add that in my use of XML, I am mostly in the "data" camp,
though I occasionally venture into the "document" camp. I am also a relative
newcomer to markup technologies, compared to many on this list who have
long-standing experience with SGML. As I've worked with XML and followed
debates on this list, though, I have acquired a deep and growing
appreciation of the traditions that XML inherits and the rich and varied
domains it serves. It would be a shame for that to be sacrificed to suit the
needs of one domain, especially when the needs of that domain *can* be
layered on top of general foundations that can serve everyone's needs (of
that I am firmly convinced).

IMO, one way to accommodate everyone is for all to recognize that there are
great facilities available for adapting the information in a document to a
particular processing model. We have SAX filters, XSLT templates, and many
other facilities that would allow an application to control the view it sees
of a document. So I find it difficult to fathom why we see such vociferous
debate from people insisting that applications must adapt to a rigid view
defined by a particular schema. These transformation tools are not evil.
They are a core part of what XML is all about. Trying to accomodate
different camps with such rigid perspectives poses an unresolvable
conundrum. Flexibility on the processing side is a way out of the conundrum.
Let applications see the view of the document instance that suit their
processing needs. Insistence on imposing one processing model from one
domain on every consuming application just hardens divisions between camps
and takes us down a path that serves no one.

> -----Original Message-----
> From: Jeff Lowery [mailto:jlowery@scenicsoft.com]
> Sent: Friday, August 31, 2001 10:04 AM
> To: Xml-Dev (E-mail)
> Subject: 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).