61–70 of 81 posts
Uh... so the bottom one of the or is CSV 1.1? How do you define headers? There's no header for the bottom csv version so I have to manually type headers for my data frame? I got a dataset with 87 obs and ~8700 columns here. I'm not going to manually name those columns. What's the solution?
What if you want to start a row with a field that has a `#`? Not to mention how to handle backwards compatibility with the above concern...
Earlier quoted context omitted.
FYI: The readme (the website) is the specification :-), see https://github.com/csv11/csv11.github.io PS: csv-next is NOT an informal specification - these are notes (collection of ideas). PPS: How do I know? I'm the author of the website - I should know ;-).
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…
Earlier quoted context omitted.
One of the authors of the Frictionless Data specifications here. The spec directly relevant to CSV is Table Schema [1], and we’ve also got some nice tools that leverage Table Schema and the family of specifications, such as goodtables [2]. [1] https://frictionlessdata.io/specs/table-schema/ [2] https://github.com/frictionlessdata/goodtables-py
This looks interesting and useful. It might be a feature that wouldn't get used a lot but I've always felt that it would be great to have a 'unit' field to specify the physical units of the values. Have you ever discussed adding this as an optional field to the specification?
https://github.com/frictionlessdata/specs/issues/537
Feel free to add your use cases to that issue.
Good effort. And I like the minimal documentation. However, and I would love to be proved wrong, I think you are about 20 years late for this project to get any interest aside from some effimerous moments in hackernews...
[1] https://github.com/openfootball [2] https://github.com/openmundi [3] https://github.com/openbeer
Some time ago I've worked on a similar, CSV-like thing that improves on readability and canonical representation, and which can hold multiple tables in a single file or stream like a database: http://jstimpfle.de/projects/wsl/main.html . (I hope it's not rude to reference it here)
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
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 different units like m² are there) from your page.
I'm not saying I'm a good specification writer (and I'm not even a native speaker of English), but I at least try. I have once written an informal specification [1] which should be almost enough to write valid files and start implementing parsers, without being too complicated. You can avoid a complicated specification without being too vague.
> For inspiration, here's an example from your humble self - https://github.com/csv11/csvreader
That's frankly much better (in terms of explicitness) than the front page, why not linking to it? :-)
But I believe that it is still not sufficient. Rather, I'm now unsure about the goal of your project: is it a set of Ruby libraries with fancy, modern but incompatible (by itself) CSV extensions? Or is it hopefully going to be a universally used format? If your intention was the former, then your front page should have been clear about it---it is not about a format but about a library. And if you are going to have a format, then my suggestions hold.
[1] https://github.com/lifthrasiir/cson (with a bit of formal materials, just for the clarity)
Even if a `spec` is created which clearly defines these cases and standardizes how they should be handled, does it qualify to be called CSV 1.1 (or 2.0? really, as it probably won't play nice with existing CSV 1.0 implementations). It is almost as-good-as creating a new format altogether. And there are many to complete with.
I also wonder if it REALLY solves the problems it aims to solve (even if the tech specs were in place). CSV in any form is not human-friendly. This is especially true when you have wide columns (say >30). Even if the records were spaced-out in a human-friendly way in STATE-1, editing records where values are of highly varying width (within a single column) will soon mess the justification when you get to STATE-2. If you skip the requirement for `fixed-number-of-fields` and `key:value` style named values; that messes readability (by humans) even more!
I've had good success with `reading` CSVs using the `csvtk` (https://github.com/shenwei356/csvtk). It provides excellent support for pretty-printing CSVs, filtering select fields etc. `writing` is still a pain, but I still feel spreadsheets are the way to go. They have been around for decades. Its sad if the formatting by specific tools is screwing CSVs, but, solving the composition/modification requirement purely by way of formatted-plain-text is a really tall ask.