JSON

Mednarodni standard iz leta 2017 (ECMA-404 in ISO/IEC 21778:2017) določa, da se »JSON« »izgovarja , kot v 'Jazon (Jason) in argonavti'«. Prva izdaja (2013) standarda ECMA-404 ni obravnavala izgovorjave. Crockford je leta 2011 dejal: »Veliko je razprav o tem, kako to izgovorite, ampak me to absolutno ne zanima.« je še ena pogosta izgovorjava.

Potem ko je bil RFC 4627 na voljo kot njegova »informativna« specifikacija od leta 2006, je bil JSON prvič standardiziran leta 2013 kot ECMA-404. RFC 8259, objavljen leta 2017, je trenutna različica internetnega standarda STD 90 in ostaja skladen z ECMA-404. Istega leta je bil JSON standardiziran tudi kot ISO/IEC 21778:2017. Standarda ECMA in ISO/IEC opisujeta le dovoljeno skladnjo, medtem ko RFC zajema nekatere varnostne in interoperabilnostne vidike.

JSON je nastal iz potrebe po komunikacijskem protokolumed strežnikom in brskalnikom v realnem času brez uporabe vtičnikov brskalnika, kot sta Flash ali java apleti, prevladujočih metod, ki so se uporabljale v zgodnjih 2000-ih.

Crockford je prvi določil in populariziral format JSON. Akronim je nastal v podjetju State Software, ki so ga soustanovili Crockford in drugi, marca 2001. Soustanovitelji so se dogovorili, da bodo zgradili sistem, ki bo uporabljal standardne zmogljivosti brskalnika in zagotavljal abstrakcijsko plast za spletne razvijalce za ustvarjanje spletnih aplikacij z ohranjanjem stanja, ki bodo imele trajno dupleksno povezavo s spletnim strežnikom, tako da bosta odprti dve povezavi HTTP in bodo reciklirane pred standardnimi časovnimi omejitvami brskalnika, če ne bodo izmenjani nadaljnji podatki. Soustanovitelji so imeli okroglo mizo in glasovali o tem, ali naj se podatkovni format imenuje JSML (JavaScript Markup Language) ali JSON (JavaScript Object Notation), pa tudi pod kakšno vrsto licence naj bo na voljo. Spletna stran JSON.org je začela delovati leta 2001. Decembra 2005 je Yahoo! je začel ponujati nekatere svoje spletne storitve v JSON.

Predhodnik knjižnic JSON je bil uporabljen v projektu otroške igre za trgovanje z digitalnimi sredstvi z imenom Cartoon Orbit na Communities.com, ki je uporabljal stranski vtičnik brskalnika z lastniškim formatom sporočil za manipulacijo elementov DHTML. Po odkritju zgodnjih zmogljivosti Ajaxa so digiGroups, Noosh in drugi uporabili okvirje za posredovanje informacij v vidno polje uporabnikovega brskalnika brez osveževanja vizualnega konteksta spletne aplikacije, s čimer so ustvarili bogate spletne aplikacije v realnem času z uporabo le standardnih zmogljivosti HTTP, HTML in JavaScript iz brskalnikov Netscape 4.0.5+ in Internet Explorer 5+. Crockford je nato ugotovil, da bi se JavaScript lahko uporabljal kot objektno usmerjena oblika sporočil za tak sistem. Sistem je bil prodan podjetjem Sun Microsystems, Amazon.com in EDS.

JSON je temeljil na podmnožici skriptnega jezika JavaScript (natančneje na standardu ECMA-262, 3. izdaja – december 1999) in se pogosto uporablja z JavaScriptom, vendar je od jezika neodvisni podatkovni format. Koda za razčlenjevanje in ustvarjanje podatkov JSON je na voljo v mnogih programskih jezikih. Spletna stran JSON navaja knjižnice JSON po jezikih.

Oktobra 2013 je Ecma International objavila prvo izdajo svojega standarda JSON ECMA-404. Istega leta je RFC 7158 uporabil ECMA-404 kot referenco. Leta 2014 je RFC 7159 postal glavna referenca za internetno uporabo JSON-a in nadomestil RFC 4627 in RFC 7158 (vendar je ECMA-262 in ECMA-404 ohranil kot glavni referenci). Novembra 2017 je ISO/IEC JTC 1/SC 22 objavil ISO/IEC 21778:2017 kot mednarodni standard. 13. decembra 2017 je Projektna skupina za internetno inženirstvo (Internet Engineering Task Force, IETF) z objavo RFC 8259, ki je trenutna različica Internetnega standarda STD 90, razveljavila RFC 7159.

