I would describe it as a _pyramid of bounded viability_ , from the minimally viable to the feature-burdened maximum. CSV excels (ha) as a minimally viable exch

I would describe it as a _pyramid of bounded viability_ , from the minimally viable to the feature-burdened maximum. CSV excels (ha) as a minimally viable exchange format for data. Combined with awk, grep, sed, bash, and Perl, and some simple SVG or D3 with SVG, the analytical solution is fast, scalable, and automatable. But CSV has limits. The column headers are the schema. Beyond these bounds, we have the other formats. JSON is messier. Its strength is in network/browser encapsulations and operations. As I have seen it used, people insert an array as a kind of schema, and they stay away from complex nesting where scalability starts failing and other difficult tooling must be summoned to compensate (parsing tools such as jq). Beyond JSON's bounds, we have XML and associated tooling. XML is versatile and expressive. XML and JSON can be written simply but both can be abused by programmers who aren't thinking beyond their own cursor. This is a rich set of tooling for data representation. In the end, one of the main advantages of CSV is that it remains a format that brings little tooling baggage ("ecosystem") to the task.