[{row1}, {row2}, {row3}]
The fact that it can do more is in no way a negative. Can even make a limited JSON parser with reduced capabilities. And with JSON can do more definitions like header names vs column names vs just arrays of arrays.
[{row1}, {row2}, {row3}]
The fact that it can do more is in no way a negative. Can even make a limited JSON parser with reduced capabilities. And with JSON can do more definitions like header names vs column names vs just arrays of arrays.
And since it doesn’t require one record per line it can be a hassle to read without having to parse it.
It’s really nice to be able to do “head -n 5”
I think there was some off-spec dialog called something like “appendable xml” (only snappier) that said the closing tag of the root element was optional, but it was clearly a hack.
I wanted there to be no root element at all, and the filename (or, the last part of the url) would act as the root element. Kind of weird idea in hindsight, but kind of useful too.
One downside is that there’d be no obvious way to specify attributes on the root element.
json is absolutely horrid for this type of hack-in jobs. Tabular data just not well structure data, easy to cut and paste.
I could see a specialized form of JSON using jagged arrays
{"Header": ["Name", "Street Address", "City"]
"Body": [
["Alice", "123 Fake St", "Faketon"],
["Bob", "987 Any Pl", "Anytown"],
]}
in that way the keys aren't repeated. It wouldn't be coherent useful JS objects when deserialized, but it would be trivial to convert js table object into a true array of Javascript objects.>> XML and Javascript are tree structures and not suitable for efficiently storing tabular data (plus other issues).
If you can do anything, it becomes hard to do the right thing. If you can only do the right thing, it becomes trivial to decide.
[{"col1":"val1", "col1":"val2"}]
["header1", "header2"]
["val1", "val2"]
...
The entire file isn't valid JSON, but if you load each line independent of the next (jsonl), then you're fine.