Crockford je licenci JSON dodal klavzulo, v kateri je zapisano: »Programska oprema se uporablja za dobro, ne za zlo«, da bi knjižnice JSON odkril kot odprtokodne, hkrati pa se je posmehoval korporativnim odvetnikom in tistim, ki so pretirano pedantni. Po drugi strani pa je ta klavzula povzročila težave z licenčno združljivostjo JSON z drugimi odprtokodnimi licencami, saj odprtokodna in prosta programska oprema običajno ne pomenita nobenih omejitev glede namena uporabe.

Naslednji primer prikazuje možno predstavitev JSON, ki opisuje osebo.

{
  "first_name": "John",
  "last_name": "Smith",
  "is_alive": true,
  "age": 27,
  "address": {
    "street_address": "21 2nd Street",
    "city": "New York",
    "state": "NY",
    "postal_code": "10021-3100"
  },
  "phone_numbers": [
    {
      "type": "home",
      "number": "212 555-1234"
    },
    {
      "type": "office",
      "number": "646 555-4567"
    }
  ],
  "children": [
    "Catherine",
    "Thomas",
    "Trevor"
  ],
  "spouse": null
}

Kodiranje znakov

Čeprav je Crockford prvotno trdil, da je JSON stroga podmnožica JavaScripta in ECMAScripta, njuna specifikacija dejansko dovoljuje veljavne dokumente JSON, ki niso veljaven JavaScript  – JSON dovoljuje, da se znaka za zaključek vrstice U+2028 VRSTIČNI LOČILNIK in U+2029 ODSTAVČNI LOČILNIK v narekovajih pojavita brez ubežnih znakov, medtem ko ECMAScript 2018 in starejši ne. To je posledica dejstva, da JSON ne dovoljuje samo »nadzornih znakov«. Za največjo prenosljivost so ti znaki ubežni s povratno (levo) poševnico.

Izmenjava JSON v odprtem ekosistemu mora biti kodirana v UTF-8. Kodiranje podpira celoten nabor znakov Unicode, vključno z znaki zunaj osnovne večjezične ravnine (U+0000 do U+FFFF). Če pa so ti znaki ubežni, morajo biti zapisani z nadomestnimi pari UTF-16. Na primer, če se želi v JSON vključiti znak emodži U+1F610 😐 NEVTRALNI OBRAZ:

{ "face": "😐" }

Ali:

{ "face": "\uD83D\uDE10" }

JSON je postal stroga podmnožica jezika ECMAScript od revizije jezika leta 2019.

Podatkovni tipi

Osnovni podatkovni tipi JSON so:

• število: predznačeno desetiško število, ki lahko vsebuje ulomek in uporablja eksponentni zapis E, vendar ne more vključevati neštevilskih vrednosti, kot je NaN. Format ne razlikuje med celim številom in številom s plavajočo vejico. JavaScript uporablja format s plavajočo vejico dvojne točnosti IEEE-754 za vse svoje numerične vrednosti (kasneje podpira tudi BigInt), vendar lahko drugi jeziki, ki implementirajo JSON, števila kodirajo drugače.
• znakovni niz: zaporedje nič ali več znakov Unicode. Znakovni nizi so ločeni z dvojnimi narekovaji in podpirajo poševnično ubežno skladnjo.
• Boolov: ena od vrednosti true ali false
• polje: urejeni seznam nič ali več elementov, od katerih je lahko vsak poljubnega tipa. Polja uporabljajo zapis v oglatih oklepajih z elementi, ločenimi z vejicami.
• objekt: zbirka parov ime-vrednost, kjer so imena (imenovana tudi ključi) znakovni nizi. Trenutni standard ECMA pravi: »Skladnja JSON ne nalaga nobenih omejitev znakovnim nizom, ki se uporabljajo kot imena, ne zahteva, da so znakovni nizi imen enolični, in ne pripisuje nobenega pomena vrstnemu redu parov ime/vrednost.« Objekti so ločeni z zavitimi oklepaji, pari pa se ločujejo z vejicami, znotraj vsakega para dvopičje »:« ločuje ključ ali ime od njegove vrednosti.
• null: prazna vrednost z uporabo besede null

