YAML og TOON beskrives begge som "mer lesbare enn JSON" — og den beskrivelsen er teknisk sann for begge, noe som gjør den ubrukelig. Det virkelige spørsmålet er: lesbar for hvem, og til hvilket formål? YAML er optimalisert for menneskelig redigering: kommentarer, ankre, flerlinjesstrenger, innrykking som speiler hvordan utviklere tenker om konfigurasjon. TOON er optimalisert for maskinbehandling: minimale tokens, ingen tvetydighet, ingen syntaks som eksisterer rent for menneskelig komfort. Dette er forskjellige jobber. Å forveksle dem fører til YAML i LLM-prompter — som er verre enn JSON — og TOON i Kubernetes-manifester, som ingen ønsker å redigere for hånd. Denne artikkelen trekker linjen tydelig.

YAML i to setninger

YAML er et menneske-vennlig dataserialiseringsformat designet for konfigurasjonsfiler, CI/CD-pipelines og ethvert strukturert dokument en utvikler vil lese, skrive og vedlikeholde for hånd. Dets definerende funksjoner — inline-kommentarer, anker/alias DRY-mekanikk, flerlinjes strengliteraler og innrykksbasert struktur — eksisterer alle for å gjøre formatet behagelig for mennesker, ikke effektivt for maskiner.

De kanoniske brukstilfellene er GitHub Actions-arbeidsflyter, Kubernetes-manifester, Docker Compose-filer og applikasjonskonfigurasjon som leveres sammen med kode. Hvis et menneske forventes å åpne filen og redigere den, er YAML et sterkt valg. YAML 1.2-spesifikasjonen formaliserte en rekke edge cases som plaget YAML 1.1 — mest beryktet Norge-problemet, der landskoden NO ble parset som boolsk false i YAML 1.1-parsere. Moderne parsere som retter seg mot YAML 1.2 håndterer dette riktig, men det er en nyttig påminnelse om at YAMLs tilsynelatende enkelhet skjuler reell parserkompleksitet.

  • Kommentarer. # dette er en kommentar — YAML støtter inline- og hel-linjekommentarer. Dette alene gjør det til det riktige valget for enhver konfigurasjon et menneske vil vedlikeholde.
  • Ankre og aliaser. Definer en blokk én gang med &anchor, gjenbruk den overalt med *alias. Avgjørende for DRY Kubernetes-konfigurasjoner og multi-miljø CI-pipelines.
  • Flerlinjesstrenger. Literal (|) og foldet (>) blok-skalarer lar deg bygge inn shell-skript, SQL-spørringer eller sertifikatdata ryddig i en YAML-fil.
  • Lesbar innrykking. Struktur defineres av whitespace, som naturlig speiler hvordan utviklere tenker om nestede konfigurasjonshierarkier.
  • Svakheter. Innrykkssensitivitet betyr at et feilplassert mellomrom er en parse-feil. Tabulatortegn er forbudt. YAML 1.1 boolsk tvang (Norge-problemet, yes/no, on/off) har forårsaket virkelige produksjonsfeil. Tabelldata uttrykt som et array av objekter er mer ordrikt enn selv JSON.

TOON i to setninger

TOON er et kompakt serialiseringsformat designet for å sende strukturerte data til og fra store språkmodeller, der hvert token koster penger og kontekstvindueplass er begrenset. Dets nøkkelinnovasjon er tabellnotasjon: for datasett der hver post deler de samme feltene, erklæres nøkler én gang i en overskrift og utelates fra hver påfølgende rad — noe som er det motsatte av hva JSON og YAML gjør.

TOON er ikke et konfigurasjonsformat og var aldri ment å være det. Det finnes ingen kommentarsyntaks. Det finnes ingen ankre. Du ville ikke redigere et 500-raders TOON-datasett for hånd mer enn du ville redigere en binær fil for hånd. Det TOON gir deg er et format som koder den samme informasjonen som JSON i betydelig færre tokens — og færre tokens betyr lavere API-kostnader, større effektive datasett per prompt og mindre press på kontekstvinduegrenser. OpenAI-tokenizeren er den raskeste måten å se dette i praksis: lim inn det samme datasettet i begge formater og sammenlign.

  • Tabellnotasjon. name[count]{col1,col2,...}: etterfulgt av én rad med verdier per linje. Nøkler fremgår nøyaktig én gang uavhengig av radantall.
  • Objektnotasjon. {key:value,key2:value2} — ingen anførselstegn på nøkler, ingen ekstra whitespace.
  • Utvetydig parsing. Ingen boolsk tvang, ingen innrykkssensitivitet, ingen spesversjons-divergens.
  • Ingen kommentarsyntaks. TOON har ingen mekanisme for inline-kommentarer — av design. Det er et dataformat, ikke et dokumentformat.
  • Svakheter. Nisjeverktøy, ingen menneskeredigerings-historie, ikke egnet for filer en utvikler vil åpne og redigere direkte.

