El 13 de marzo de 2026, el IRS publicó en GitHub el código fuente de su nueva calculadora de retención de impuestos. Nadie esperaba que el lenguaje en el corazón del sistema fuera XML. No Python, no JavaScript, no un motor de reglas moderno. XML.
El ingeniero líder del proyecto publicó un artículo explicando por qué. Y aunque el título suena técnico y el caso de uso es el código tributario de EE.UU., las lecciones que entrega son directamente aplicables a cualquier startup o equipo técnico que necesite modelar lógica de negocio compleja: tarifas dinámicas, reglas de elegibilidad, flujos de aprobación, condiciones de precios.
¿Qué tiene XML que JSON no tiene?
En la mayoría de los proyectos modernos, JSON ganó la batalla de los formatos. Es compacto, tiene soporte nativo en JavaScript y todo el mundo lo entiende. Pero hay un tipo de problema donde JSON empieza a mostrar sus límites: cuando necesitas representar lógica declarativa con árboles de dependencias y condiciones anidadas.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀El artículo muestra el ejemplo concreto de calcular el total owed —lo que debes al fisco al final del año—. En JavaScript imperativo, la lógica crece rápido: cálculos en cadena, dependencias de orden, manejo especial de colecciones. El código mezcla detalles de implementación con la lógica del dominio fiscal, y perder de vista uno o dos nodos puede introducir un error que nadie detecta hasta que alguien paga impuestos de más.
En XML declarativo, la misma lógica queda como:
<Fact path="/totalOwed">
<Derived>
<Subtract>
<Minuend><Dependency path="/totalTax"/></Minuend>
<Subtrahends><Dependency path="/totalPayments"/></Subtrahends>
</Subtract>
</Derived>
</Fact>Verbose, sí. Pero completamente auditable. El motor de ejecución decide cómo y en qué orden correr los cálculos. Las reglas se pueden navegar con XPath, validar con XSD, consultar desde bash con un one-liner, y generar vistas alternativas sin tocar el motor. Todo eso viene gratis con XML.
¿Por qué no JSON, YAML o algo más moderno?
El artículo hace la comparación honestamente. JSON falla porque no tiene una forma nativa de expresar árboles con tipos propios: cada nodo hijo necesita declarar explícitamente qué tipo de objeto es, lo que genera un JSON más verboso que el XML original y mucho menos legible. Sin comentarios, sin whitespace sano para texto largo, sin XSD para validación de esquema.
YAML parece más legible, pero el autor del motor de reglas original lo descartó directamente: “whatever you do, don’t try to express the logic of the Internal Revenue Code as YAML.” El problema no es la sintaxis sino que YAML no tiene el mismo ecosistema de herramientas maduras para transformar, consultar y validar estructuras complejas.
S-expressions (Lisp) y KDL son alternativas visualmente más limpias, pero carecen de lo más importante: un parser universal disponible en prácticamente cualquier lenguaje, con décadas de tooling estable detrás. XML tiene XPath, XSLT, XSD, editores en todos los IDEs, y soporte nativo o bindings en cualquier stack.
Eso es exactamente lo que el artículo llama un DSL “barato”: no porque sea fácil de leer, sino porque no necesitas construir nada extra. El compilador, el validador, la capa de introspección, todo ya existe. Puedes enfocarte en modelar tu dominio.
La prueba práctica: tres preguntas antes de elegir tu formato
El caso del IRS no es el único. Maven, Ant, los layouts de Android, Office Open XML, SVG, WSDL y SOAP —todos usan XML como DSL porque la separación entre las reglas y el motor de ejecución tiene valor real. No es nostalgia por J2EE.
Para cualquier equipo construyendo sistemas con lógica de negocio cambiante, el artículo sugiere hacerse estas tres preguntas antes de decidir cómo representar las reglas:
- ¿Con qué frecuencia cambian estas reglas? Si actualizas tarifas, condiciones o tramos regularmente, separar las reglas del motor que las ejecuta no es ingeniería de más: es la diferencia entre editar un archivo XML y desplegar código nuevo.
- ¿Quién más, además de devs, necesita leer o modificar estas reglas? Un analista de negocio, un abogado o un regulador puede aprender a leer XML si el schema está bien diseñado. No puede leer JavaScript con maps y reduces anidados.
- ¿Necesitas auditabilidad? Si alguien puede preguntarte “¿cómo llegaste a ese número?”, un grafo declarativo de dependencias te da la trazabilidad gratis. Un programa imperativo te obliga a agregar logging explícito en cada paso.
Si respondiste sí a cualquiera de las tres, XML como DSL merece estar en la conversación. No porque sea elegante, sino porque es práctico de una forma que los formatos más modernos todavía no replican con el mismo nivel de madurez.
Por qué importa ahora
El contexto es 2026 y la IA genera código a una velocidad que hace difícil mantener la lógica de negocio legible y auditable. Precisamente por eso, el principio que demuestra este artículo se vuelve más relevante: separar las reglas de su ejecución es una decisión arquitectural que protege la mantenibilidad a largo plazo, independientemente de quién o qué escribió el motor.
Si estás construyendo un contrato de API que necesita evolucionar sin romper clientes, o simplificando tu stack hacia herramientas que hacen más con menos, el principio es el mismo: elige la solución más barata que resuelva el problema correcto, aunque lleve 30 años entre nosotros.
