RE: The tragedy of the commons

[Jeff Lowery <jlowery@scenicsoft.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.

Yes, those divisions are the ones that should have the focus for either
being resolved or shelved. The XML Blueberry issue pointed up some problems
in XML itself, like it's hard dependency on Unicode 2.0 for Names. Those
issues should be addressed as core issues, but not necessarily resolved at
the moment. Changes would propagate up to the specialized XML branches.

The simple stuff can be agreed to first. That's the core of the core set. If
it takes 100 postings to argue if it's simple or not, it's a priori not
simple. If one large group of people want it bad, and and another not at
all, then it's not core, or at least not all of it.

I guess what I'm saying is that we need a formal categorization and
recognition of the various domains XML operates in, and what their
requirements are. Then we can sit down and map them out, and address the
overlap. If there appears to be a consensus agreement on certain features,
then they are "core" or "common". 

What's left is the specialized stuff. Now there's the problem of "soft"
specialization and "hard" specialization. Soft specialization would remain
compatible with the core specifications, and with other soft
specializations; hard would suit only the needs of the domain at hand. Hard
is incompatible with core, (and other domains) because it requires features
core does not support. That doesn't prevent one hard-implemented domain tool
from communicating with another outside the domain, but some munging would
have to be provided in the transfer. 

This is a crucial point that Simon made: there are tools that provide means
over the barriers of domain specializations. I can move data from the
document domain to the data domain by first validating it against a schema
that I write, and the document people are unaware of. If they change the
document, my schema is broken, not their document. They're the ones driving
(but I might plead with them to slow down and obey the traffic signs :-)).

It ain't easy, but it would probably departmentalize some of the noise. It
would at least allow the simpler problems emerge from the hard ones. I would
then see the W3C more as a body like the European Parliament, working out
the kinks and settling disputes that cause problems with the free
interchange of information, not as a stand..., er, recommendations body.
More of a rulings body that keeps things running smoothly without dictating.

That would be cool.