Earlier quoted context omitted.
This is a very cool idea but why not just add the closing tags and have a minimal format that is also valid HTML and can easily view the data by pointing your browser at the file? It's already a universal format and as dtech mentions below, you get Excel compatibility. I would also add headers and an optional type attribute... Age If the file is too big then you probably need compress it or use a more appropriate for…
The document I posted was valid html6 -- all of those end tags are optional. From an XML purist's perspective that's abhorrent, but if we're trying to make a terse table format skipping the close tags is good.
Why isn’t there a decent file format for tabular data?
261–270 of 355 posts
Re: Why isn’t there a decent file format for tabular data?
#262Earlier quoted context omitted.
But that’s sort of the problem with csv. You never really know which rules your csv files has. Many .csv files are indeed tab separated.
It’s a very meta-level problem. The main problem with CSV is “this is CSV” is an ambiguous statement. One could commit to a rule set, and give it a new name. Probably, someone has done this already.
Re: Why isn’t there a decent file format for tabular data?
#263Earlier quoted context omitted.
ASCII separators (mnemonics FS, GS, RS, US) are difficult for most users to type, and have no obvious/standardized visual representation.
Who is typing out CSVs anyway. You’d either use a spreadsheet tool or do it in code.
Re: Why isn’t there a decent file format for tabular data?
#264Why are all these "separated"? Sounds like null-terminated C strings. Wouldn't it be better to put the dimension in a header and then just dump the contents unseparated? Why the need to view them in simple text editors?
What you suggested works for fixed width fields only, doesn't it?
Re: Why isn’t there a decent file format for tabular data?
#265Fundamentally, why are people so concerned about about hand editing tabular data? The options for that are pretty terrible. Only editing an existing value in one cell is ok. Everything else - adding new rows, new columns and making sure the file format and column structure is correct - is all terrible. This gets doubly so if you stick it in git and start getting messy pull requests. I would carefully question what us…
Re: Why isn’t there a decent file format for tabular data?
#266Seems like the problem here is there is several high quality and well-developed formats, but the author and the commenters here dismiss them because of the different trade-offs they make. csv -- Simple for simple use cases, text-based, however many edge cases, feature lacking etc xlsx -- Works in excel, ubiquitous format with a standard, however complicated and missing scientific features sqlite -- Designed for relat…
The DBT (DBase III) format was common in the 80s and 90s. It is a typed, fixed-width format that was directly supported by Excel, Visual Basic grid widgets, among many other tools. For example, Norton Commander supported it directly, letting you preview database tables without loading another program.
That should actually be DBF, the format for the main database tables. DBT was an ancillary format for the memo fields, which were used to store longer pieces of text in one column of a DBF record. Overall, that generic format and associated software is called XBASE. People still use it in production. And data entry (CRUD) using it with plain text or TUI DOS-style apps blows Web and even GUI apps out of the water in speed of use.
Re: Why isn’t there a decent file format for tabular data?
#267Re: Why isn’t there a decent file format for tabular data?
#268Earlier quoted context omitted.
Gotta wonder why the format isn't just a column separator char, a row separator char, and then all the data guaranteed not to have those two chars. Then you could save the thing by finding any two chars that aren't used in the data. I guess this is why we have a zillion formats.
ASCII Code 29: Group Separator ASCII Code 30: Record Separator ASCII Code 31: Unit Separator https://theasciicode.com.ar/ascii-control-characters/record-...
Re: Why isn’t there a decent file format for tabular data?
#269Seems like the problem here is there is several high quality and well-developed formats, but the author and the commenters here dismiss them because of the different trade-offs they make. csv -- Simple for simple use cases, text-based, however many edge cases, feature lacking etc xlsx -- Works in excel, ubiquitous format with a standard, however complicated and missing scientific features sqlite -- Designed for relat…
None of them seem all that conducive to source control or merging. Any good format for that?
Works like a charm!
Re: Why isn’t there a decent file format for tabular data?
#270Parquet is a wonderful file format and is a dream to work with compared to CSV. Parquet embeds the schema in the footer metadata, so the query engines don't need to guess what the column names / data types are. Parquet used to be poorly supported, but now it's well supported by almost all languages. You can even view Parquet files in text editors now, but that's not something I've ever needed ( https://blog.jetbrains…
The other problem with Parquet is that it's overly flexible/supports application-specific metadata. It's all fine when you use a single tool/library for reading and writing files but cross-platform is problematic. Saving a Pandas dataframe to parquet, for example, will include a bunch of Pandas-specific metadata which is ignored or skipped by other libraries.
In this case, it required converting timestamp/datetime columns to a nano time int64 representation before writing data from Pandas (for example), otherwise you could not read those columns using anything that wasn't Pandas.
But maybe this has changed but at the time I last used parquet as a table format?