# JSON Stats Analyzer

Juan Cruz Viotti
Department of Computer Science
University of Oxford
Oxford, GB OX1 3QD
<EMAIL_ADDRESS>
https://www.jviotti.com Mital Kinderkhedia
Department of Computer Science
University of Oxford
Oxford, GB OX1 3QD
<EMAIL_ADDRESS>

###### Abstract

In this paper, we present the JSON Stats Analyzer, a free-to-use open-source
web-based JavaScript tool and module that provides JSON document analysis. We
explain how the JSON Stats Analyzer works, its usage alongside the
demonstration of eleven JSON documents from Tier 1, Tier 2 and Tier 3 from our
proposed taxonomy that categorizes JSON documents according to their size,
content, redundancy and nesting characteristics. For each JSON document, we
provide its definition, characteristics and the document structure, alongside
a visual representation of the JSON document structure and its summary
statistics.

##  1 Motivation

To the best of our knowledge, there are gaps in the current literature that
prevents a sound understanding of JSON [4] documents at a higher level that
provides us with an insight of the instances themselves. As a consequence,
research experiments that involve JSON documents do not follow a methodical
approach for solving the input selection problem. To solve this problem, [9]
(Table 2) introduces a formal tiered taxonomy consisting of 36 categories that
form a common basis to class JSON documents based on their size, type of
content, characteristics of their structure and redundancy criteria.

Given the universality of the JSON [4] data interchange format as the lingua-
franca of the web [8], a growing amount of research is conducted taking JSON
documents as input. For any experiment following a thorough scientific
approach, the quality and representativity of the input data is a significant
factor that determines the quality of the experiment results.

Software systems make use of JSON to model diverse and domain-specific data
structures. Each of these data structures have characteristics that
distinguish them from other data structures. For example, a data structure
that models a person is fundamentally different from a data structure that
models sensor data. The difference lies in the characteristics which use
diverse data types such as text, numeric and boolean. Therefore, two instances
of the same data structure may inherit the same or similar characteristics
despite having different values.

Intuitively and on observation, we know that these characteristics exist, but
in the existing literature we lack a common terminology to describe them in an
unambiguous way. In an attempt to solve this ambiguity problem, our taxonomy
[9] (Table 2) presents a formal vocabulary to describe, reason, discuss and
reason about JSON documents in a high-level manner.

##  2 Taxonomy Definition

Our proposed taxonomy [9] aims to classify JSON documents into a limited and
useful set of categories that is easy to reason about rather than exhaustively
considering every possible aspect of a data structure. This taxonomy
categorizes JSON documents according to their size, content, redundancy and
nesting characteristics.

###  2.1 Naming Conventions

We present the naming conventions of the taxonomy in Table 1.