Presledki so dovoljeni in prezrti okrog ali med skladenjskimi elementi (vrednosti in ločila, ne pa znotraj vrednosti znakovnega niza). Za presledke se v ta namen štejejo štirje specifični znaki: presledek, vodoravni tabulator, pomik v novo vrstico in pomik na začetek vrstice. Zlasti oznaka vrstnega reda bajtov ne sme biti ustvarjena s skladno implementacijo (čeprav je lahko sprejeta pri razčlenjevanju JSON). JSON ne ponuja skladnje za komentarje.

Zgodnje različice JSON (kot so določene v RFC 4627) so zahtevale, da mora veljavno besedilo JSON vsebovati samo objekt ali tip polja, ki lahko vsebujeta druge tipe znotraj sebe. Ta omejitev je bila opuščena v RFC 7158, kjer je bilo besedilo JSON na novo definirano kot poljubna serializirana vrednost.

Števila v JSON so agnostična glede njihove predstavitve v programskih jezikih. Čeprav to omogoča serializiranje števil poljubne točnosti, lahko povzroči težave s prenosljivostjo. Ker na primer ni razlikovanja med celoštevilskimi in plavajočimi vrednostmi, lahko nekatere implementacije obravnavajo 42, 42.0, and 4.2E+1 kot isto število, druge pa ne. Standard JSON ne postavlja zahtev glede podrobnosti implementacije, kot so prekoračitev, podkoračitev, izguba točnosti, zaokroževanje ali predznačene ničle, vendar priporoča, da se za »dobro interoperabilnost« ne pričakuje več kot točnost IEEE 754 binary64. Pri serializiranju dvojiške predstavitve števila s plavajočo vejico na ravni stroja (kot je binary64) v človeku berljivo desetiško predstavitev (kot so števila v JSON) in nazaj ni inherentne izgube točnosti  – obstajajo objavljeni algoritmi za točno in optimalno izvedbo te pretvorbe.

Komentarji so bili namerno izključeni iz JSON. Leta 2012 je Crockford njihovo odločitev o zasnovi opisal takole: »Odstranil sem komentarje iz JSON-a, ker sem videl, da jih ljudje uporabljajo za shranjevanje ukazov za razčlenjevanje, kar bi uničilo interoperabilnost.«

JSON ne dovoljuje »zaključnih vejic«  – vejice za zadnjo vrednostjo znotraj podatkovne strukture. Zaključne vejice so pogosta značilnost izpeljank JSON za izboljšanje enostavnosti uporabe.

RFC 8259 opisuje nekatere vidike skladnje JSON, ki so sicer dovoljeni v skladu s specifikacijami, vendar lahko povzročijo težave z interoperabilnostjo.

• nekatere implementacije JSON sprejemajo samo besedila JSON, ki predstavljajo objekt ali polje. Zaradi interoperabilnosti bi morale aplikacije, ki si izmenjujejo JSON, prenašati sporočila, ki so objekti ali polja.
• specifikacije dovoljujejo objekte JSON, ki vsebujejo več članov z istim imenom. Obnašanje implementacij, ki obdelujejo objekte s podvojenimi imeni, je nepredvidljivo. Zaradi interoperabilnosti se morajo aplikacije pri prenosu objektov JSON izogibati podvojenim imenom.
• specifikacije izrecno določajo, da vrstni red članov v objektih JSON ni pomemben. Zaradi interoperabilnosti se morajo aplikacije izogibati dodeljevanju pomena vrstnemu redu članov, tudi če programska oprema za razčlenjevanje ta vrstni red naredi vidnega.
• čeprav specifikacije ne omejujejo velikosti ali točnosti številskih literalov JSON, jih pogosto uporabljena implementacija JavaScript shranjuje kot količine IEEE754 »binary64«. Zaradi interoperabilnosti se morajo aplikacije izogibati prenosu števil, ki jih ni mogoče predstaviti na ta način, na primer 1E400 ali 3,141592653589793238462643383279.
• čeprav specifikacije ne omejujejo kodiranja znakov Unicode v besedilu JSON, velika večina implementacij predvideva kodiranje UTF-8  – zaradi interoperabilnosti bi morale aplikacije sporočila JSON vedno in samo kodirati v UTF-8.
• specifikacije ne prepovedujejo prenosa zaporedij bajtov, ki nepravilno predstavljajo znake Unicode. Zaradi interoperabilnosti bi morale aplikacije prenašati sporočila, ki ne vsebujejo takšnih zaporedij bajtov.
• specifikacija ne omejuje načina, kako aplikacije primerjajo znakovne nize Unicode. Zaradi interoperabilnosti bi morale aplikacije takšne primerjave vedno izvajati po posameznih kodnih enotah.

