XPath, JSON y YAML

XSL es la familia de tecnologías pensada para transformar documentos XML. La idea de fondo es que un mismo documento de datos puede convertirse en muchas presentaciones distintas sin tocar los datos: basta con cambiar la hoja de transformación.

La pieza que se usa en la práctica es XSLT, de XSL Transformations. Es un lenguaje, escrito él mismo en XML, que describe reglas de transformación. Un procesador, como Apache Xalan, toma dos entradas (el documento XML de datos y la hoja XSLT) y las funde en una salida, que es otro documento de marcas: otro XML, un HTML o texto plano.

La otra pieza es XSL-FO, de Formatting Objects. Se diferencia en la salida: en vez de otro documento de marcas produce un entregable listo para imprimir o distribuir, típicamente un PDF o una imagen. El procesador de referencia es Apache FOP. Es la vía clásica para generar certificados o informes en PDF a partir de datos en XML.

XSLT produce marcado; XSL-FO produce un documento final maquetado. Si la pregunta habla de generar un PDF a partir de XML, la respuesta es XSL-FO.

XPath, de XML Path Language, es el lenguaje con el que se señala una parte concreta de un documento XML. No transforma ni valida: solo selecciona. Es la pieza sobre la que se apoyan XSLT para decidir a qué nodos aplica cada regla, los validadores y casi todas las API de proceso.

La forma más rápida de entenderlo es compararlo con los selectores de CSS, porque hacen lo mismo sobre árboles distintos. La sintaxis recuerda a una ruta de directorios: la barra baja un nivel y la doble barra busca a cualquier profundidad; los corchetes filtran; y la arroba indica que lo que sigue es un atributo, no un elemento.

En XPath las posiciones empiezan en 1, no en 0: el primer hijo es [1]. Es un error muy repetido en los apuntes, porque la costumbre de programar lleva a escribir [0].

La tabla enseña además dónde gana XPath: puede seleccionar un elemento por lo que contiene (todos los temas que tengan al menos un subtema) y puede recorrer hacia atrás, dos cosas que los selectores de CSS clásicos no permiten.

Para trabajar con un XML desde un programa hace falta un analizador, o parser. Hay dos enfoques radicalmente distintos, y la elección entre ellos es la pregunta clásica de este apartado porque no es de gusto: depende del tamaño del documento y de lo que se quiera hacer con él.

DOM es un estándar del W3C. El analizador lee el documento entero y construye en memoria un árbol de objetos que representa el documento completo. A partir de ahí el programa puede moverse libremente por el árbol, subir, bajar, añadir nodos, borrarlos o modificarlos, y volcar el resultado a un XML nuevo.

SAX funciona al revés. No construye nada: va leyendo el documento de principio a fin y, según encuentra cosas, avisa a una clase que el programador ha escrito previamente. Es lo que se llama un modelo de eventos: inicio de documento, inicio de etiqueta, texto, fin de etiqueta. El programa reacciona a esos avisos y decide qué guarda.

Si el documento es grande y solo hay que leerlo, SAX. Si hay que recorrerlo en varias direcciones o modificarlo, DOM. La memoria es lo que decide.

DOM y SAX tienen un inconveniente común: obligan a trabajar con nodos genéricos, no con los objetos del negocio. JAXB da un paso más y genera directamente objetos de las clases del dominio de la aplicación, de modo que en lugar de un nodo llamado Element se obtiene un objeto Alumno o un objeto Tema, con sus atributos y sus métodos.

Esas clases no hace falta escribirlas a mano: la utilidad xjc, que viene con el kit de desarrollo de Java, las genera automáticamente a partir de un esquema XSD. El esquema deja de ser solo un validador y pasa a ser también el contrato del que sale el código.

Los dos procesos que hay que saber nombrar son marshalling y unmarshalling, y se confunden constantemente porque la intuición los coloca al revés.

StAX es la variante de tirar en lugar de empujar. En vez de levantar el árbol de objetos entero, deja que sea el programador quien vaya pidiendo el siguiente trozo cuando lo necesita. Sirve para procesar en flujo, o streaming, y para construir un árbol solo con la parte del documento que interesa. Es el punto medio entre la comodidad de DOM y la frugalidad de SAX.

Marshall es del objeto al documento, como serializar. Unmarshall es del documento al objeto, como deserializar. El prefijo un- va del XML hacia dentro.

En el árbol que construye DOM todos los nodos comparten un mismo tipo general, Node, del que cuelgan varias especializaciones que conviene distinguir porque se preguntan por separado.

Document es un tipo instrumental: representa al documento completo y es el punto de entrada para crear nodos nuevos, pero no es un nodo real del árbol, sino su contenedor. Su propiedad documentElement apunta al elemento raíz de verdad, que en HTML es la etiqueta <html>.