Table 1: The letter T stands for Tier 1, the letter S stands for Tier 2 and the letter L stands for Tier 3. Tier | Content Type | Redundancy | Structure | Acronym
---|---|---|---|---
Size Minified $<$ 100 bytes
Tier 1 | Numeric | Redundant | Flat | TNRF
Tier 1 | Numeric | Redundant | Nested | TNRN
Tier 1 | Numeric | Non-Redundant | Flat | TNNF
Tier 1 | Numeric | Non-Redundant | Nested | TNNN
Tier 1 | Textual | Redundant | Flat | TTRF
Tier 1 | Textual | Redundant | Nested | TTRN
Tier 1 | Textual | Non-Redundant | Flat | TTNF
Tier 1 | Textual | Non-Redundant | Nested | TTNN
Tier 1 | Boolean | Redundant | Flat | TBRF
Tier 1 | Boolean | Redundant | Nested | TBRN
Tier 1 | Boolean | Non-Redundant | Flat | TBNF
Tier 1 | Boolean | Non-Redundant | Nested | TBNN
Size Minified $\geq$ 100 $<$ 1000 bytes
Tier 2 | Numeric | Redundant | Flat | SNRF
Tier 2 | Numeric | Redundant | Nested | SNRN
Tier 2 | Numeric | Non-Redundant | Flat | SNNF
Tier 2 | Numeric | Non-Redundant | Nested | SNNN
Tier 2 | Textual | Redundant | Flat | STRF
Tier 2 | Textual | Redundant | Nested | STRN
Tier 2 | Textual | Non-Redundant | Flat | STNF
Tier 2 | Textual | Non-Redundant | Nested | STNN
Tier 2 | Boolean | Redundant | Flat | SBRF
Tier 2 | Boolean | Redundant | Nested | SBRN
Tier 2 | Boolean | Non-Redundant | Flat | SBNF
Tier 2 | Boolean | Non-Redundant | Nested | SBNN
Size Minified $\geq$ 1000 bytes
Tier 3 | Numeric | Redundant | Flat | LNRF
Tier 3 | Numeric | Redundant | Nested | LNRN
Tier 3 | Numeric | Non-Redundant | Flat | LNNF
Tier 3 | Numeric | Non-Redundant | Nested | LNNN
Tier 3 | Textual | Redundant | Flat | LTRF
Tier 3 | Textual | Redundant | Nested | LTRN
Tier 3 | Textual | Non-Redundant | Flat | LTNF
Tier 3 | Textual | Non-Redundant | Nested | LTNN
Tier 3 | Boolean | Redundant | Flat | LBRF
Tier 3 | Boolean | Redundant | Nested | LBRN
Tier 3 | Boolean | Non-Redundant | Flat | LBNF
Tier 3 | Boolean | Non-Redundant | Nested | LBNN

Figure 1: [9] introduces a formal taxonomy to class JSON documents that
consists of 36 categories.

###  2.2 Size

  * •

Tier 1 Minified $<$ 100 bytes. A JSON document is in this category if its
UTF-8 [3] minified form occupies less than 100 bytes.

  * •

Tier 2 Minified $\geq$ 100 $<$ 1000 bytes. A JSON document is in this category
if its UTF-8 [3] minified form occupies 100 bytes or more, but less than 1000
bytes.

  * •

Tier 3 Minified $\geq$ 1000 bytes. A JSON document is in this category if its
UTF-8 [3] minified form occupies 1000 bytes or more.

###  2.3 Content Type

  * •

Textual. A JSON document is in this category if it has at least one string
value and its number of string values multiplied by the cummulative byte-size
occupied by its string values is greater than or equal to the boolean and
numeric counterparts.

  * •

Numeric. A JSON document is in this category if it has at least one number
value and its number of number values multiplied by the cummulative byte-size
occupied by its number values is greater than or equal to the textual and
boolean counterparts.

  * •

Boolean. A JSON document is in this category if it has at least one boolean or
null value and its number of boolean and null values multiplied by the
cummulative byte-size occupied by its boolean and null values is greater than
or equal to the textual and numeric counterparts.

  * •

Structural. A JSON document is in this category if it does not include any
string, boolean, null or number values.

A JSON document can be categorized as textual, numeric and boolean at the same
time.

###  2.4 Redundancy

  * •

Non-redundant. A JSON document is in this category if less than 25

  * •

Redundant. A JSON document is in this category if at least 25percent of its
scalar and composite values are redundant.

###  2.5 Nesting

  * •

Flat. A JSON document is in this category if the height of the document
multiplied by the non-root level with the largest byte-size when taking
textual, numeric and boolean values into account is less than 10. If two
levels have the byte size, the highest level is taken into account.

  * •

Nested. A JSON document is in this category if it is considered structural and
its height is greater than or equal to 5, or if the height of the document
multiplied by the non-root level with the largest byte-size when taking
textual, numeric and boolean values into account is greater than or equal to
10. If two levels have the byte size, the highest level is taken into account.

##  3 JSON Stats Analyzer

