+json-seq

JSON text sequences

[6] JSON text sequences は、 JSON を0個以上、特殊記号で区切って並べたデータ形式です。

代替

[15] 本項の形式はほとんど実採用例がなく、特にメリットもないので、 より単純で利用例の多い改行区切りJSON列を使うべきです。

仕様書

構文

[7] RFC 7159 JSON 値の0個以上の列ですが、 JSON 値の前には RS (U+001E)、後には LF (U+000A) を必ず配置するものです。

[8] 一般的に JSON 値の列を表したい時は改行区切りにしますが、 RFC 7464 形式では改行CRLF ではなく LF 1つでなければなりませんし、 RS を入れる必要があります。一般的なエディターコピーアンドペーストによる入力では気づかないうちに CRLF を記述してしまいそうですし、 RS は入力が難しく、 表示上もあるのかどうかの判断が難しそうなので、 RFC 7464 形式は非常に取り扱いが難しそうです。 (もっとも、 CRJSON 的には空白なので、無視されて結果意図通りの解釈がされますから、あまり問題ではありません。)
[12] 元々 LF のみだったところ、提案があって RS を求めることにしたと謝辞にあります >>1LFJSON 値に含まれる可能性があるので他の区切り文字を使いたかったのでしょうが、 行長が長くなるのも嫌って LF も必須のままにしたのですかね。
[13] LF 区切りなら Unix 等の行指向ツールの入力として使いやすかったですし、 プログラミング言語の標準ライブラリー等にも大抵は LF ないし CRLF 区切りの行読み込みモードが実装されていて扱いやすそうですが、 RS が入っているしJSON値に LF が含まれる可能性があるということでそうもいきません。

MIME 型

[30] MIME型application/json-seq です >>1

[31] 構造化構文接尾辞 +json-seq が定義されています >>27

素片識別子

[32] application/json-seq素片識別子は、 規定なし >>1 となっています。

[33] +json-seq素片識別子は、他の構造化構造化接尾辞素片識別子と同形態の規定となっています >>27

批判

[18] 既に業界で広く採用例がある改行区切りのJSONと互換性のない新たな似て非なるデータ形式を、 特に利点もないのに創作するのは、混乱の元でしかありません。

[34] JSONテキストファイルで扱いやすくデバッグが容易であるのが大きな利点です。 しかし制御文字を混入させることで、そのメリットを潰してしまっています。 それをメリットと感じないのであれば、 CBOR などのバイナリー系のデータ形式の方が性能面などで優位にあり、 ストリーム可能な形式もそれをベースに設計するべきです。

歴史

[14] ongoing by Tim Bray · RFC 7464, JSON Text Sequences ( 版) <https://www.tbray.org/ongoing/When/201x/2015/02/26/JSON-Text-Sequences>

[26] 世間でよく使われているものを標準化する時に何か1つ余計な非互換変更を加えるのは、 IETF の伝統です。

[2] 対応アプリケーション例に jq がありますが、少なくても現時点で最新の正式版である 1.4 には --seq オプションは実装されていないようです。 GitHub 版には実装されているようですが、 いくつか Issues に不具合が登録されており >>3, >>4、この状態でも RFC に適合すると言えるのかどうか知りませんが、 RFC の対応アプリケーション例の筆頭 >>1 としては恥ずかしい (RFC の側が。) ように思えます。

[5] 実装が存在していなくても RFC が出版される要件は満たせるのでしょうから、 IETF としては仕様の問題ではなく実装の問題ということでどうでもいいのかもしれませんが...

[10] 対応アプリケーション例に >>9 もありますが >>1、標準で LF 区切りであるところ、オプション --rs を与えると RS が出力されるようです。

[11] RFC が変な構文にしたせいで無駄なオプションが必要になって利用者を混乱させる元になっている気がしますが・・・。

[16] enhancement: use new RFC 7464 JSON sequencing in i3bar protocol · Issue #1493 · i3/i3 ( 版) <https://github.com/i3/i3/issues/1493>

[17] ISSUE-20: Represent Collections using JSON Text Sequences (RFC 7464) - Social Web Working Group Tracker ( 版) <http://www.w3.org/Social/track/issues/20>

[19] draft-williams-json-text-sequence-00 - JavaScript Object Notation (JSON) Text Sequences ( ( 版)) <http://tools.ietf.org/html/draft-williams-json-text-sequence-00>

[20] Command Line Interface — Fiona 1.4.0 documentation ( 版) <http://toblerity.org/fiona/cli.html>

The cat command concatenates the features of one or more datasets and prints them as a JSON text sequence of features. In other words: GeoJSON feature objects, possibly pretty printed, separated by ASCII RS (x1e) chars. LF-separated sequences with no pretty printing are optionally available using --x-json-seq-no-rs.

[21] RFC 7946 - The GeoJSON Format () <https://tools.ietf.org/html/rfc7946#appendix-C>

If such a representation is needed, a new media type is required that has the ability to represent these sets or sequences. When defining such a media type, it may be useful to base it on "JavaScript Object Notation (JSON) Text Sequences" [RFC7464], leaving the foundations of how to represent multiple JSON objects to that specification, and only defining how it applies to GeoJSON objects.

[22] GeoJSON text sequences

[23] draft-wilde-json-seq-suffix-00 - A Media Type Structured Syntax Suffix for JSON Text Sequences () <https://tools.ietf.org/html/draft-wilde-json-seq-suffix-00>

[24] +json-seq should be a proper structured syntax suffix · Issue #19 · geojson/geojson-text-sequences () <https://github.com/geojson/geojson-text-sequences/issues/19>

RFC 8091

[29] には、構造化構文接尾辞 +json-seq を規定する RFC 8091 が出版されました。

[25] I-D/json-seq-suffix at master · dret/I-D () <https://github.com/dret/I-D/tree/master/json-seq-suffix>

[28] RFC 8091 - A Media Type Structured Syntax Suffix for JSON Text Sequences () <https://tools.ietf.org/html/rfc8091>