• Apache Xerces es la implementación de referencia tanto del analizador DOM como del SAX.
• En Java, DocumentBuilder es el analizador DOM y SAXParser el de SAX.
• El API Trax se encarga del camino de vuelta: vuelca a XML el árbol DOM que hay en memoria, transformando un origen en un resultado.
• Para seleccionar nodos concretos dentro del árbol se usa XPath, que es al XML lo que los selectores son al CSS.

JSON, de JavaScript Object Notation, nació como la notación con la que se escriben los objetos en JavaScript y acabó convertido en estándar propio, la norma ECMA-404, con tipo MIME application/json. Ha desplazado a XML en el intercambio de datos entre navegador y servidor porque ocupa mucho menos, no lleva etiquetas de cierre y el navegador lo entiende de forma nativa.

Es un lenguaje sin esquema: por defecto no se valida contra ninguna gramática, y esa ligereza es parte de su atractivo. Cuando hace falta validar, existe la iniciativa JSON Schema, que persigue para JSON lo que XSD hace para XML.

• El nombre del atributo va SIEMPRE entre comillas, sin excepción.
• El valor va entre comillas solo si es una cadena.
• No hay tipo fecha: las fechas se escriben como cadenas, y por tanto entre comillas.
• El separador decimal es el punto; el separador de elementos, la coma.
• NaN significa Not a Number y es un valor de JavaScript, no de JSON.
• JSON no admite comentarios, a diferencia de XML y de YAML.

{
  "alumno": "A-4312",
  "curso": "largo",
  "ultimoIntento": {
    "tema": "aplicaciones-web-html-xml-y-scripting",
    "fecha": "2026-08-16T18:20:00Z",
    "aciertos": 18,
    "nota": 8.5,
    "superado": true,
    "observaciones": null
  },
  "preguntasFalladas": ["q3", "q7", "q9"]
}

Para procesarlo desde Java las librerías clásicas son Jackson y GSON, esta última de Google. En el estándar de la plataforma hay dos API: JSON-B, de alto nivel, que enlaza el JSON con las clases del dominio como hace JAXB con XML, y JSON-P, de bajo nivel, que trabaja con la estructura del documento.

El error más repetido en los ejercicios de JSON es dejar sin comillas el nombre de un atributo o ponerle comillas a un número. El nombre siempre va entrecomillado; el valor, solo si es cadena.

El uso de JSON que más se pregunta fuera del intercambio de datos es la autenticación web, mediante el JSON Web Token o JWT. Es una credencial que el servidor emite tras validar al usuario y que el cliente devuelve en cada petición dentro de la cabecera Authorization, precedida de la palabra Bearer.

El token son tres trozos separados por puntos, cada uno codificado en base64url. El primero es la cabecera, un objeto JSON que dice qué algoritmo lo firma y qué tipo de token es. El segundo es la carga útil, otro objeto JSON con las afirmaciones sobre el usuario: quién es, cuándo se emitió, cuándo caduca. Y el tercero es la firma, que se calcula sobre los dos anteriores con una clave que solo conoce el servidor.

// Estructura de un JWT: cabecera.carga.firma
// Cabecera:  { "alg": "HS256", "typ": "JWT" }
// Carga:     { "sub": "A-4312", "curso": "largo", "exp": 1789000000 }
// Firma:     HMACSHA256( base64url(cabecera) + "." + base64url(carga), secreto )

fetch("/api/intentos", {
  headers: { "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." }
});

La cabecera y la carga de un JWT van codificadas en base64url, no cifradas: cualquiera puede leerlas. Lo que la firma garantiza es que nadie las ha alterado, no que sean secretas. Nunca se mete un dato sensible en la carga.

Los lenguajes de marca ligeros son formatos de sintaxis más simple que XML, pensados para escribir documentación con muy pocos caracteres y obtener aun así un documento presentable en la web. Los dos que hay que citar son Markdown, con extensión .md, y reStructuredText, con extensión .rst.

YAML, por su parte, es un formato de serialización legible por personas. Su nombre es un acrónimo recursivo: YAML Ain't Markup Language, es decir, YAML no es un lenguaje de marcado, declaración con la que sus autores quisieron subrayar que su objetivo son los datos y no el documento. La estructura la marca la sangría, no las llaves ni las etiquetas.

# YAML admite comentarios, y JSON no
tema: aplicaciones-web-html-xml-y-scripting
bloque: 3
nivel: 1
subtemas:
  - slug: xml-bien-formado-y-valido
    preguntas: 9
  - slug: javascript-dom-y-eventos
    preguntas: 9

• Definir un API REST en formato Swagger u OpenAPI.
• Escribir un playbook de Ansible.
• Describir el entorno de trabajo de un desarrollador con Docker Compose.