The JSON Stats Analyzer is a free-to-use open-source web application that
implements the taxonomy introduced in [9] and provides summary statistics.
Using JSON Stats Analyzer, a user can determine the summary statistics
corresponding to the taxonomy for any given JSON document. To complement the
web application, the project also distributes a Node.js 111https://nodejs.org
command-line interface program and a JavaScript library for programmatic use.

The JSON Stats Analyzer is developed using the JavaScript [5] programming
language, the CodeMirror 222https://codemirror.net version 5.65.0 open-source
embeddable web editor (MIT License), the open-source Chart.js
333https://www.chartjs.org version 3.7.0 charting JavaScript library (MIT
License), and the UI Kit 444https://getuikit.com version 3.10.0 CSS open-
source web component framework (MIT License). The web application is deployed
to the GitHub Pages 555https://pages.github.com free static-hosting service.

To make use of the JSON Stats Analyzer web application, the user opens
https://sourcemeta.github.io/json-taxonomy/ on a web browser, writes or copy-
pastes a JSON document of choice on the text editor at the left-hand side of
the screen, and clicks the Analyze JSON button at the top right corner of the
screen. The analysis results are presented at the right-hand side of the
screen. If the syntax of the JSON document is invalid, an error is displayed
at the right-hand side of the screen.

The analysis results are presented in the following order:

  * •

The classification of the input JSON document according to the taxonomy
introduced in [9].

  * •

A set of pie charts representing the distribution of content type when taking
into consideration the number of values of the input JSON document and the
byte-size of the input JSON document in UTF-8 [3] minified form.

  * •

A high-level summary of the input JSON document in terms of its byte-size in
UTF-8 [3] minified form, its number of values, its height and its number of
duplicated values.

  * •

A breakdown of the input JSON document values aggregated by content and
divided in terms of the number of values in the document, their byte-size and
redundancy level.

  * •

A breakdown of the input JSON document values aggregated by their nesting
level divided in terms of the number of values in the document and their byte-
size.

##  4 Usage

###  4.1 JavaScript

We publish an npm 666https://www.npmjs.com package which can be installed as
shown in Figure 2.

Figure 2: The JavaScript module that implements the JSON Taxonomy is installed
through the npm package manager.

The module exposes a single function that takes any JSON value and returns the
sequence of taxonomy qualifiers as an array of strings. Its usage is
exemplified in Figure 3.

Figure 3: The JavaScript module exposes a single function that computes the
JSON Taxonomy for any JSON value.

###  4.2 CLI

The npm package includes a simple command-line interface program that can be
globally installed as shown in Figure 4.

Figure 4: The companion command-line interface program that implements the
JSON Taxonomy is also installed through the npm package manager.

The CLI program takes the path to a JSON document as an argument and outputs
the taxonomy to standard output as shown in Figure 5.

Figure 5: An example of running the JSON Taxonomy command-line program with a
fictitious JSON document file as input.

##  5 Demonstration

In this section, we demonstrate various JSON documents for Tier 1, Tier 2 and
Tier 3 as per the taxonomy defined in [9]. For each demonstration, we provide
the definition, characteristics and document structure. These documents are as
follows:

  * •

Grunt.js Clean Task. Tier 1 Minified $<$ 100 bytes, textual, redundant, flat.
See Figure 6.

  * •

CircleCI Matrix. Tier 1 Minified $<$ 100 bytes, numeric, non-redundant,
nested. See Figure 7.

  * •

TSLint Linter (Basic). Tier 1 Minified $<$ 100 bytes, boolean, non-redundant,
nested. See Figure 8.

  * •

Entry Point Regulation Manifest. Tier 2 Minified $\geq$ 100 $<$ 1000 bytes,
textual, redundant, nested. See Figure 9.

  * •

TravisCI Notifications Configuration. Tier 2 Minified $\geq$ 100 $<$ 1000
bytes, textual, redundant, flat. See Figure 10.

  * •