Leta 2015 je IETF objavila RFC 7493, ki opisuje »format sporočila I-JSON«, omejeni profil JSON, ki omejuje skladnjo in obdelavo JSON, da bi se čim bolj izognilo tem težavam z interoperabilnostjo.

Semantika

Čeprav JSON zagotavlja skladenjski okvir za izmenjavo podatkov, nedvoumna izmenjava podatkov zahteva tudi dogovor med proizvajalcem in potrošnikom o semantiki specifične rabe skladnje JSON. Zgled, kjer je tak dogovor potreben, je serializacija podatkovnih tipov, ki niso del standarda JSON, na primer datumi in regularni izrazi.

Uradni tip MIME za besedilo JSON je application/json, in večina sodobnih implementacij ga je sprejela. Med starejše tipe MIME spadajo text/json, text/x-json in text/javascript. Standardna pripona imena datoteke je .json.

Shema JSON določa format, temelječ na JSON, za definiranje strukture podatkov JSON za validacijo, dokumentacijo in nadzor interakcije. Zagotavlja pogodbo za podatke JSON, ki jih zahteva določena aplikacija, in kako je te podatke mogoče spremeniti. Shema JSON temelji na konceptih iz XML Schema (XSD), vendar temelji na JSON. Tako kot pri XSD se lahko ista orodja za serializacijo/deserializacijo uporabljajo tako za shemo kot za podatke in je samoopisna. Določena je v Internet Draftu pri IETF, pri čemer je najnovejša različica iz leta 2024 »Draft 2020-12«. Za različne programske jezike je na voljo več validatorjev, vsak z različnimi stopnjami skladnosti.

Standard JSON ne podpira referenc na objekte, vendar obstaja osnutek standarda IETF za reference na objekte, ki temeljijo na JSON.

JSON-RPC je protokol za oddaljeno proženje procedur (RPC), zgrajen na JSON-u kot nadomestilo za XML-RPC ali SOAP. Gre za preprost protokol, ki definira le peščico podatkovnih tipov in ukazov. JSON-RPC omogoča sistemu pošiljanje obvestil (informacij strežniku, ki ne zahtevajo odgovora) in mnogokratnih klicev strežniku, na katere je mogoče odgovoriti zunaj vrstnega reda.

Asinhroni JavaScript in JSON (ali AJAJ) se nanašata na isto metodologijo dinamičnih spletnih strani kot Ajax, le da se namesto XML uporablja podatkovni format JSON. AJAJ je tehnika spletnega razvoja, ki spletni strani omogoča, da po nalaganju v spletni brskalnik zahteva nove podatke. Običajno s strežnika prikaže nove podatke kot odgovor na uporabnikova dejanja na tej spletni strani. Na primer, kar uporabnik vnese v iskalno polje, odjemalska koda nato pošlje strežniku, ki takoj odgovori s spustnim seznamom ustreznih elementov podatkovne zbirke.

JSON se je kot konfiguracijski jezik uporabljal ad hoc. Vendar pa ne podpira komentarjev. Leta 2012 je Crockford, ustvarjalec JSON-a, o komentarjih v JSON-u, ko se uporablja kot konfiguracijski jezik, povedal naslednje: »Vem, da pomanjkanje komentarjev nekatere ljudi žalosti, vendar ne bi smelo. Recimo, da uporabljate JSON za shranjevanje konfiguracijskih datotek, ki jih želite označiti. Kar vstavite vse komentarje, ki jih želite. Nato jih posredujte razčlenjevalniku JSON prek JSMin.«

MongoDB za svojo dokumentno usmerjeno podatkovno zbirko uporablja podatke, podobne JSON-u.

Nekatere relacijske podatkovne zbirke imajo dodano podporo za izvorne podatkovne tipe JSON, kot sta JSONB v PostgreSQL in JSON v MySQL. To razvijalcem omogoča neposredno vstavljanje podatkov JSON, ne da bi jih morali pretvoriti v drugo obliko.

