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

;; [35] [[改行区切りのJSON]]とは異なる形式ですが、
混同されていることもあり、要注意です。

* 代替

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

* 仕様書

[REFS[
- [1] '''[CITE@en[RFC 7464 - JavaScript Object Notation (JSON) Text Sequences]] ([TIME[2015-02-26 08:31:19 +09:00]] 版) <https://tools.ietf.org/html/rfc7464>'''
- [27] [CITE@en[RFC 8091 - A Media Type Structured Syntax Suffix for JSON Text Sequences]] ([TIME[2017-02-23 00:58:07 +09:00]]) <https://tools.ietf.org/html/rfc8091>
]REFS]

* 構文

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

;; [8] 一般的に [[JSON]] 値の列を表したい時は[[改行]]区切りにしますが、 [[RFC 7464]]
形式では[[改行]]は [[CRLF]] ではなく [[LF]] 1つでなければなりませんし、
[CODE(charname)@en[[[RS]]]] を入れる必要があります。一般的な[[エディター]]や[[コピーアンドペースト]]による入力では気づかないうちに
[[CRLF]] を記述してしまいそうですし、 [CODE(charname)@en[[[RS]]]] は入力が難しく、
表示上もあるのかどうかの判断が難しそうなので、 [[RFC 7464]] 形式は非常に取り扱いが難しそうです。
(もっとも、 [[CR]] は [[JSON]] 的には[[空白]]なので、無視されて結果意図通りの解釈がされますから、あまり問題ではありません。)

;; [12] 元々 [[LF]] のみだったところ、提案があって [CODE(charname)@en[[[RS]]]]
を求めることにしたと謝辞にあります [SRC[>>1]]。 [CODE(charname)@en[[[LF]]]]
は [[JSON]] 値に含まれる可能性があるので他の区切り文字を使いたかったのでしょうが、
行長が長くなるのも嫌って [[LF]] も必須のままにしたのですかね。

;; [13] [[LF]] 区切りなら [[Unix]] 等の行指向ツールの入力として使いやすかったですし、
プログラミング言語の標準ライブラリー等にも大抵は [[LF]] ないし [[CRLF]]
区切りの行読み込みモードが実装されていて扱いやすそうですが、 
[CODE(charname)@en[[[RS]]]] が入っているし[[JSON]]値に [CODE(charname)@en[[[LF]]]]
が含まれる可能性があるということでそうもいきません。

* MIME 型

[30] [[MIME型]]は [DFN[[CODE(MIME)@en[[[application/json-seq]]]]]] 
です [SRC[>>1]]。

-*-*-

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

[38] 
[CODE[application/city+json-seq]]
は、
[[JSON Text Sequences]] ではなく [[NDJSON]] であるにも関わらず、
[[IANA]] に登録されています。

;; [39] この杜撰さが安定の [[IETF]] [[クオリティー]]w



* 素片識別子

[32] [CODE(MIME)@en[application/json-seq]] の[[素片識別子]]は、
規定なし [SRC[>>1]] となっています。

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

* 文脈

[37] 
[[改行区切りJSON列]]同様、
[[JSONストリーミング]]に用いることが想定されているようです。

* 批判

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

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

* 歴史

[14] [CITE@en[ongoing by Tim Bray · RFC 7464, JSON Text Sequences]]
([TIME[2015-03-05 05:22:02 +09:00]] 版)
<https://www.tbray.org/ongoing/When/201x/2015/02/26/JSON-Text-Sequences>

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

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

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