GeoJSON Example Document. Tier 2 Minified $\geq$ 100 $<$ 1000 bytes, numeric,
redundant, nested. See Figure 11.

  * •

GitHub FUNDING Sponsorship (Empty). Tier 2 Minified $\geq$ 100 $<$ 1000 bytes,
boolean, redundant, flat. See Figure 12.

  * •

NPM Package.json Example Manifest. Tier 3 Minified $\geq$ 1000 bytes, textual,
non-redundant, flat. See Figure 13.

  * •

JSON Resume Example. Tier 3 Minified $\geq$ 1000 bytes, textual, non-
redundant, nested. See Figure 14.

  * •

ESLint Configuration Document. Tier 3 Minified $\geq$ 1000 bytes, numeric,
redundant, flat. See Figure 15.

  * •

Nightwatch.js Test Framework Configuration. Tier 3 Minified $\geq$ 1000 bytes,
boolean, redundant, flat. See Figure 16.

###  5.1 Grunt.js Clean Task

Definition. Grunt.js 777https://gruntjs.com is an open-source task runner for
the JavaScript [5] programming language used by a wide range of companies in
the software development industry such as Twitter, Adobe, and Mozilla
888https://gruntjs.com/who-uses-grunt. In Figure 6, we demonstrate a Tier 1
minified $<$ 100 bytes textual redundant flat (Tier 1 TRF from Table 1) JSON
document that consists of an example configuration for a built-in plugin to
clear files and folders called grunt-contrib-clean
999https://github.com/gruntjs/grunt-contrib-clean.

Characteristics. With a size of 92 bytes in UTF-8 [3] minified form, 10
values, a height [9] of 3 and 3 duplicated values, Grunt.js Contrib Clean is a
JSON document whose content is determined by structure both in terms of number
of values and cumulative byte-size. It has 4 non-structural values: 2 textual
values and 2 boolean values. However, the textual values are 4.3% larger in
byte-size than the boolean values.

Document Structure. This document contains equal number of boolean and textual
values, but the cumulative byte-size of the textual values is larger than the
cumulative byte-size of the boolean values. Therefore, this document is
_textual_ according to the taxonomy [9]. The boolean and string values in the
document have a 50% duplication. Therefore, this document is _redundant_
according to the taxonomy [9]. The height of this document is 3 and its
largest level is 2. Therefore, this document is _flat_ according to the
taxonomy [9].

Figure 6: Grunt.js Clean Task

###  5.2 CircleCI Matrix

Definition. CircleCI 101010https://circleci.com is a commercial cloud-provider
of continuous integration and deployment pipelines used by a wide range of
companies in the software development industry such as Facebook, Spotify, and
Heroku 111111https://circleci.com/customers/. In Figure 7, we demonstrate a
Tier 1 minified $<$ 100 bytes numeric non-redundant nested (Tier 1 NNN from
Table 1) JSON document that represents a pipeline configuration file for
CircleCI that declares the desired CircleCI version and defines a workflow
that contains a single blank matrix-based job.

Characteristics. With a size of 94 bytes in UTF-8 [3] minified form, 13
values, a height [9] of 9 and no duplicated values, CircleCI Matrix is a JSON
document whose content is determined by structural values both in terms of
number and cumulative byte-size. It only has non-structural values that are
numeric and add up to less than 7% of the total byte-size.

Document Structure. Leaving structural values aside, this document only
contains numeric values. Therefore, this document is _numeric_ according to
the taxonomy [9]. None of the values in this document are duplicated.
Therefore, this document is _non-redundant_ according to the taxonomy [9]. The
height of this document is 9 and its largest level is 9. Therefore, this
document is _nested_ according to the taxonomy [9].

Figure 7: CircleCI Matrix

###  5.3 TSLint Linter (Basic)

