-
Notifications
You must be signed in to change notification settings - Fork 4
/
780.txt
175 lines (124 loc) · 9.11 KB
/
780.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
[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]]。
* 素片識別子
[32] [CODE(MIME)@en[application/json-seq]] の[[素片識別子]]は、
規定なし [SRC[>>1]] となっています。
[33] [CODE[+json-seq]] の[[素片識別子]]は、他の[[構造化構造化接尾辞]]の[[素片識別子]]と同形態の規定となっています
[SRC[>>27]]。
;; [[素片識別子]]参照。
* 批判
[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]