[6] JSON text sequences
は、 JSON を0個以上、特殊記号
RS で区切って並べたデータ形式です。
[15] 本項の形式はほとんど実採用例がなく、特にメリットもないので、 より単純で利用例の多い改行区切りJSON列を使うべきです。
[7] RFC 7159 JSON 値の0個以上の列ですが、 JSON 値の前には
RS (U+001E)、後には
LF (U+000A) を必ず配置するものです。
RS を入れる必要があります。一般的なエディターやコピーアンドペーストによる入力では気づかないうちに
CRLF を記述してしまいそうですし、 RS は入力が難しく、
表示上もあるのかどうかの判断が難しそうなので、 RFC 7464 形式は非常に取り扱いが難しそうです。
(もっとも、 CR は JSON 的には空白なので、無視されて結果意図通りの解釈がされますから、あまり問題ではありません。)[30] MIME型は application/json-seq
です >>1。
[32] application/json-seq の素片識別子は、
規定なし >>1 となっています。
[33] +json-seq の素片識別子は、他の構造化構造化接尾辞の素片識別子と同形態の規定となっています
>>27。
[37] 改行区切りJSON列同様、 JSONストリーミングに用いることが想定されているようです。
[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 の側が。) ように思えます。
[10] 対応アプリケーション例に >>9 もありますが >>1、標準で LF
区切りであるところ、オプション --rs を与えると RS が出力されるようです。
[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
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.
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.
[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
[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
RS=YES/NO: whether to start records with the RS=0x1E character, so as to be compatible with the RFC 8142 standard. Defaults to NO, unless the filename extension is “geojsons”