Definition. TSLint 121212https://palantir.github.io/tslint is now an obsolete
open-source linter for the TypeScript 131313https://www.typescriptlang.org
programming language. TSLint was created by the Big Data analytics company
Palantir 141414https://www.palantir.com and was merged with the ESLint open-
source JavaScript linter in 2019
151515https://github.com/palantir/tslint/issues/4534. In Figure 8, we
demonstrate a Tier 1 minified $<$ 100 bytes boolean non-redundant nested (Tier
1 BNN from Table 1) JSON document that consists of a basic TSLint
configuration that enforces grouped alphabetized imports.

Characteristics. With a size of 66 bytes in UTF-8 [3] minified form, 5 values,
a height [9] of 4 and no duplicated values, TSLint Linter (Basic) is a JSON
document whose content is determined by structural values both in terms of
number and cumulative byte-size. It has 1 non-structural value: a boolean that
add up to less than 7% of the total byte-size.

Document Structure. Leaving structural values aside, this document only
contains boolean values. Therefore, this document is _boolean_ according to
the taxonomy [9]. None of the values in this document are duplicated.
Therefore, this document is _non-redundant_ according to the taxonomy [9]. The
height of this document is 4 and its largest level is 4. Therefore, this
document is _nested_ according to the taxonomy [9].

Figure 8: TSLint Linter (Basic)

###  5.4 Entry Point Regulation Manifest

Definition. Entry Point Regulation (EPR) [6] is a W3C proposal led by Google
that defines a manifest that protects websites against cross-site scripting
attacks by allowing the developer to mark the areas of the application that
can be externally referenced. EPR manifests are used in the web industry. In
Figure 9, we demonstrate a Tier 2 minified $\geq$ 100 $<$ 1000 bytes textual
redundant nested (Tier 2 TRN from Table 1) JSON document that defines an
example EPR policy for a fictitious website.

Characteristics. With a size of 519 bytes in UTF-8 [3] minified form, 32
values, a height [9] of 4 and 10 duplicated values, Entry Point Regulation
Manifest is a JSON document whose content is determined by textual values in
terms of number but structural values in terms of cumulative byte-size. It has
20 non-structural values: 14 textual values, 1 numeric value and 5 boolean
values. Together, the 20 non-structural values represent 50% of the cumulative
byte-size.

Document Structure. This document includes textual, numeric and boolean
values. Leaving structural values aside, this document is dominated by textual
values in terms of number and cumulative byte-size. Therefore, this document
is _textual_ according to the taxonomy [9]. In this document, 3 out of 5
boolean values, 4 out of 14 textual values and 3 out of 12 structural values
are duplicates. Therefore, 31.25% of its values are duplicates, making this
document _redundant_ according to the taxonomy [9]. The height of this
document is 4 and its largest level is 3. Therefore, this document is _nested_
according to the taxonomy [9].

Figure 9: Entry Point Regulation Manifest

###  5.5 TravisCI Notifications Configuration

Definition. TravisCI 161616https://travis-ci.com is a commercial cloud-
provider of continuous integration and deployment pipelines used by a wide
range of companies in the software development industry such as ZenDesk,
BitTorrent, and Engine Yard. In Figure 10, we demonstrate a Tier 2 minified
$\geq$ 100 $<$ 1000 bytes textual redundant flat (Tier 2 TRF from Table 1)
JSON document that consists of an example pipeline configuration for TravisCI
that declares a set of credentials to post build notifications to various
external services.

Characteristics. With a size of 672 bytes in UTF-8 [3] minified form, 16
values, a height [9] of 3 and 12 duplicated values, TravisCI Notifications
Configuration is a JSON document whose content is determined by structural
values in terms of number and textual values in terms of cumulative byte-size.
All of its 7 non-structural values are strings that add to 75% of the total
byte-size.

Document Structure. Leaving structural values aside, this document only
contains textual values. Therefore, this document is _textual_ according to
the taxonomy [9]. In this document, 6 out of 7 textual values and 6 out of 9
structural values are duplicates. Therefore, 75% of its values are duplicates,
making this document _redundant_ according to the taxonomy [9]. The height of
this document is 3 and its largest level is 3. Therefore, this document is
_flat_ according to the taxonomy [9].

