71–80 of 81 posts
Why not use tab-separated values, you get improved readability and less quoting needed, or am I missing something?
How does this improve on RFC 4180? (I only _wish_ excel and many other parsers behaved predictably like that RFC, but it is a decent proposal. ) ( https://www.ietf.org/rfc/rfc4180.txt )
Just for the record to quote from the memo:
This memo provides information for the internet community. IT DOES NOT SPECIFY AN INTERNET STANDARD OF ANY KIND. IT DOES NOT SPECIFY AN INTERNET STANDARD OF ANY KIND. IT DOES NOT SPECIFY AN INTERNET STANDARD OF ANY KIND.
Just repeating it three times in case you missed it, see https://www.ietf.org/rfc/rfc4180.txt
Earlier quoted context omitted.
I think you don't understand :-). A specification doesn't always have to be complicated, that's the point. I'm all for tech notes with all the details. Here's a challenge for you - write a csv parser - I know - it's a daunting task. For inspiration, here's an example from your humble self - https://github.com/csv11/csvreader
> A specification doesn't always have to be complicated, that's the point. That's right, but your "specification" was not even enough for writing a CSV 1.1 file. For example I have mentioned a front matter issue---there is no example using it, and I'm deeply confused how the front matter looks like (or even where it is). I'm seeing numeric units there, but I don't know how they are handled (or, say, what happens if d…
It's NOT about one universal csv format and the ultimate specification to settle the matter until the end of history etc.
Thanks for the detailed suggestions. I see your points. I appreciate your helpfulness.
[ ["If", "we're", "going", "to", "improve", "CSV"], ["Let's", "do", "it", "with", "some", "JSON"] ]
See the CSVJSON format - http://csvjson.org - Love it. I will add a new variant called CSV <3 JSON shortly to the CSV 1.1 repo and csvreader etc. too.
Earlier quoted context omitted.
I've recently been dealing with some CSV data exported from Excel. One of the columns has lengths measured in inches or feet. A column that says 14" exports as , '"14"""', It feels downright silly to me.
A cell w/ 14" would be ,"14""", And I verified that all four of Excel's CSV varieties write this, but this is also what RFC CSV writers would emit. Not saying you can't pick up oddities elsewhere, but as stated, it's not that bad. (Not that I condone use of CSV… it's an awful format.)
Earlier quoted context omitted.
Oh, hello! My gut feeling was that csv-next is pointing to the informal specification (and they read like it, but specific to a single problem point). I guess you might not have understood my complaint (my bad), so let me give some examples how the specification should look like. An informal specification looks like this [1]. You should give examples and rules enough to use your format and sufficient to implement mos…
I think you don't understand :-). A specification doesn't always have to be complicated, that's the point. I'm all for tech notes with all the details. Here's a challenge for you - write a csv parser - I know - it's a daunting task. For inspiration, here's an example from your humble self - https://github.com/csv11/csvreader
On the whole, some ideas to make CSV files human-friendly, but neglecting backward compatibility (comments, use of spaces...) and introducing major syntactic and semantic cans of worms (multiline values, named fields, defaults...). I think CSV files should evolve towards tighter constraints instead.
Well, if you want to improve tabular data formats: 1. Add a version identifier / content-type on the first line! 2. Create a formal grammar for this CSV format 3. Specify preferred character-encoding 4. Provide some tooling (validation, CSV 1.1 => HTML, CSV => Excel) 5. Add the option to specify column type (string, int, date) 6. Specify ISO-8601 as the preferred date format 7. Allow 'reheading' the columns in the fi…
"CSV on the Web: A Primer" http://www.w3.org/TR/tabular-data-primer/
"Model for Tabular Data and Metadata on the Web" http://www.w3.org/TR/tabular-data-model/
"Generating JSON from Tabular Data on the Web" (csv2json) http://www.w3.org/TR/csv2json/
"Generating RDF from Tabular Data on the Web" (csv2rdf) http://www.w3.org/TR/csv2rdf/
...
N. Allow authors to (1) specify how many header rows are metadata and (2) what each row is. For example: 7 metadata header rows: {column label, property URI [path], datatype URI, unit URI, accuracy, precision, significant figures}
With URIs, we can merge, join, and concatenate data (when e.g. study control URIs for e.g. single/double/triple blinding/masking indicate that the https://schema.org/Dataset meets meta-analysis inclusion criteria).
"#LinkedReproducibility"; "#LinkedMetaAnalyses"
I can't see this gaining any traction. There's nothing wrong with CSV as it is for basic data transfer. CSV had been unchanged now for so long, that any attempt to update it will fail - there are simply too many CSV parsers already implemented. If you are worried about people in the year 3000 understanding your data, add a .txt file alongside the CSV explaining the fields.
> There's nothing wrong with CSV as it is for basic data transfer. I disagree. CSV is horribly underspecified and many parsers have conflicting ideas on how things should work. I've hit areas where, for example, an API was generating a CSV that another API could read, but NOT if it was opened and then re-saved by Excel first (just re-saving, not editing), because Excel was making some trivial change in the format tha…
1. Look at how everybody is extending CSV in the real world
2. Make a new format which does those things, as closely to all the existing implementations as is reasonable
3. Write a fully-specified new syntax for it, including a complete parser (state machine including error cases)
4. Make a complete set of tests, which make it very obvious when you don't pass, for shaming everyone into compliance
5. Get buy-in from a major standards organization, and all of the major corporate players
I don't see any improvements/replacements succeeding if they don't hit all of these points. "CSV 1.1" here hits #1 and #2 only.
There are a ton of problems here: * From the documentation "No quotes needed for values ... Use dual quotes ... Use triple quotes" * You haven't solved the problem of describing what the columns are. In fact, its worse because you are encouraging people to put units in the field * Spaces matter! What if the data is literally " Word " vs "Word". This format makes them both the same. * For some reason, the header row i…
Hello, I'm the original author of CSV 1.1. There are no problems :-). You're making up things / problems. Nowhere says it that the header row is removed. You CANNOT auto-detect a header, you have to tell your parser (see the csvreader library as an example - https://github.com/csv11/csvreader - from my humble self.) if you have a header or not (it's optional). If Spaces matter! but them in quotes. By default you don'…
So, just like a regular CSV?
Well, if you want to improve tabular data formats: 1. Add a version identifier / content-type on the first line! 2. Create a formal grammar for this CSV format 3. Specify preferred character-encoding 4. Provide some tooling (validation, CSV 1.1 => HTML, CSV => Excel) 5. Add the option to specify column type (string, int, date) 6. Specify ISO-8601 as the preferred date format 7. Allow 'reheading' the columns in the fi…