Ker je JSON podmnožica JavaScripta, lahko pride do napačnega prepričanja, da je varno posredovati besedila JSON funkciji JavaScript eval(). To ni varno, saj nekatera veljavna besedila JSON, zlasti tista, ki vsebujejo U+2028 VRSTIČNO LOČILO ali U+2029 ODSTAVČNO LOČILO, niso veljavna koda JavaScript, dokler specifikacije JavaScripta niso bile posodobljene leta 2019 in tako starejši pogoni morda ne podpirajo te kode. Da bi se izognili mnogim pastem, ki jih povzroča izvajanje poljubne kode z interneta, je bila v peto izdajo ECMAScripta najprej dodana nova funkcija JSON.parse(), ki jo od leta 2017 podpirajo vsi večji brskalniki. Za nepodprte brskalnike Crockford zagotavlja knjižnico JavaScript, združljivo z API-jem. Poleg tega je predlog TC39 »Subsume JSON« od revizije jezika leta 2019 ECMAScript uvrstil v strogo supermnožico JSON. Različne implementacije razčlenjevalnikov JSON so utrpele težave z napadi za zavrnitev storitev in ranljivostjo množičnega dodeljevanja.

JSON se promovira kot nizkoproračunska alternativa XML-u, saj imata oba formata široko podporo za ustvarjanje, branje in dekodiranje v resničnih situacijah, kjer se pogosto uporabljata. Glede na specifičen primer uporabe alternative JSON vključujejo:

• za besedilne formate, CSV in supermnožice JSON (glej spodaj). Ion ponuja tudi besedilni format, ki je supermnožica JSON (širši nabor primarnih tipov, opomb, komentarjev in omogočanje zaključnih vejic).
• za hitrejšo obdelavo na račun človeške berljivosti so med formati izmenjave podatkov, ki lahko izražajo vse objekte JSON, CBOR (standard IETF RFC) in dvojiški Ion. Tudi Googlov Protocol Buffers lahko zapolni to nišo zaradi možnosti razčlenjevanja brez sheme, vendar ni namenjen kot izmenjevalni jezik. Poleg tega imajo podatkovne zbirke, kot sta SQLite in PostgreSQL, svoje lastne notranje dvojiške predstavitve, imenovane »JSONB«, ki niso namenjene zunanji uporabi.

XML

XML se uporablja za opis strukturiranih podatkov in serializacijo objektov. Obstajajo različni protokoli, temelječi na XML, ki predstavljajo isto vrsto podatkovnih struktur kot JSON za isto vrsto izmenjave podatkov. Podatke je mogoče v XML kodirati na več načinov. Najobsežnejša oblika z uporabo parov oznak ima za posledico veliko večjo (po številu znakov) predstavitev kot JSON, če pa so podatki shranjeni v atributih in obliki kratkih oznak, kjer je zaključna oznaka zamenjana z />, je predstavitev pogosto približno enake velikosti kot JSON ali le malo večja. Vendar ima lahko atribut XML samo eno vrednost in vsak atribut se lahko na vsakem elementu pojavi največ enkrat.

XML ločuje podatke od metapodatkov (z uporabo elementov in atributov), medtem ko JSON nima takšnega koncepta.

Druga ključna razlika je naslavljanje vrednosti. JSON ima objekte s preprostim preslikavanjem ključa v vrednost, medtem ko se v XML naslavljanje dogaja na vozliščih, od katerih vsako prejme edinstven ID prek procesorja XML. Poleg tega standard XML definira skupni atribut xml:id, ki ga lahko uporabnik uporabi za eksplicitno nastavitev ID-ja.

Imena oznak XML ne smejo vsebovati nobenega od znakov !"#$%&'()*+,/;<=>?@[\]^`{|}~, niti presledka, in se ne smejo začeti z -, . ali številsko števko, medtem ko se ključi JSON lahko (tudi če morata biti narekovaj in poševnica ubežna).

Vrednosti XML so znakovni nizi znakov brez vgrajene tipske varnosti. XML ima koncept sheme, ki dovoljuje močno tipiziranje, uporabniško definirane tipe, vnaprej definirane oznake in formalno strukturo, kar omogoča formalno validacijo toka XML. JSON ima vgrajenih več tipov in podoben koncept sheme v shemi JSON.

XML podpira komentarje, medtem ko JSON ne.

TOML

