RFC 8259 クイズ

**解説:** A: RFC 8259では任意のJSON valueをtop-levelにserializeできる. B: applicationは一般的なJSON grammarより受理範囲を狭められる. C: RFC 8259はJSON syntaxを定義するがparse後のschema validationを禁止しない.

**解説:** A: object nameはuniqueであるべきでありduplicateの扱いは実装間で予測できない. B: last-winsは一般的な実装例だがRFC 8259の必須動作ではない. C: member orderではduplicate-nameの曖昧さを解消できずparserごとにorderの見え方も異なる.

**解説:** A: RFC 8259はmember orderを呼出側に見せるかがlibraryごとに異なるとする. B: encodingの選択でobject-member orderが相互運用可能なcontractになるわけではない. C: arrayはelement positionでorderを表すがobject-member orderへの依存は安全でない.

**解説:** A: RFC 8259はarray elementにsame-type要件を課さないためmixed valueもvalidである. B: arrayは異なるJSON value typeを混在でき各elementは通常のvalue grammarに従う. C: grammarは1つ以上のelementを持つarrayに加えてempty arrayも許している.

**解説:** A: NaNとInfinityはRFC 8259のnumber grammarに含まれない. B: IEEE 754実装はNaNを表現できるがJSON syntaxは許さない. C: NaNはlowercaseのnull literalでも他のJSON literalでもない.

**解説:** A: number notationを変えてもbinary64のexact integer range外の値はexactにならない. B: JSONにはcomment syntaxがなくnumeric precisionの問題も残る. C: stringならnumeric roundingを避けてapplicationがidentifier syntaxを定義できる.

**解説:** A: RFC 8259はclosed ecosystem外で交換するJSONにUTF-8を要求する. B: network上のJSONはUTF-8を使いgeneratorはBOMを付けてはならない. C: member orderはencoding negotiation signalを持たない.

**解説:** A: 異なるescape表記でも同じstring valueをencodeできる. B: string equalityはobject内のmember positionに依存しない. C: RFC 8259はtextual representationを変換した後のcode-unit比較を示す.

**解説:** A: RFC 8259はこのdataでlengthやvalueの不一致やruntime failureまで起こりうるとする. B: RFC 8259は共通のreplacement procedureを定義しない. C: lone surrogateをencodeしてもUnicode scalar valueにはならない.

**解説:** A: checkが遅いとhostile inputが先にparserとapplication resourceを消費する. B: RFC 8259はsizeとdepthのlimitを許しearly enforcementでresource useを制限できる. C: parserはtext sizeとmaximum nesting depthにlimitを設けられる.