Side om side: de samme dataene i hvert formats element

Den mest ærlige sammenligningen viser hvert format som gjør det det faktisk er godt til — ikke tvinger en head-to-head der det ene er åpenbart feil verktøy.

Først et Kubernetes Deployment-manifest. Dette er YAMLs hjemmebane: en menneske-vedlikeholdt konfigurasjonsfil med kommentarer, ankre for delte verdier og dyp nesting som kartlegges til det logiske hierarkiet i et Kubernetes-objekt:

yaml
# Deployment manifest for the payments-service
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-service
  namespace: production
  labels:
    app: payments-service
    version: "2.4.1"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payments-service
  template:
    metadata:
      labels:
        app: payments-service
    spec:
      containers:
        - name: payments-service
          image: registry.example.com/payments-service:2.4.1
          ports:
            - containerPort: 8080
          env:
            - name: DB_HOST
              valueFrom:
                secretKeyRef:
                  name: payments-db-secret
                  key: host
            - name: LOG_LEVEL
              value: "info"
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

Å skrive det i TOON ville være meningsløst — det er ikke tabelldata, det vil bli redigert av mennesker, og det drar nytte av kommentarer som forklarer ikke-åpenlyse verdier. YAML er det riktige verktøyet her, og det er ingen konkurranse.

Nå de samme dataene i TOONs hjemmebane: et brukerdatasett som sendes til en LLM for analyse. Det er der TOONs tabellnotasjon gjør jobben:

text
users[12]{id,email,plan,mrr,country,signupDate,churned}:
  1001,[email protected],pro,99.00,US,2024-01-15,false
  1002,[email protected],starter,19.00,GB,2024-02-03,false
  1003,[email protected],enterprise,499.00,DE,2023-11-20,false
  1004,[email protected],pro,99.00,CA,2024-03-10,true
  1005,[email protected],starter,19.00,AU,2024-01-28,false
  1006,[email protected],pro,99.00,US,2023-12-05,false
  1007,[email protected],enterprise,499.00,FR,2024-02-14,false
  1008,[email protected],starter,19.00,IN,2024-03-22,true
  1009,[email protected],pro,99.00,US,2024-01-09,false
  1010,[email protected],enterprise,499.00,JP,2023-10-31,false
  1011,[email protected],starter,19.00,BR,2024-04-01,false
  1012,[email protected],pro,99.00,US,2024-02-19,true

Å skrive det som YAML — et array av 12 objekter, hvert med 7 nøkler — ville gjenta alle 7 nøkkelnavn 12 ganger. Det er 84 nøkkeldeklarasjoner for 84 verdier. TOON erklærer hver nøkkel én gang.

Der YAML slår TOON hver gang

Enhver fil et menneske vil åpne, lese og redigere hører hjemme i YAML (eller JSON, for enklere tilfeller). De avgjørende fordelene er kommentarer og ankre — to funksjoner TOON rett og slett ikke har.

  • CI/CD-pipelines. GitHub Actions, GitLab CI, CircleCI — alle YAML-native. Muligheten til å kommentere ut et trinn under feilsøking er genuint nyttig.
  • Kubernetes og Helm. Alle manifester, alle values-filer, alle chart-maler. YAML-ankersystemet brukes aktivt i komplekse Helm-charts for å unngå å gjenta miljøkonfigurasjoner.
  • Docker Compose. Multi-tjeneste-definisjoner med kommentarer som forklarer ikke-åpenlyse portbindinger, volummonteringer og nettverkskonfigurasjoner.
  • Applikasjonskonfigurasjonsfiler. pyproject.toml-stil-konfigurasjoner, applikasjonsinnstillinger, funksjonsflagger med forklarende kommentarer inline.
  • Enhver fil i versjonskontroll som mennesker gjennomgår i PR-er. Kommentarer i YAML-konfigurasjon er en del av dokumentasjonen. TOON kan ikke delta i denne arbeidsflyten i det hele tatt.
