Cart
[Home] [By Thread] [By Date] [Recent Entries]
> -----Original Message----- > From: Rick Jelliffe [mailto:rjelliffe@a...] > Sent: Thursday, January 04, 2007 5:53 PM > To: xml-dev@l... > Subject: Re: 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!]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
