4 ms·

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

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 https://github.com/csv11/csvreader

lifthrasiir 8y ago
> 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 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 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 https://github.com/lifthrasiir/cson (with a bit of formal materials, just for the clarity)
- geraldbauer 8y ago
  The goal of the project is to improve CSV :-) - it's in the title e.g. CSV Evolved and in the version 1.1 (that is, it's not version 2.0). It's about not breaking things - it's about small changes (mostly) for humble humans (not machines). 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.
HelloNurse 8y ago
A specification has to be, um, specified. For example, the first thing to explain is whether the file format is actually text and if it is what the allowed characters and encodings are. And let's not forget the big one: how are records and fields delimited? Too boring to explain? 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.
Noumenon72 8y ago
You should stop using smilies in this passive-aggressive manner. You should also stop condescending to people. You may feel that you can't be wrong so they must not understand because they are too dumb and daunted by it, but you should not be revealing that to them in your comments, because it's so offputting.

lifthrasiir 8y ago

> 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 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 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 https://github.com/lifthrasiir/cson (with a bit of formal materials, just for the clarity)

geraldbauer 8y ago
The goal of the project is to improve CSV :-) - it's in the title e.g. CSV Evolved and in the version 1.1 (that is, it's not version 2.0). It's about not breaking things - it's about small changes (mostly) for humble humans (not machines). 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.

HelloNurse 8y ago

A specification has to be, um, specified. For example, the first thing to explain is whether the file format is actually text and if it is what the allowed characters and encodings are. And let's not forget the big one: how are records and fields delimited? Too boring to explain? 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.

Noumenon72 8y ago

You should stop using smilies in this passive-aggressive manner. You should also stop condescending to people. You may feel that you can't be wrong so they must not understand because they are too dumb and daunted by it, but you should not be revealing that to them in your comments, because it's so offputting.