Figure 10: TravisCI Notifications Configuration

###  5.6 GeoJSON Example Document

Definition. GeoJSON [2] is a standard to encode geospatial information using
JSON. GeoJSON is used in industries that have geographical and geospatial use
cases such as engineering, logistics and telecommunications. In Figure 11, we
demonstrate a Tier 2 minified $\geq$ 100 $<$ 1000 bytes numeric redundant
nested (Tier 2 NRN from Table 1) JSON document that defines an example polygon
using the GeoJSON format.

Characteristics. With a size of 189 bytes in UTF-8 [3] minified form, 53
values, a height [9] of 5 and 21 duplicated values, GeoJSON Example Document
is a JSON document whose content is determined by numeric values in terms of
number but structural values in terms of cumulative byte-size. It has 31 non-
structural values: 1 textual value and 30 numeric values. Together, the 31
non-structural values represent 49.7% of the cumulative byte-size.

Document Structure. This document includes numeric and textual values. Leaving
structural values aside, this document is dominated by numeric values in terms
of number and cumulative byte-size. Therefore, this document is _numeric_
according to the taxonomy [9]. In this document, 18 out of 30 numeric values
and 3 out of 22 structural values are duplicates. Therefore, 39.62% of its
values are duplicates, making this document _redundant_ according to the
taxonomy [9]. The height of this document is 5 and its largest level is 5.
Therefore, this document is _nested_ according to the taxonomy [9].

Figure 11: GeoJSON Example Document

###  5.7 GitHub FUNDING Sponsorship (Empty)

Definition. The GitHub 171717https://github.com software hosting provider
defines a FUNDING 181818https://docs.github.com/en/github/administering-a-
repository/managing-repository-settings/displaying-a-sponsor-button-in-your-
repository file format to declare the funding platforms that an open-source
project supports. The FUNDING file format is used by the open-source software
industry. In Figure 12, we demonstrate a Tier 2 minified $\geq$ 100 $<$ 1000
bytes boolean redundant flat (Tier 2 BRF from Table 1) JSON document that
consists of a definition that does not declare any supported funding
platforms.

Characteristics. With a size of 182 bytes in UTF-8 [3] minified form, 11
values, a height [9] of 1 and 8 duplicated values, GitHub FUNDING Sponsorship
(Empty) is a JSON document whose content is determined by boolean values in
terms of number but structural values in terms of cumulative byte-size. It has
10 non-structural values: 1 textual value and 9 boolean values. Together, the
10 non-structural values represent 29.1% of the cumulative byte-size.

Document Structure. This document is dominated by boolean values in terms of
number. Leaving structural values aside, this document is dominated by boolean
values in terms of cumulative byte-size. Therefore, this document is _boolean_
according to the taxonomy [9]. In this document, 8 out of 9 boolean values are
duplicates. Therefore, 72.73% of its values are duplicates, making this
document _redundant_ according to the taxonomy [9]. The height of this
document is 1 and its largest level is 1. Therefore, this document is _flat_
according to the taxonomy [9].

Figure 12: GitHub FUNDING Sponsorship (Empty)

###  5.8 NPM Package.json Example Manifest

Definition. Node.js Package Manager (NPM) 191919https://www.npmjs.com is an
open-source package manager for Node.js 202020https://nodejs.org, a JavaScript
[5] runtime targetted at the web development industry. A package that is
published to NPM is declared using a JSON file called package.json
212121https://docs.npmjs.com/cli/v6/configuring-npm/package-json. In Figure
13, we demonstrate a Tier 3 minified $\geq$ 1000 bytes textual non-redundant
flat (Tier 3 TNF from Table 1) JSON document that consists of a package.json
manifest that declares a particular version of the Grunt.js
222222https://gruntjs.com task runner.