Merknad om ankre: YAML-ankre (&anchor) og aliaser (*alias) er underutnyttede, men kraftfulle. En Kubernetes-konfigurasjon som deler de samme miljøvariablene på tvers av flere containere, kan definere dem én gang med &common-env og referere til blokken med *common-env — holder filen DRY uten noen malmmotor. TOON har ingen tilsvarende mekanisme.

Der TOON slår YAML hver gang

Alle data som genereres programmatisk og sendes til en LLM hører hjemme i TOON. YAML er faktisk verre enn JSON for dette brukstilfellet — dens innrykksintensive syntaks og gjentatte nøkkelnavn legger til tokens uten å legge til noen informasjon modellen trenger.

  • LLM-prompt-payloads. Mating av et datasett til GPT-4o, Claude eller Gemini for analyse, klassifisering eller berikiing. TOONs tabellnotasjon kutter tokenantall med 40–60% sammenlignet med JSON, og sammenlignet med YAML er gapet enda større.
  • LLM-utdatainstruksjoner. Å instruere en modell til å svare i TOON produserer kortere, billigere utdata. YAML-utdata fra en LLM er ordrikt og innrykkssensitivt — ett feilplassert mellomrom og parsing bryter ned.
  • Programmatisk genererte datasett. Hvis koden din bygger dataene, bør den bygge TOON. Det finnes ingen menneskelig redaktør som drar nytte av kommentarer eller lesbar innrykking.
  • Høy-volum batchpipelines. Kjører du 10 000 poster gjennom en LLM per dag? En 50% tokenreduksjon er en 50% reduksjon i den linjen av API-regningen din.
  • Kontekstvindu-press. Når du trenger å passe mer data innenfor en modells kontekstgrense, lar TOON deg pakke inn flere rader til samme tokenkostnad.

Tokenantall-virkeligheten

Her er det samme 10-raders datasettet i tre formater. Tallene er omtrentlige, men konsistente med hva OpenAI-tokenizeren rapporterer for GPT-4os tokenisering.

YAML-array av objekter:

yaml
- id: 1
  username: alice_chen
  plan: pro
  mrr: 99.00
  country: US
- id: 2
  username: bob_martin
  plan: starter
  mrr: 19.00
  country: GB
- id: 3
  username: carol_white
  plan: enterprise
  mrr: 499.00
  country: DE
- id: 4
  username: dan_patel
  plan: pro
  mrr: 99.00
  country: CA
- id: 5
  username: eve_torres
  plan: starter
  mrr: 19.00
  country: AU
- id: 6
  username: frank_liu
  plan: pro
  mrr: 99.00
  country: US
- id: 7
  username: grace_kim
  plan: enterprise
  mrr: 499.00
  country: FR
- id: 8
  username: henry_obi
  plan: starter
  mrr: 19.00
  country: IN
- id: 9
  username: iris_novak
  plan: pro
  mrr: 99.00
  country: US
- id: 10
  username: james_sato
  plan: enterprise
  mrr: 499.00
  country: JP

TOON-tabellnotasjon, samme data:

text
users[10]{id,username,plan,mrr,country}:
  1,alice_chen,pro,99.00,US
  2,bob_martin,starter,19.00,GB
  3,carol_white,enterprise,499.00,DE
  4,dan_patel,pro,99.00,CA
  5,eve_torres,starter,19.00,AU
  6,frank_liu,pro,99.00,US
  7,grace_kim,enterprise,499.00,FR
  8,henry_obi,starter,19.00,IN
  9,iris_novak,pro,99.00,US
  10,james_sato,enterprise,499.00,JP
Omtrentlige tokenantall for dette datasettet: YAML ≈ 290 tokens. JSON (tilsvarende array av objekter) ≈ 230 tokens. TOON ≈ 115 tokens. YAML er ikke bare verre enn TOON — det er verre enn JSON for tabelldata, fordi dens innrykkssyntaks legger til tokens som JSONs klammeparenteser ikke gjør. TOON vinner med omtrent 2,5× over YAML og 2× over JSON på denne formen for data. Verifiser med OpenAI-tokenizeren.

