The JavaScript Object eXchange (JSOX) Data Interchange Format

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

JavaScript Object eXchange (JSOX) is a text format for the serialization of structured data. It is derived from JSON [RFC8259] and from the object literal syntax of the ECMAScript Programming Language Standard [ECMA-262].¶

A JSOX parser accepts every text that a JSON parser accepts, and assigns it the same meaning. The converse does not hold: a JSOX generator can produce texts that a JSON parser will reject.¶

JSOX's design goals were to extend JSON with features that improve clarity for human authors and reduce redundancy for machine-generated documents, while keeping JSON's original goals of being minimal, portable, and textual. Specifically, JSOX adds:¶

• representation of the ECMAScript Date and BigInt types without application-level conventions;¶

• representation of ArrayBuffer and the twelve TypedArray classes as base 64 data carried by a type tag;¶

• a type tag on objects, arrays, and strings, so that a receiver can revive application types directly;¶

• field-name macros, which declare a set of field names once and then carry only values for each subsequent object of that shape;¶

• references, which allow a value to name another value already present in the same text, so that shared and cyclic object graphs survive a round trip;¶

• comments, unquoted object keys, and the additional string and number forms of ECMAScript.¶

All of these features are optional. A JSOX text that uses none of them is a JSON text.¶

A JSOX value is a primitive type (string, number, boolean, date, arbitrary-precision integer, or binary array), a structured type (object or array), or one of the two placeholder values null and undefined.¶

A string is a sequence of zero or more Unicode characters [UNICODE]. Note that this citation references the latest version of Unicode rather than a specific release.¶

Many strings do not need quotation marks, and JSOX lets those be written without them. This is not a separate kind of token: an unquoted string is a string, and it may appear anywhere a string may appear. It may be an object member name, a type tag, or a value in its own right, so {a:b} and {"a":"b"} denote the same object. Where this document says "identifier", it means a string in a position where a name is expected; the rules for when quotes may be omitted are the same in every position, and are given in Section 3.2.¶

An object is a collection of zero or more name/value pairs, where a name is a string. An array is an ordered sequence of zero or more values.¶

The terms "object" and "array" come from the conventions of ECMAScript. The term "class" is used in the general sense of a set of values that share a common structure and are distinguished from other values by that structure.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The grammatical rules in this document are to be interpreted as described in ABNF [RFC5234], with the extension that numeric values above %xFF denote Unicode scalar values rather than octets, as is done in [RFC8259].¶

Angle-bracketed prose values are used where a rule is more clearly stated in English than in ABNF.¶

The grammar describes the text after comments have been removed (Section 3.1). Comments are therefore absent from every rule below, including ws, and a comment may appear at any point that is not inside a quoted string.¶

The number rules of Section 7 are the one place where the ABNF is deliberately looser than the language. A number is recognized by a closed set of characters, and several of its forms -- dates in particular -- are then constrained by prose and by the references rather than by the grammar. Where the two disagree, the prose governs.¶

3. JSOX Grammar

A JSOX text is a sequence of tokens. The set of tokens includes six structural characters, identifiers, strings, numbers, and six literal names.¶

A JSOX text is a single serialized value, optionally preceded by one or more macro definitions (Section 9.3).¶

JSOX-text = ws *( macro-definition ws ) value ws

These are the six structural characters:¶

begin-array     = ws %x5B ws  ; [ left square bracket
begin-object    = ws %x7B ws  ; { left curly bracket
end-array       = ws %x5D ws  ; ] right square bracket
end-object      = ws %x7D ws  ; } right curly bracket
name-separator  = ws %x3A ws  ; : colon
value-separator = ws %x2C ws  ; , comma

Two additional rules are used in the places where a structural character MUST NOT be preceded by whitespace: after the tag of a macro definition (Section 9.3), and after the tag of a typed value at the top level (Section 9).¶