TOML (»Tom's Obvious, Minimal Language« (prvotno »Tom's Own Markup Language«)) je datotečni format za konfiguracijske datoteke. Zasnovan je tako, da ga je enostavno brati in pisati, saj je minimalističen (za razliko od bolj kompleksnega YAML) in uporablja človeku berljivo skladnjo. Projekt standardizira implementacijo vseprisotnega formata datoteke INI (ki ga je v veliki meri nadomestil) in odpravlja dvoumnost pri njegovi interpretaciji.

Podpora za komentarje in druge funkcije se je izkazala za koristno, kar je privedlo do ustvarjanja več nestandardnih supermnožic JSON. Med njimi so HJSON, HOCON in JSON5 (ki kljub svojemu imenu ni peta različica JSON).

YAML

YAML različice 1.2 je supermnožica JSON  – prejšnje različice niso bile strogo združljive. Na primer, zamenjava ubežnega znaka (desne) poševnice / s povratno (levo) poševnico \ je veljavna v JSON, ni pa bila veljavna v YAML. YAML podpira komentarje, JSON pa ne.

CSON

CSON (»CoffeeScript Object Notation«) uporablja pomembno zamikanje in tipke brez narekovajev ter predpostavlja deklaracijo zunanjega objekta. Uporabljen je bil za konfiguriranje urejevalnika besedil Atom na GitHubu.

Obstaja tudi nepovezan projekt z imenom CSON (»Cursive Script Object Notation«), ki je skladenjsko bolj podoben JSON-u.

HOCON

HOCON (»Human-Optimized Config Object Notation«) je format za človeku berljive podatke in supermnožica JSON. Uporabe HOCON so:

• uporablja se večinoma skupaj s spletnim ogrodjem Play Framework, in ga je razvilo podjetje Lightbend.
• podprt je tudi kot konfiguracijski format za projekte .NET prek Akka.NET in Puppet.
• TIBCO Streaming: HOCON je primarna oblika konfiguracijske datoteke za družino izdelkov TIBCO Streaming (StreamBase, LiveView in Artifact Management Server) od različice TIBCO Streaming Release 10.
• je tudi primarna oblika konfiguracijske datoteke za več podsistemov programa Exabeam Advanced Analytics.
• Jitsi ga uporablja kot »nov« konfiguracijski sistem in za datoteke s priponami.properties kot rezervno možnost.

JSON5

JSON5 (»JSON5 Data Interchange Format«) je razširitev skladnje JSON, ki je, tako kot JSON, tudi veljavna skladnja JavaScript. Specifikacija se je začela leta 2012 in končala leta 2018 z različico 1.0.0. Glavne razlike v primerjavi s skladnjo JSON so:

• neobvezne zaključne vejice
• nenarekovani objektni ključi
• enojni narekovaji in mnogovrstični znakovni nizi
• dodatne oblike zapisa števil
• komentarji

Skladnja JSON5 je podprta v nekaterih programskih opremah kot razširitev skladnje JSON, na primer v prostem in odprtokodnem relacijskem pogonu podatkovne zbirke SQLite.

JSONC

JSONC (JSON with Comments) je podmnožica JSON5, ki se uporablja v Microsoftovem integriranem razvojnem okolju Visual Studio Code:

• podpira enovrstične komentarje (//) in blokovne komentarje (/* */)
• sprejema zaključne vejice, vendar se jih ne priporoča in urejevalnik bo prikazal opozorilo

Na podlagi specifikacije JSON ali iz nje je bilo zgrajenih več formatov serializacije. Primeri vključujejo:

• GeoJSON, format, zasnovan za predstavitev preprostih geografskih značilnosti
• JSON-LD, metoda kodiranja povezanih podatkov z uporabo JSON
• JSON-RPC, protokol za oddaljeno proženje procedur, kodiran v JSON
• JsonML, lahki označevalni jezik, ki se uporablja za preslikavo med XML in JSON
• Smile (format izmenjave podatkov)
• UBJSON, dvojiški format za izmenjavo računalniških podatkov, ki posnema JSON, vendar zahteva manj bajtov podatkov
• Jsonnet je domensko specifičen jezik, ki temelji na prototipih in ustvarja datoteke JSON. Vsi dokumenti JSON so veljavni programi Jsonnet, ki se bodo ob zagonu izdali nespremenjeni. Jsonnet razširja JSON s podporo spremenljivkam, uvozom, zankam, komentarjem itd. Jsonnet se uporablja kot konfiguracijski jezik za inženiring infrastrukture v oblaku.