へー面白い。面白いけど誰得なんだ。JSON-LinesをExcel が読めるようになればそれでいい気もする。
データフォッ的 ??? あ、データフォーマットのtypoか
配列はデータ側で「配列である事」を明示できる利点があるけど、構造化は結局プログラム側が構造を知ってないと扱えないからフラットでよくね?ってなるな…。構造が任意個続きますみたいな指定ができるのは嬉しい。
へ〜！
そこまでしてcsv使いたい理由が無い
誰が何を定義しようとCSVなんてExcelで読み書きできるかが全てじゃない？JSONでいいよ
jsonでおｋ
JSONとかExcelとかすでに普及してるフォーマットがすでにあるからな
提案者の記事 https://www.linkedin.com/pulse/csv-data-interchange-format-weve-been-waiting-marcelo-caldas-it8pe
xmlとjsonで十分な気はした。
一つのカラムになんらかのセパレーターで複数のデータを突っ込むのは、今までもアドホックに行われて来たわけで、その手法の規格化？
これが嬉しい状況があまり思い浮かばないな。csv しか扱えないレガシーシステムでどうしても構造化データを扱いたい時？普通は yaml でいいやになったり、レガシーシステムでもコンバータ書いて済ませそう。
ネストすんなよ。読み込んでそのままExcelにできないし。結局何らかの処理を挟むならJSONでいいのでは
そっか
シンプルなのがいいのに、難しくしたら流行らんだろ
ほなら他のフォーマット使ったらええねんてならない？ readする時に考慮しないといけないなら既存の他データ形式の方が良くないかね。csvを拡張して実現せないかんとなる状況はなんじゃろ。これは誰が嬉しいんやろか
扱うときにダブルクォートとカンマにだけ気をつければいいのがCSVの良さなんだがなあ。ここまでやるんだったらJSONの方がいいな。
excelとかって言われてるけどむしろexcelで手動でデータ編集するときこそ真価発揮するんでねえのこのフォーマット
個人的に「仕様としてのコメント行」が一番欲しい。jsonも。（javadoc/jsdoc的なヘッダ詳細を記述できる記法もあれば尚良し
自分が必要かではなく必要な業務フローは存在するかで考えましょう
確かにJSONは1フィールドごとにラベルがつくので冗長なのでヘッダーしかつけないCSVの方が効率的ではある。
発想は嫌いではないけど（CSVの中に配列や構造化されたデータを持ちたいこともある）、そこまでやるならJSONでよくね？となる
物理計測の保存データだとキーに()や[]で単位を書く場合があり、誤動作しないか心配
方言だらけで終わってるCSVというフォーマットを更に複雑にするの勘弁しちくりーー
おもしろい。Markdownの表で使いたい書式
CSVとしてパースできるんだから今以上に複雑にする要素は何もない（CSVとの互換性を維持しているということの意味を分かっていないやつが多そう）。別に好きにすりゃいいんじゃね。両端の()を外して再帰下降すればいい
ローカルで実績積んで出直してきてほしい。
複数システム間で連携してると、データをただ横流ししてるだけの処理が挟まってることはよくある。CSVとしても扱えるなら途中の処理を変えずにすむ。標準化されてれば誰かがパーサー作ってくれるだろうし。
jsonをそのままCSVで書けて、パースしやすく、既存のCSVとの互換性もある。良さそうね。
既存の仕組みと極力ぶつからない提案してるのは面白い。ただそれで嬉しいシーンがあまり思いつかないし、CSVがテーブル状なのにテーブル設計のアンチパターンをモロに踏み抜いているよう見えてあまり好かない。
そこまでいうならexcel、、、いやなんでもない
勉強できるバカが閃いちゃった感がすごい
世界がコメントを受け入れられるJSONで統一されますように。
他を使えというのはそうなんだけど、これが欲しくなる理由わかる
こんなわかりにくい規格ならjsonでいい。CSVはシンプルで非技術者でも扱えることが利点なので、むしろデータ中のカンマやクオートの処理をスマートにする方向に進化してほしかった。
文字列に[]が入ってて意図しない挙動になる未来が見えるぞ！
開発してると一度はやりたくなるやつだ（笑）。英名と和名を同居させたりJSON文字列いれてメタデータ格納したり。個人的にはフッター行を活用する仕様が欲しい。
『CSV++』フォーマットの提案仕様について - ASnoKaze blog
へー面白い。面白いけど誰得なんだ。JSON-LinesをExcel が読めるようになればそれでいい気もする。
データフォッ的 ??? あ、データフォーマットのtypoか
配列はデータ側で「配列である事」を明示できる利点があるけど、構造化は結局プログラム側が構造を知ってないと扱えないからフラットでよくね?ってなるな…。構造が任意個続きますみたいな指定ができるのは嬉しい。
へ〜！
そこまでしてcsv使いたい理由が無い
誰が何を定義しようとCSVなんてExcelで読み書きできるかが全てじゃない？JSONでいいよ
jsonでおｋ
JSONとかExcelとかすでに普及してるフォーマットがすでにあるからな
提案者の記事 https://www.linkedin.com/pulse/csv-data-interchange-format-weve-been-waiting-marcelo-caldas-it8pe
xmlとjsonで十分な気はした。
一つのカラムになんらかのセパレーターで複数のデータを突っ込むのは、今までもアドホックに行われて来たわけで、その手法の規格化？
これが嬉しい状況があまり思い浮かばないな。csv しか扱えないレガシーシステムでどうしても構造化データを扱いたい時？普通は yaml でいいやになったり、レガシーシステムでもコンバータ書いて済ませそう。
ネストすんなよ。読み込んでそのままExcelにできないし。結局何らかの処理を挟むならJSONでいいのでは
そっか
シンプルなのがいいのに、難しくしたら流行らんだろ
ほなら他のフォーマット使ったらええねんてならない？ readする時に考慮しないといけないなら既存の他データ形式の方が良くないかね。csvを拡張して実現せないかんとなる状況はなんじゃろ。これは誰が嬉しいんやろか
扱うときにダブルクォートとカンマにだけ気をつければいいのがCSVの良さなんだがなあ。ここまでやるんだったらJSONの方がいいな。
excelとかって言われてるけどむしろexcelで手動でデータ編集するときこそ真価発揮するんでねえのこのフォーマット
個人的に「仕様としてのコメント行」が一番欲しい。jsonも。（javadoc/jsdoc的なヘッダ詳細を記述できる記法もあれば尚良し
自分が必要かではなく必要な業務フローは存在するかで考えましょう
確かにJSONは1フィールドごとにラベルがつくので冗長なのでヘッダーしかつけないCSVの方が効率的ではある。
発想は嫌いではないけど（CSVの中に配列や構造化されたデータを持ちたいこともある）、そこまでやるならJSONでよくね？となる
物理計測の保存データだとキーに()や[]で単位を書く場合があり、誤動作しないか心配
方言だらけで終わってるCSVというフォーマットを更に複雑にするの勘弁しちくりーー
おもしろい。Markdownの表で使いたい書式
CSVとしてパースできるんだから今以上に複雑にする要素は何もない（CSVとの互換性を維持しているということの意味を分かっていないやつが多そう）。別に好きにすりゃいいんじゃね。両端の()を外して再帰下降すればいい
ローカルで実績積んで出直してきてほしい。
複数システム間で連携してると、データをただ横流ししてるだけの処理が挟まってることはよくある。CSVとしても扱えるなら途中の処理を変えずにすむ。標準化されてれば誰かがパーサー作ってくれるだろうし。
jsonをそのままCSVで書けて、パースしやすく、既存のCSVとの互換性もある。良さそうね。
既存の仕組みと極力ぶつからない提案してるのは面白い。ただそれで嬉しいシーンがあまり思いつかないし、CSVがテーブル状なのにテーブル設計のアンチパターンをモロに踏み抜いているよう見えてあまり好かない。
そこまでいうならexcel、、、いやなんでもない
勉強できるバカが閃いちゃった感がすごい
世界がコメントを受け入れられるJSONで統一されますように。
他を使えというのはそうなんだけど、これが欲しくなる理由わかる
こんなわかりにくい規格ならjsonでいい。CSVはシンプルで非技術者でも扱えることが利点なので、むしろデータ中のカンマやクオートの処理をスマートにする方向に進化してほしかった。
文字列に[]が入ってて意図しない挙動になる未来が見えるぞ！
開発してると一度はやりたくなるやつだ（笑）。英名と和名を同居させたりJSON文字列いれてメタデータ格納したり。個人的にはフッター行を活用する仕様が欲しい。