El sustituto de JSON

El problema, en sí, es solucionar el problema del intercambio de datos. La idea principal es crear un sistema que sea legible por humanos, y dotarle de algún tipo de estructura que permita representar datos complejos. Por ejemplo, la NASA se encontró con múltiples dificultades cuando quiso digitalizar los datos históricos, desde el soporte hasta el formato en sí mismo. Si tus datos, en cambio, están almacenados en texto, el hecho de perder las herramientas para procesar esos datos no es realmente importante.

Muchas veces, si tenemos que mandar datos tabulares de un ordenador a otro, se utilizaba CSV (Comma Separated Values, o valores separados por comas). Por ejemplo:

Productos, Mes, Ventas
"Zapatos", 1, 45
"Pendientes", 1, 96
"Cinturones", 2, 35

La idea es muy básica: darle estructura al texto, de manera que podamos organizar los datos que enviamos. Pero en el final de los 1990, XML tomó el mundo (todo el mundo), al asalto. XML se utilizó para archivos de intercambio, archivos de configuración... para todo.

<ventas>
    <mes id="1">
        <producto nombre="Zapatos">45</producto>
        <producto nombre="Pendientes">96</producto>
    </mes>
    <mes id="2">
        <producto nombre="Cinturones">35</producto>
    </mes>
</ventas>

No está mal, pero una de las características de XML es que es... muy verboso. Muchos caracteres: abrir y cerrar etiquetas tiene su coste, claro. Aunque la información está mejor organizada, de forma más determinista que con CSV, el exceso de texto lo hace demasiado engorroso.

Claro, CSV precisa que los datos a enviar sean tabulares, mientras que XML puede adaptarse a cualquier tipo de información, tabular o no.

El siguiente paso fue JSON, alrededor de 2005, y se basa en JavaScript. JSON tiene varias ventajas. No es tan verboso, principalmente porque no es necesario abrir y cerrar etiquetas. Además, la sintaxis permite utilizar varios tipos de datos: números (enteros y reales), booleanos, texto...

"ventas": {
    "meses": [
        {
            "id": 1,
            "productos": [{
                "nombre": "Zapatos",
                "ventas": 45
            },{
                "nombre": "Pendientes",
                "ventas": 96
            }]
        },
        {
            "id": 2,
            "productos": [{
                "nombre": "Cinturones",
                "ventas": 35
            }]
        }
    ]
}

JSON es mucho más intuitivo que XML, más directo; pero no está exento de problemas en cuanto a ser o no escueto: todos los meses tienen los mismos campos en ese caso, y sin embargo, es necesario volver a especificarlos de nuevo.

YAML es otro lenguaje de formato de datos que da estructura al texto, y sus siglas significan que no es un lenguaje de marcado (?). Este formato ha ganado gran popularidad. De nuevo, se trata principalmente de ser todavía más escueto.

meses:
  - id: 1
    productos:
      - nombre: Zapatos
        ventas: 45
      - nombre: Pendientes
        ventas: 96
  - id: 2
    productos:
      - nombre: Cinturones
        ventas: 35

Aunque también repite los nombres de los campos, es cierto que es más escueto que JSON. Aún así, no está exento de problemas. Por ejemplo, mientras los datos en XML o JSON pueden introducirse en una sola línea (los espacios o cambios de línea no son significativos), aquí los cambios de línea y los espacios antes de cada línea son significativos. En este sentido, el propio formato indica también la única forma de visualizarlo, en concreto la indentación indica qué elementos están dentro de otros, pero a la vez lo hace legible. Esto suele considerarse tanto un problema como una ventaja.

Por supuesto, la comunidad no se ha parado en estos formatos, otros han ido surgiendo. Por ejemplo, TOML se basa más o menos en el antiguo formato INI de configuración de Windows.

Pero ahora, según parece, ha surgido otra necesidad. El problema es que las aplicaciones de IA cuantifican por los tokens del prompt de entrada la envergadura del trabajo a realizar, por lo que es necesario un formato que sea tan escueto como sea posible. Y por eso aparece TOON. TOON se basa vagamente en YAML (de forma que los espacios precedentes, y los cambios de línea son significativos), pero utiliza CSV para las listas.

meses[2]:
  - id: 1
    productos[2]{nombre,ventas}:
      Zapatos,45
      Pendientes,96
  - id: 2
    productos[1]{nombre,ventas}:
      Cinturones,35

Cuando tomé conciencia de la existencia de este formato, y vi sus ejemplos, hubo algo que me produjo auténtica urticaria: es necesario especificar el número de elementos de las listas, aunque no es necesario, en cambio, repetir continuamente los nombres de los campos.

Además, hay algo que me molesta en el campo de la informática: siempre se prefiere algo (un formato, un lenguaje de programación...) totalmente nuevo, en lugar de extender lo ya existente. TOON se parece mucho a YAML, ¿no? ¿Por qué no extenderlo para no tener que repetir los nombres de los campos?

meses:
  - id: 1
    productos<nombre, ventas>:
      - Zapatos, 45
      - Pendientes, 96
  - id: 2
    productos<nombre, ventas>:
      - Cinturones, 35

En fin, supongo que habrá gustos y opiniones para todo el mundo, pero creo que la famosa viñeta de XKCD sobre estándares se impone.