Characteristics. With a size of 2258 bytes in UTF-8 [3] minified form, 72
values, a height [9] of 3 and 3 duplicated values, NPM Package.json Example
Manifest is a JSON document whose content is determined by textual values in
terms of both number and cumulative byte-size. It has 61 non-structural
values. Together, the non-structural values represent 84.72% of the cumulative
byte-size.

Document Structure. Leaving structural values aside, this document only
contains textual values. Therefore, this document is _textual_ according to
the taxonomy [9]. In this document, 3 out of 61 textual values are duplicates.
Therefore, only 4.17% of its values are duplicates, making this document _non-
redundant_ according to the taxonomy [9]. The height of this document is 3 and
its largest level is 1. Therefore, this document is _flat_ according to the
taxonomy [9].

Figure 13: NPM Package.json Example Manifest

###  5.9 JSON Resume Example

Definition. JSON Resume 232323https://jsonresume.org is a community-driven
proposal for a JSON-based file format that declares and renders themable
resumes used in the recruitment industry. In Figure 14, we demonstrate a Tier
3 minified $\geq$ 1000 bytes textual non-redundant nested (Tier 3 TNN from
Table 1) JSON document that consists of a detailed example resume for a
fictitious software programmer.

Characteristics. With a size of 3047 bytes in UTF-8 [3] minified form, 99
values, a height [9] of 4 and 2 duplicated values, JSON Resume Example is a
JSON document whose content is determined by textual values in terms of both
number and cumulative byte-size. It has 68 non-structural values. Together,
the non-structural values represent 68.69% of the cumulative byte-size.

Document Structure. Leaving structural values aside, this document only
contains textual values. Therefore, this document is _textual_ according to
the taxonomy [9]. In this document, 2 out of 68 textual values are duplicates.
Therefore, only 2.02% of its values are duplicates, making this document _non-
redundant_ according to the taxonomy [9]. The height of this document is 4 and
its largest level is 3. Therefore, this document is _nested_ according to the
taxonomy [9].

Figure 14: JSON Resume Example

###  5.10 ESLint Configuration Document

Definition. ESLint 242424https://eslint.org is a popular open-source
extensible linter for the JavaScript [5] programming language used by a wide
range of companies in the software development industry such as Google,
Salesforce, and Airbnb. In Figure 15, we demonstrate a Tier 3 minified $\geq$
1000 bytes numeric redundant flat (Tier 3 NRF from Table 1) JSON document that
defines a browser and Node.js linter configuration that defines general-
purposes and _React.js_ -specific 252525https://reactjs.org linting rules.

Characteristics. With a size of 1140 bytes in UTF-8 [3] minified form, 54
values, a height [9] of 4 and 39 duplicated values, ESLint Configuration
Document is a JSON document whose content is determined by numeric values in
terms of number but structural values in terms of cumulative byte-size. It has
47 non-structural values: 3 textual values, 39 numeric values and 5 boolean
values. Together, the 47 non-structural values represent only 9.91% of the
cumulative byte-size.

Document Structure. This document includes textual, numeric and boolean
values. While this document is dominated by numeric values in terms of number,
numeric values do not make for the majority of cumulative byte-size by content
type. However, the high difference in the number of numeric values and other
types of values increases the numeric weight of the document and makes the
document _numeric_ according to the taxonomy [9]. In this document, 36 out of
39 numeric values and 3 out of 5 boolean values are duplicates. Therefore,
72.23% of its values are duplicates, making this document _redundant_
according to the taxonomy [9]. The height of this document is 4 and its
largest level is 2. Therefore, this document is _flat_ according to the
taxonomy [9].

Figure 15: ESLint Configuration Document

###  5.11 Nightwatch.js Test Framework Configuration