[REFS[
- [3] [CITE@en[Add --seq-strict or similar · Issue #654 · stedolan/jq]] ([TIME[2015-03-13 18:58:47 +09:00]] 版) <https://github.com/stedolan/jq/issues/654>
- [4] [CITE@en[Sequence parser does not require first text to start with RS · Issue #687 · stedolan/jq]] ([TIME[2015-03-13 18:59:06 +09:00]] 版) <https://github.com/stedolan/jq/issues/687>
]REFS]

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

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

[REFS[
-[9] [CITE@en[mapbox/cligj]] ([TIME[2015-03-13 19:07:42 +09:00]] 版) <https://github.com/mapbox/cligj>
]REFS]


[16] [CITE@en[enhancement: use new RFC 7464 JSON sequencing in i3bar protocol · Issue #1493 · i3/i3]]
([TIME[2015-06-10 01:07:50 +09:00]] 版)
<https://github.com/i3/i3/issues/1493>

[17] [CITE@en[ISSUE-20: Represent Collections using JSON Text Sequences (RFC 7464) - Social Web Working Group Tracker]]
([TIME[2015-06-10 01:13:38 +09:00]] 版)
<http://www.w3.org/Social/track/issues/20>

[19] [CITE@en[draft-williams-json-text-sequence-00 - JavaScript Object Notation (JSON) Text Sequences]]
( ([TIME[2014-03-15 10:59:11 +09:00]] 版))
<http://tools.ietf.org/html/draft-williams-json-text-sequence-00>

[FIG(quote)[
[FIGCAPTION[
[20] [CITE[Command Line Interface — Fiona 1.4.0 documentation]]
([TIME[2014-09-23 05:12:40 +09:00]] 版)
<http://toblerity.org/fiona/cli.html>
]FIGCAPTION]

> 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.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[21] [CITE@en[RFC 7946 - The GeoJSON Format]]
([TIME[2016-08-19 22:23:34 +09:00]])
<https://tools.ietf.org/html/rfc7946#appendix-C>
]FIGCAPTION]

>  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.

]FIG]

[22] [[GeoJSON text sequences]]

[23] [CITE@en[draft-wilde-json-seq-suffix-00 - A Media Type Structured Syntax Suffix for JSON Text Sequences]]
([TIME[2016-10-08 22:04:42 +09:00]])
<https://tools.ietf.org/html/draft-wilde-json-seq-suffix-00>

[24] [CITE@en[+json-seq should be a proper structured syntax suffix · Issue #19 · geojson/geojson-text-sequences]]
([TIME[2016-10-21 12:36:59 +09:00]])
<https://github.com/geojson/geojson-text-sequences/issues/19>

** RFC 8091

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

[25] [CITE@en[I-D/json-seq-suffix at master · dret/I-D]]
([TIME[2016-10-21 12:37:10 +09:00]])
<https://github.com/dret/I-D/tree/master/json-seq-suffix>

[28] [CITE@en[RFC 8091 - A Media Type Structured Syntax Suffix for JSON Text Sequences]] ([TIME[2017-02-23 00:58:07 +09:00]]) <https://tools.ietf.org/html/rfc8091>


[FIG(quote)[
[FIGCAPTION[
[36] [CITE@en[GeoJSONSeq: sequence of GeoJSON features — GDAL documentation]]
([TIME[2021-12-08T15:14:16.000Z]], [TIME[2021-12-09T05:18:16.075Z]])
<https://gdal.org/drivers/vector/geojsonseq.html>
]FIGCAPTION]

> 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”

]FIG]


* メモ

[40] 
やっぱり [[RFC]] になることのネームバリューというのはあるみたいで、
いくつか実装例はあるみたいですね。 [[GitHub]] で検索すると何個か出てきます。

[41] 
でもあまり積極的に使ってそうな事例は見つからないというか、どうしてもほしいという要望とか、
使ったら不具合がありましたという報告とか、頻繁な機能追加や不具合修正などが行われている形跡はなく。
実装したらそれで終わりって感じのばかりで。実装も、リポジトリーにテストデータが揃っているものが皆無で、
ろくに動作確認もされてないのではないかという疑惑が...





[42] どこかに実利用例のファイルが無いかなあと探してみたんだけどどこにもない・・・ [TIME[2025-11-28T02:48:42.537Z]]

[43] 実装の動作確認用のファイルすらみつからない (テストスクリプトに組み込まれた数バイトくらいのは見つかったが・・・) [TIME[2025-11-28T02:49:10.797Z]]

[44] 使ってる人はどこにいるの?? [TIME[2025-11-28T02:49:42.080Z]]