> canonical [way to] lossly serialize the DOM I'd rather not :) That's what SGML and XML are designed for. I agree with your points, but I think the pursuit o

> canonical [way to] lossly serialize the DOM I'd rather not :) That's what SGML and XML are designed for. I agree with your points, but I think the pursuit of the one generalized serialization format to rule them all is misguided and scratching an intellectual itch rather solving a practical problem anyone is having. In my experience, either you want an upfront interface-first design. When you constrain yourself to mainstream techniques, chances are you'll be using XML/XSD, though it's not ideal to describe co-inductive data structures (it's a grammar-based formalism for text after all). Or you're not working on system boundaries, and your project doesn't benefit from interface-first design (such as in a Web app with a dedicated back-end). Again if you don't feel like introducing non-mainstream formats, you'll be using JSON. Everything else seems to be prone to falling into an https://xkcd.com/927/ https://xkcd.com/927/ trap at this point. Sure there are other use cases (binary data, mass data, streaming, whatever). But these are at least as niche as those for TSV/CSV.