Definition. Nightwatch.js 262626https://nightwatchjs.org is an open-source
browser automation solution used in the software testing industry. In Figure
16, we demonstrate a Tier 3 minified $\geq$ 1000 bytes boolean redundant flat
(Tier 3 BRF from Table 1) JSON document that consists of a Nightwatch.js
configuration file that defines a set of general-purpose WebDriver [7] and
Selenium 272727https://www.selenium.dev options.

Characteristics. With a size of 1506 bytes in UTF-8 [3] minified form, 66
values, a height [9] of 3 and 42 duplicated values, Nightwatch.js Test
Framework Configuration is a JSON document whose content is determined by
boolean values in terms of number but structural values in terms of cumulative
byte-size. It has 56 non-structural values: 10 textual values, 14 numeric
values and 32 boolean values. Together, the 56 non-structural values represent
only 16.2% of the cumulative byte-size.

Document Structure. This document includes textual, numeric and boolean
values. Leaving structural values aside, this document is dominated by boolean
values in terms of number and cumulative byte-size. Therefore, this document
is _boolean_ according to the taxonomy [9]. In this document, 5 out of 10
textual values, 4 out of 14 numeric values, 29 out of 32 boolean values and 4
out of 10 structural values are duplicates. Therefore, 63.64% of its values
are duplicates, making this document _redundant_ according to the taxonomy
[9]. The height of this document is 3 and its largest level is 1. Therefore,
this document is _flat_ according to the taxonomy [9].

Figure 16: Nightwatch.js Test Framework Configuration

##  6 Conclusions and Further Work

In this paper, we present JSON Stats Analyzer, a free-to-use open-source web-
based JavaScript tool that implements our proposed JSON taxonomy [9] that
categorizes JSON documents according to their size, content, redundancy and
nesting characteristics.

There are several avenues to extend our work: a visualization dashboard that
compares multiple JSON documents across the tiers based on their content type,
redundancy characteristics and document structure providing us with a meta
analysis of how the documents with a variety of characteristics fare across
the tiers; building a wider dataset of real-world JSON documents that
demonstrates the characteristics pertinent to each tier. We welcome
contributions to build this dataset from the industry professionals and
academic community alike.

## References

  * [1]
  * Butler et al. [2016] H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, and T. Schaub. 2016.  _The GeoJSON Format_.  RFC. IETF.  https://doi.org/10.17487/RFC7946
  * Consortium [2019] The Unicode Consortium. 2019\.  _The Unicode Standard, Version 12.1.0_.  Standard. The Unicode Consortium, Mountain View, CA.
  * ECMA [2017] ECMA. 2017.  _ECMA-404: The JSON Data Interchange Syntax_.  ECMA, Geneva, CH.  https://www.ecma-international.org/publications/standards/Ecma-404.htm
  * ECMA [2021] ECMA. 2021.  _ECMA-262: ECMAScript 2021 language specification_.  ECMA, Geneva, CH.  https://www.ecma-international.org/publications/standards/Ecma-262.htm
  * Ross and West [2016] David Ross and Mike West. 2016.  _Entry Point Regulation_.  W3C Working Group Note. W3C.  https://w3c.github.io/webappsec-epr/.
  * Stewart and Burns [2020] Simon Stewart and David Burns. 2020.  _WebDriver_.  W3C Working Draft. W3C.
  * Vargas et al. [2019] Santiago Vargas, Utkarsh Goel, Moritz Steiner, and Aruna Balasubramanian. 2019.  Characterizing JSON Traffic Patterns on a CDN. In _Proceedings of the Internet Measurement Conference_ (Amsterdam, Netherlands) _(IMC ’19)_. Association for Computing Machinery, New York, NY, USA, 195–201.  https://doi.org/10.1145/3355369.3355594
  * Viotti and Kinderkhedia [2022] Juan Cruz Viotti and Mital Kinderkhedia. 2022.  A Benchmark of JSON-compatible Binary Serialization Specifications.  arXiv:2201.03051 [cs.SE]