3 ms·

Don't we do CSV/TSV anymore? It's certainly the most basic schema-less data format imaginable, and you can even have field names using the convention that the f

• jxub 8y ago
  CSV standards are flawed and it has a lot of weird edge cases. Moreover, byte encoding formats are more concise, so faster to transport over the wire and store and the schema seldom proves to be an hindrance, as it assists in data validation and acts as documentation.
• jerf 8y ago
  "It might be considered out of fashion today in our staged this-vs-that culture, but I don't see anything wrong with it.... no API required." Well, it has no type system, not even "string vs. number", no hierarchy of any kind (no objects, no lists, nothing going deeper), and CSV/TSV is actually a meta-specification requiring a correct use of CSV to provide a complete specification (since you can trust literally nothing about a CSV/TSV implementation otherwise) so you can handle the distinguished characters in the data values. Whatever it is you are about to say is the answer to that problem is not; it is an answer and there are others in common use, and correct usage needs to specify them. Unlike the formats listed, it's completely unclear how to serialize arbitrary objects into it in a way that other people would agree to sight-unseen. That is, yes, I'm aware you can jam anything you want into CSV. For instance, you could make one of the columns be JSON. But that defeats the purpose of claiming it's good enough on its own, no? Same for any other scheme you might propose; unless you can show it to be a standard, it's not an answer, just an ad-hoc solution. I'm not saying it's useless. Literally used it last Friday to dump some data into something that could be loaded by a spreadsheet program so someone can mix & match the data without having to ask for every individual possible view to come straight from me. Very useful format at times. But as a generalized serialization format? It's not even in the running, which is precisely why it doesn't come up in these discussions. If you want to get concrete, show me the canonical way you'd lossly serialize the DOM tree nodes for the HN home page into CSV, in a way that you are reasonably sure is the same way everybody else would tend to if given the task, then show me the emitter and generator code that is more convenient than the alternatives.
  • tannhaeuser 8y ago
    > 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.
• imtringued 8y ago
  It's complicated enough that you need a library to properly use it and simultaneously simple enough that people think they don't need a library. Then there are the billions of possible variations. Nobody can agree on a common column (is it ',' ';' or '\t'), newline seperator, whether the first row is a header and you can only store data in the first normal form. CSV is so terrible that even excel spreadsheets are a better data exchange format.
  • tannhaeuser 8y ago
    Nice said :) but come on. CSV parsing is trivial.