Grunnen til at YAML klarer seg dårligere enn JSON på tabelldata er strukturell: YAML bruker én linje per nøkkel-verdi-par med innrykking, så et 5-felts objekt koster 5 linjer pluss listemarkøren. JSON omgir i det minste hele objektet i ett sett med klammeparenteser. TOON eliminerer nøkkelgjentakelse fullstendig — nøkler fremgår én gang, verdier pakkes inn i rader. Besparelsene vokser med radantall og feltantall.

Bruk av TOON i koden din

Pakken @toon-format/toon håndterer koding og dekoding:

bash
npm install @toon-format/toon
ts
import { encode, decode } from '@toon-format/toon';

// Your dataset — could come from a database query, API response, anywhere
const users = [
  { id: 1001, email: '[email protected]', plan: 'pro',        mrr: 99.00,  country: 'US' },
  { id: 1002, email: '[email protected]',   plan: 'starter',    mrr: 19.00,  country: 'GB' },
  { id: 1003, email: '[email protected]', plan: 'enterprise', mrr: 499.00, country: 'DE' },
  // ...more rows
];

// Encode to TOON before inserting into your LLM prompt
const toonPayload = encode(users);
// users[3]{id,email,plan,mrr,country}:
//   1001,[email protected],pro,99.00,US
//   1002,[email protected],starter,19.00,GB
//   1003,[email protected],enterprise,499.00,DE

const prompt = `Analyse this user dataset and identify churn risk signals.
Return your findings as a TOON dataset with columns: id, riskScore, reason.

Dataset:
${toonPayload}`;

// After the LLM responds with TOON output, decode it back
const llmResponse = '...'; // TOON string from the model
const findings = decode(llmResponse);
console.log(findings[0]); // { id: 1001, riskScore: 'low', reason: 'Active, pro plan' }

Beslutningsveiledning

Valget mellom YAML og TOON er nesten aldri tvetydig i praksis:

  • Bruk YAML hvis et menneske vil lese eller redigere filen — CI/CD-pipelines, Kubernetes-manifester, Docker Compose, applikasjonskonfigurasjon, Ansible-playbooks.
  • Bruk YAML hvis du trenger inline-kommentarer for å forklare ikke-åpenlyse verdier.
  • Bruk YAML hvis du trenger ankre og aliaser for å holde en kompleks konfigurasjon DRY.
  • Bruk YAML hvis du jobber med et verktøy som forventer YAML av konvensjon (Helm, GitHub Actions, k8s kubectl apply).
  • Bruk TOON hvis dataene skal inn i en LLM-prompt — spesielt tabelldata med flere rader.
  • Bruk TOON hvis du ber en LLM om å returnere strukturerte data og vil ha kortere, billigere utdata.
  • Bruk TOON hvis tokenantall betyr noe — høy-volum pipelines, lange datasett, kontekstvindu-press.
  • Bruk TOON hvis dataene genereres programmatisk og ingen mennesker vil redigere dem direkte.
  • Bruk JSON (ikke YAML eller TOON) hvis du bygger et REST API, lagrer data i en database eller integrerer med tredjepartsverktøy som forventer JSON.

Oppsummering

YAML og TOON okkuperer fullstendig forskjellige posisjoner i stacken din. YAML hører hjemme i repositoryet ditt ved siden av koden — konfigurasjonsfiler, pipeline-definisjoner, infrastrukturmanifester. TOON hører hjemme ved grensen mellom applikasjonen din og LLM API-er, der det konverterer de strukturerte dataene dine til den mest tokeneffektive representasjonen før sending og konverterer modellens svar tilbake på vei ut. Det er ingen meningsfull overlapp mellom disse jobbene, noe som er grunnen til at spørsmålet ikke er "hva er bedst" men "hva hører hjemme her".

Hvis du jobber med TOON, er TOON Formatter og TOON Validator den raskeste måten å inspisere og verifisere TOON-strenger på. JSON til TOON-konvertereren konverterer eksisterende JSON-payloads til TOON for LLM-bruk, og TOON til JSON-konvertereren håndterer returreisen når en modell svarer i TOON og det nedstrøms systemet ditt forventer JSON. Se også Wikipedia-artikkelen om YAML for en kortfattet historikk om formatet og en oppsummering av dets kjente edge cases.

← All TOON articles Browse all categories →