> -----Original Message-----
> From: Rick Jelliffe [mailto:rjelliffe@a...]
> Sent: Thursday, January 04, 2007 5:53 PM
> To: xml-dev@l...
> Subject: Re: [xml-dev] json v. xml
> 
> We are better off with two (or ten) small, distinct languages that
> developers can master rather than multiplying the complexity of XML in
> futile attempts to make it useful for everything. The opposite of
> complexity is not simplicity but modesty.

I've been having very similar thoughts.  For pure text documents, XML +
RELAX NG hits a sweet spot; for SOAP-ish web services and X-O databinding,
XML minus DTDs + namespaces + XSD is not much more complex than absolutely
necessary; for data-oriented Web apps JSON is another sweet spot;  for
mobile apps with constrained bandwidth, maybe the W3C EXI folks will find
another sweet spot with a binary XML format.  NOT insisting that one size
fits all these scenarios is a recipe for peace and progress in each domain
(and negates my primary objection to the EXI WG's efforts).

BUT there's the little problem of tooling.  Does each domain have to evolve
their own schema/data constract language, their own APIs, their own
query/transform languages? Will there be enough users in each domain to
support top-quality tools, whether they be commercial or OSS? 

There's also the "zero-one-infinity rule".
http://www.catb.org/jargon/html/Z/Zero-One-Infinity-Rule.html Once we
abandon the one size more or less fits all in principle, there's no logical
stopping place before utter fragmentation and non-interoperability.  Power
laws will tend to keep those in the mainstream at a manageable number, but
that was true of data formats pre-XML and it wasn't a particularly happy
world to live in.

There is something to be said for trying to unify all this around some sort
of "XML 2.0" that is founded on a common, minimal but extensible tree data
model rather than the bits on the wire [zipping up flameproof suit in case
Tim Bray still subscribes to this list :-) ]; treats the various bits on the
wire as alternative serializations in a manner analogous to how XML 1.0
handles encodings, and thus maintains compatibility with the infoset-based
tools such as DOM, XSLT, XQuery, etc.  Just perhaps, the threat of
JSON/EXI-induced chaos might motivate the W3C to think about this.  If the
W3C doesn't de jure, I suspect that the major platform providers or the
communities around them will do it de facto.  In .NET for example, I could
easily imagine an XmlReader and XmlWriter implementation for JSON and/or
EXI, which would more or less automatically enable DOM, LINQ to XML, and
XPath/XSLT to work with these formats, at least to the extent there is a
canonical JSON <-> InfoSet-subset mapping. [Disclaimer: These are my
personal random thoughts, not a statement of direction!]