open-object     = %x7B ws     ; { with no preceding whitespace
open-array      = %x5B ws     ; [ with no preceding whitespace

ws = *(
        %x09 /              ; Horizontal tab
        %x0A /              ; Line feed or New line
        %x0D /              ; Carriage return
        %x20 /              ; Space
        %x2028 /            ; U+2028 Line separator
        %x2029 /            ; U+2029 Paragraph separator
        %xFEFF )            ; U+FEFF Zero width no-break space

comment       = line-comment / block-comment

line-comment  = ( %x2F.2F / %x23 )
                *( %x00-09 / %x0B-0C / %x0E-2027 /
                   %x202A-10FFFF )
                ; "//" or "#" up to but not including the next
                ; %x0A, %x0D, %x2028 or %x2029

block-comment = %x2F.2A <any sequence of characters that does not
                contain the two-character sequence "*/"> %x2A.2F
                ; "/*" ... "*/"

string          = quoted-string / unquoted-string

identifier      = string

unquoted-string = id-begin *id-char

id-begin = <any id-char that is not DIGIT, "+", "-", or ".">

id-char  = <any Unicode scalar value that is not matched by ws, is
            not a structural character, is not a quotation-mark,
            and is not "#"; and "/" only where the character that
            follows it is neither "/" nor "*">

4. Values

A JSOX value MUST be an object, an array, a number, a string, a typed value, or one of the following six literal names:¶

false null true Infinity NaN undefined

The literal names MUST be lowercase except as spelled here, and MUST match exactly. No other literal names are allowed.¶

value = false / null / true / undefined / NaN / Infinity
      / number / string / object / array / typed-value

false     = %x66.61.6c.73.65             ; false
null      = %x6e.75.6c.6c                ; null
true      = %x74.72.75.65                ; true
undefined = %x75.6e.64.65.66.69.6e.65.64 ; undefined
NaN       = [ minus / plus ] %x4e.61.4e  ; [-]NaN
Infinity  = [ minus / plus ]
            %x49.6e.66.69.6e.69.74.79    ; [-]Infinity

The alternatives of value are ordered: a token is tested against the six literal names first, then as a number, and only then as a string. Because string includes unquoted-string (Section 3.2), a bare word such as hello is a value -- a string -- and not an error.¶

-NaN and +NaN are accepted and denote the same value as NaN.¶

undefined denotes the absence of a value. A member whose value is undefined is equivalent to a member that is not present, and a generator MAY omit such a member. Receivers that have no representation for undefined SHOULD treat it as null.¶

5. Objects

An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is an identifier. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique.¶

object = begin-object
         [ member *( value-separator member )
           [ value-separator ] ]
         end-object

member = identifier name-separator value

A single trailing comma is permitted after the last member and has no effect. More than one consecutive comma between members is an error.¶

An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates.¶

JSOX parsing libraries MAY differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.¶

6. Arrays

An array structure is represented as square brackets surrounding zero or more values (or elements). Elements are separated by commas.¶

array   = begin-array
          [ element *( value-separator element ) ]
          end-array

element = ws [ value ] ws

There is no requirement that the values in an array be of the same type.¶

An element MAY be empty, in which case the array has a member at that position whose value is undefined. Consecutive commas therefore produce elisions: [1,,3] is an array of three elements whose second element is undefined. A single trailing comma does not add an element; [1,2,] and [1,2] denote the same array, while [1,2,,] denotes an array of three elements.¶

7. Numbers

The representation of numbers is similar to that used in most programming languages, and follows [ECMA-262]. A number is represented in base 10 unless a radix prefix selects another base. It contains an integer component that may be prefixed with an optional sign, which may be followed by a fraction part and/or an exponent part.¶

Four further forms are recognized that JSON does not have: radix numbers, arbitrary-precision integers, dates (Section 7.2), and the non-finite literals NaN and Infinity (Section 4).¶

number        = plain-number / radix-number / bigint / date

plain-number  = [ sign ] ( int [ frac ] / frac ) [ exp ]

radix-number  = [ sign ] zero radix 1*radix-digit

bigint        = [ sign ] int bigint-suffix

sign          = plus / minus

int           = DIGIT *DIGIT

frac          = decimal-point *DIGIT

exp           = e [ sign ] 1*DIGIT

decimal-point = %x2E                ; .

e             = %x65 / %x45         ; e E

minus         = %x2D                ; -

plus          = %x2B                ; +

zero          = %x30                ; 0

radix         = %x58 / %x78         ; X x  -- hexadecimal
              / %x4F / %x6F         ; O o  -- octal
              / %x42 / %x62         ; B b  -- binary

radix-digit   = DIGIT / %x41-46 / %x61-66
                ; restricted to the digits of the selected radix

bigint-suffix = %x6E                ; n

underscore    = %x5F                ; _

A number begins with a digit, +, -, or .. Once a number has started, only the characters named by the rules above may follow, and all of them are below U+0080.¶

A fraction part is a decimal point followed by zero or more digits, so both a leading and a trailing decimal point are permitted: .5 and 1. are valid numbers denoting 0.5 and 1.¶

An exponent part begins with the letter E in upper or lower case, which may be followed by a plus or minus sign. The E and optional sign are followed by one or more digits.¶

Unlike JSON, leading zeros are permitted in a decimal number and do not change its value: 0123 denotes 123. A base other than 10 MUST be selected with an explicit radix prefix.¶

Earlier descriptions of JSOX followed C in reading a leading zero as selecting octal, so that 0123 denoted 83. That reading is deprecated. Implementations MUST NOT interpret a leading zero as selecting octal, and MUST use the 0o prefix to write an octal number. Generators SHOULD avoid emitting a leading zero at all, since a reader familiar with C may misread it.¶

Only one sign may appear, and it MUST be the first character. A sequence such as ----123 is an error.¶

An underscore (_) MAY appear anywhere within a number, including before or after the decimal point and at the end. It is treated as a zero-width separator: it is not stored and does not modify the value. 1_000_000 and 1000000 denote the same number. Note that a leading underscore does not begin a number; it begins a string.¶

_ is the only non-breaking separator a number has. U+00A0 NO-BREAK SPACE, which joins characters into a single string elsewhere (Section 3.2.1), terminates a number instead: every character of a number is below U+0080, so U+00A0 cannot be part of one. 1234<NBSP> is the number 1234, and 12<NBSP>34 is two numbers -- allowed at the top level of a stream, and an error in a bounded context (Section 3.2.2).¶

This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSOX numbers within the expected precision. A JSOX number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.¶

Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values.¶

date        = [ sign ] 1*DIGIT time-symbol
              *( DIGIT / time-symbol )

time-symbol = %x54 / %x5A           ; T Z
            / %x2B / %x2D / %x3A    ; + - :

8. Quoted Strings

This section defines the quoted form of a string. The unquoted form, and the relationship between the two, are defined in Section 3.2.¶

The representation of quoted strings follows the conventions of [ECMA-262]. A quoted string begins and ends with a quotation mark. Three quotation marks are available: U+0022 QUOTATION MARK, U+0027 APOSTROPHE, and U+0060 GRAVE ACCENT. The closing quotation mark MUST be the same character as the opening quotation mark. No template substitution is performed inside a grave-accent-quoted string; the grave accent is a third quotation mark and nothing more.¶

All Unicode characters may be placed within the quotation marks, except for the quotation mark used to open the string and the reverse solidus, which MUST be escaped. The other two quotation marks need not be escaped.¶

A string MAY span more than one line. Every character between the opening and the closing quotation mark is retained, including line terminators. To continue a string onto the next line without including the line terminator in its value, escape the line terminator with a reverse solidus.¶

quoted-string   = quotation-mark *char quotation-mark
                  ; the closing mark is the same character as
                  ; the opening mark

quotation-mark  = %x22 / %x27 / %x60   ; " ' `

char            = unescaped / escape escape-sequence

escape          = %x5C                 ; \

escape-sequence = %x22 /               ; "  quotation mark
                  %x27 /               ; '  quotation mark
                  %x60 /               ; `  quotation mark
                  %x5C /               ; \  reverse solidus
                  %x2F /               ; /  solidus
                  %x62 /               ; b  backspace  U+0008
                  %x66 /               ; f  form feed  U+000C
                  %x6E /               ; n  line feed  U+000A
                  %x72 /               ; r  carriage return
                  %x74 /               ; t  tab        U+0009
                  %x76 /               ; v  vert. tab  U+000B
                  %x78 2HEXDIG /       ; xXX
                  %x30-32 2OCTDIG /    ; 0NN  octal, U+0000-U+00FF
                  %x75 4HEXDIG /       ; uXXXX
                  %x75 %x7B 1*HEXDIG %x7D /
                                       ; u{XXXXXX}
                  %x0A / %x0D /        ; line continuation
                  %x2028 / %x2029

unescaped       = <any Unicode scalar value other than the
                   quotation mark that opened this string and
                   %x5C reverse solidus>

OCTDIG          = %x30-37              ; 0-7

Any character may be escaped. If the character is in the Basic Multilingual Plane (U+0000 through U+FFFF), then it may be represented as a six-character sequence: a reverse solidus, followed by the lowercase letter u, followed by four hexadecimal digits that encode the character's code point. The hexadecimal letters A through F can be upper or lower case.¶

A character whose code point is below U+0100 may also be written as \x followed by two hexadecimal digits, or as \0 followed by two octal digits.¶

A character at any code point may be written as \u{ followed by one or more hexadecimal digits and }.¶

Alternatively, there are two-character sequence escape representations of some popular characters. So, for example, a string containing only a single reverse solidus character may be written as the four characters "\\".¶

To escape an extended character that is not in the Basic Multilingual Plane using the four-digit form, the character is represented as a 12-character sequence encoding the UTF-16 surrogate pair. So, for example, a string containing only the G clef character (U+1D11E) may be represented as "𝄞", or equivalently as "\u{1D11E}".¶

An escape sequence that is not listed above is an error. Note in particular that a reverse solidus followed by a decimal digit other than 0, 1, or 2 is reserved and MUST NOT be generated.¶

9. Typed Values

A typed value is a value that carries a type tag: an identifier that names an application type, immediately followed by the value's representation. A receiver that recognizes the tag may revive the value as an instance of that type; a receiver that does not recognize the tag MUST still be able to parse the value, and SHOULD make the tag and the underlying value available to the application.¶

typed-value  = typed-object / typed-array / typed-string
             / macro-reference

typed-object = identifier begin-object
               [ member *( value-separator member )
                 [ value-separator ] ]
               end-object

typed-array  = identifier begin-array
               [ element *( value-separator element ) ]
               end-array

typed-string = identifier ws quoted-string

The ws these three rules admit before the value is permitted only in a bounded context. At the top level it MUST be absent, so that open-object and open-array apply and a typed string's quotation mark is adjacent to its tag. See below.¶

Whether whitespace may separate the tag from the value it carries depends on the surrounding context, as described in Section 3.2.2.¶

In a bounded context -- inside an object or an array -- whitespace MAY appear between the tag and the {, [, or quotation mark that follows it. The enclosing } or ] and the , and : separators already mark where each value ends, so nothing is made ambiguous by the gap. [ab"cd"] and [ab "cd"] both denote an array of one string, cd, tagged ab.¶

A comment between the two does not arise as a separate case: it is removed before tokenizing (Section 3.1), so [ab/*x*/"cd"] is [ab"cd"] and the tag is adjacent after all. This is why the restriction below can be stated in terms of whitespace alone.¶

In an unbounded context -- the top level of a text or of a stream -- the tag MUST be adjacent to its value, with no whitespace between them. Nothing there marks where a value ends, so a complete value ends at its last character: "abc" {a:1} is two values, and "abc"{a:1} is one tagged value.¶

A generator SHOULD NOT emit whitespace between a tag and its value in either context, since output written that way is valid in only one of them.¶

A tag is a string (Section 3.2), so it may be quoted. Quoting is what allows a tag to contain a character that unquoted-string does not admit; "o:1"{a:1} is a typed object whose tag is the three- character name o:1. A quoted tag names an application type in exactly the same way an unquoted one does, and carries no other meaning: the colon in o:1 is part of the name, and does not make the tag a name/value pair.¶

A typed string is exactly two strings: the tag and the value. A third adjacent string matches no rule and is an error. "a""b" is the string b tagged a -- the same construct as color"#333", with the tag quoted -- while "a""b""c" is not a JSOX text.¶

Because a quoted string is self-delimiting, a typed string at the top level of a text MUST use an unquoted tag; otherwise the tag would be read as a complete string value in its own right. This restriction applies only to typed strings, since { and [ are unambiguous after a closing quotation mark.¶

A tag that the receiver has not registered does not make the text invalid. The value is parsed normally and the tag is reported to the application; see Section 14.¶

binary-array = array-type open-array [ base64-data ] end-array

array-type   = "ab" / "u8" / "cu8" / "s8" / "u16" / "s16"
             / "u32" / "s32" / "f32" / "f64"

reference = "ref" open-array
            [ ref-step *( value-separator ref-step ) ]
            end-array

ref-step  = string / int

macro-definition = identifier open-object
                   identifier *( value-separator identifier )
                   end-object

macro-reference  = identifier open-object
                   [ element *( value-separator element ) ]
                   end-object

10. String and Character Issues

11. Base 64 Encoding

The binary typed arrays of Section 9.1 carry their octets as base 64 data. JSOX uses the alphabet below rather than the alphabets of [RFC4648], because the two characters it selects for values 62 and 63 are permitted in an unquoted identifier and so require no quoting:¶

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789$_

Generators MUST use this alphabet.¶

For interoperability with data produced by other base 64 implementations, parsers MUST additionally accept the following characters on input:¶

Note that +, -, ., /, and , require quoting when they appear in a value that is otherwise an unquoted identifier, and that , and / are ambiguous inside an array; a parser reading base 64 data between [ and ] reads to the closing bracket and so is not affected, but a generator MUST NOT emit these characters.¶

Padding is not required. A = or ~ character terminates the data. Trailing bits that do not complete an octet MUST be zero and MUST be discarded.¶

12. Parsers

A JSOX parser transforms a JSOX text into another representation. A JSOX parser MUST accept all texts that conform to the JSOX grammar. A JSOX parser MAY accept non-JSOX forms or extensions.¶

An implementation may set limits on the size of texts that it accepts, on the maximum depth of nesting, on the range and precision of numbers, on the length and character contents of strings, and on the number of macro and type tags it will track. See Section 14.¶

13. Generators

A JSOX generator produces JSOX text. The resulting text MUST strictly conform to the JSOX grammar.¶

A generator that is asked to produce a value that has no JSOX representation, such as a function, MUST either omit it or report an error, and MUST NOT emit an approximation that would parse as a different value.¶

14. Security Considerations

Generally, there are security issues with scripting languages. JSOX is a subset of ECMAScript that excludes code expressions, so a JSOX text cannot by itself cause code to run.¶

However, JSOX's syntax deviates from ECMAScript for type tags, macro definitions, and references. It is therefore not generally possible to use a scripting language's eval() function to parse a JSOX text, and implementations MUST NOT do so. A subset of JSOX texts -- those that use no type tag, macro, reference, date, or binary array -- would be accepted by eval(), but an implementation cannot know that a text is in that subset without first parsing it. Using eval() on data from an untrusted source allows arbitrary code execution.¶

Reviving application types from a type tag is a deserialization primitive, and carries the risks common to such primitives. A receiver MUST NOT construct an arbitrary type named by an incoming tag. It SHOULD revive only types that the application has explicitly registered, and it MUST treat the values supplied for a revived type as untrusted input, validating them exactly as it would validate the same values arriving in a plain object. A tag that has not been registered MUST NOT cause any application code to run.¶

References (Section 9.2) let a text name values elsewhere in itself. Two hazards follow. First, a reference can create a cyclic structure; software that walks a parsed JSOX value without tracking which objects it has already visited will not terminate. Receivers that pass parsed values to code expecting a tree -- including code that re-serializes them -- MUST detect cycles. Second, a small text can name the same large substructure many times, so the size of the parsed value is not bounded by the size of the text. Implementations SHOULD bound the number of references they will resolve.¶

Macros (Section 9.3) and type tags accumulate state for the lifetime of a stream. An attacker who can write to a long-lived stream can define tags without limit. Implementations SHOULD bound the number of definitions they will retain.¶

Binary typed arrays (Section 9.1) allow a text to request an allocation whose size is proportional to the length of the base 64 data. This is a bounded expansion, but implementations SHOULD still apply a limit on allocation size.¶

Arbitrary-precision integers are unbounded in length. Implementations SHOULD limit the length of such a number, since arithmetic on very large integers can consume disproportionate time.¶

Because JSOX permits comments and several equivalent spellings of the same value -- three quotation marks, several escape forms, several number bases, underscores in numbers, macros -- two texts that denote the same value may differ. JSOX is therefore not suitable as-is for applications that require a canonical form, such as computing a signature over serialized data. Such applications MUST define their own canonicalization, or sign the octets received rather than a re-serialization of them.¶

Implementations SHOULD apply limits on nesting depth, text size, string length, and number magnitude. A parser that recurses per level of nesting can be made to exhaust its stack by a text consisting only of open brackets.¶

A stream of JSON or JSOX texts may generate the sequence ][ where two adjacent array values meet. Software that scans for such sequences must not treat them as significant.¶

15. IANA Considerations

IANA is requested to register the media type "application/jsox" in the "Media Types" registry, using the template below and following the procedures of [RFC6838].¶

Type name:

application¶

Subtype name:

jsox¶

Required parameters:

N/A¶

Optional parameters:

N/A. No "charset" parameter is defined for this registration. Adding one has no effect on compliant recipients; see Section 10.1.¶

Encoding considerations:

binary¶

Security considerations:

See Section 14 of RFC XXXX.¶

Interoperability considerations:

See Section 1, Section 7, and Section 10.1 of RFC XXXX.¶

Published specification:

RFC XXXX¶

Applications that use this media type:

JSOX has been used to exchange data between applications written in C, C++, and JavaScript.¶

Fragment identifier considerations:

N/A¶

Additional information:

Deprecated alias names for this type: N/A¶

Magic number(s): N/A¶

File extension(s): .jsox¶

Macintosh file type code(s): TEXT¶

Person & email address to contact for further information:

James Buckeyne james.buckeyne@gmail.com¶

Intended usage:

COMMON¶

Restrictions on usage:

None¶

Author:

James Buckeyne james.buckeyne@gmail.com¶

Change controller:

James Buckeyne james.buckeyne@gmail.com¶

RFC Editor: please replace XXXX above with the RFC number assigned to this document, and remove this paragraph.¶

16. Examples

This is a JSOX object, and also a JSON object:¶

{
  "Image": {
    "Width":  800,
    "Height": 600,
    "Title":  "View from 15th Floor",
    "Thumbnail": {
      "Url":    "http://www.example.com/image/481989943",
      "Height": 125,
      "Width":  100
    },
    "Animated": false,
    "IDs": [116, 943, 234, 38793]
  }
}

Its Image member is an object whose Thumbnail member is an object and whose IDs member is an array of numbers.¶

This is a JSOX array containing two objects. It uses unquoted member names, dates, arbitrary-precision integers, binary arrays, and both comment forms:¶

[
  {
     "precision": "zip",
     "ident":     123594985n,
     "Latitude":  37.7668,
     "Longitude": -122.3959,
     created:     2018-09-11T03:43:53.345-07:00,
     binary:      u8[U2VjcmV0],   /* Secret */
     Address:     "",
     City:        "SAN FRANCISCO",
     State:       "CA",
     Zip:         "94107",
     Country:     "US"
  },
  {
     precision:   "zip",
     "ident":     123594986n,
     Latitude:    37.371991,
     "Longitude": -122.026020,
     created:     2018-09-11T10:43:52.437Z,
     "binary":    u8[SGVsbG8sIFdvcmxkIQ],   // Hello, World!
     "Address":   "",
     City:        "SUNNYVALE",
     "State":     "CA",
     Zip:         "94085",
     "Country":   "US"
  }
]

The same data, using a macro to declare the member names once:¶

locale{ precision,ident,Latitude,Longitude,
        created,binary,Address,City,State,Zip,Country}
[ locale{ "zip",123594985n,37.7668,-122.3959,
          2018-09-11T03:43:53.345-07:00,
          u8[U2VjcmV0],
          "","SAN FRANCISCO","CA","94107","US"},
  locale{ "zip",123594986n,37.371991,-122.026020,
          2018-09-11T10:43:52.437Z,
          u8[SGVsbG8sIFdvcmxkIQ],
          "","SUNNYVALE","CA","94085","US"}
]

Once defined, the macro remains in effect for later values in the same stream:¶

locale{ "zip",123594988n,36.1699,-115.1398,
        2018-09-11T13:23:23.636Z,
        u8[SGVsbG8sIFdvcmxkIQ],
        "","LAS VEGAS","NV","89109","US"}

This is an example of a reference. The manager member and the first element of the employees array denote the same object:¶

{
   company: { name: "Example.com",
              employees: [ { name:"bob" }, { name:"tom" } ],
              manager: ref["company","employees",0]
            }
}

Here are several small JSOX texts containing only values:¶

"Hello world!"
42
123n
true
Infinity
2018-09-11T13:23:23.636Z

17. References

Changes from JSON

This appendix summarizes, without normative force, how JSOX differs from JSON [RFC8259]. Every one of these constructs is optional; a JSOX text that uses none of them is a JSON text.¶

Additions taken from JSON5 [JSON5] and JSON6 [JSON6]:¶

• Object member names may be unquoted (Section 3.2).¶

• Strings may be quoted with ' or ` as well as ", may span lines, and accept the full set of ECMAScript escapes (Section 8).¶

• Numbers may be hexadecimal, octal, or binary; may have leading zeros, a leading or trailing decimal point, a leading plus sign, or underscore separators; and may be NaN or Infinity (Section 7).¶

• Objects and arrays may have a trailing comma, and arrays may have elisions (Section 5, Section 6).¶

• undefined is a literal name (Section 4).¶

• Line and block comments are removed before tokenizing (Section 3.1).¶

Additions specific to JSOX:¶

• Dates are written unquoted, as a form of number (Section 7.2).¶

• Arbitrary-precision integers are written with an n suffix (Section 7).¶

• Binary buffers and typed arrays are written as base 64 data carried by a reserved tag (Section 9.1).¶

• Objects, arrays, and strings may carry a type tag so that a receiver can revive an application type (Section 9).¶

• Macros declare a set of member names once and then carry only values (Section 9.3).¶

• References allow shared and cyclic structures to be encoded (Section 9.2).¶

• # introduces a line comment (Section 3.1).¶

• A string may be unquoted in value position as well as in a member name (Section 3.2).¶

One earlier JSOX behavior has been withdrawn: a leading zero once selected octal, as it does in C. That reading is deprecated, and a leading zero now denotes a decimal number. Octal is written with the 0o prefix (Section 7).¶

Acknowledgments

RFC 4627 [RFC4627] was written by Douglas Crockford, and was revised as RFC 7159 and then RFC 8259 [RFC8259] by Tim Bray. This document reuses a substantial amount of text from those documents, particularly in the descriptions of objects, arrays, numbers, strings, and character encoding. The debt is gratefully acknowledged.¶

The relaxations of JSON's punctuation, string, and number syntax adopted here were developed by the JSON5 [JSON5] and JSON6 [JSON6] communities.¶

Author's Address