¿Qué significa que XML sea un DSL ‘barato’?
En el mundo del desarrollo de software, la búsqueda del lenguaje ideal para modelar reglas de negocio complejas es constante. El artículo XML Is a Cheap DSL de unplannedobsolescence.com plantea una tesis provocadora pero bien fundamentada: XML sigue siendo una de las opciones más eficientes para construir un lenguaje de dominio específico (DSL), especialmente cuando se trata de modelar lógica tan compleja como el código tributario de Estados Unidos.
El caso de estudio central es el Tax Withholding Estimator del IRS, una herramienta de código abierto que utiliza XML para codificar las reglas de retención de impuestos federales —miles de líneas de tablas, tramos y condiciones derivadas directamente de la Publicación 15-T del IRS—. El enfoque no es accidental: XML fue elegido porque resuelve un problema concreto de la forma más directa posible.
El argumento central: XML elimina la fricción del parsing
Una de las principales ventajas que el artículo destaca de XML como DSL es su ecosistema de herramientas maduras y universales. A diferencia de formatos emergentes o de sintaxis personalizadas, XML viene con:
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad- Parsers estándar disponibles en prácticamente todos los lenguajes de programación.
- XPath y XSLT para navegar y transformar estructuras de forma declarativa.
- XSD (XML Schema Definition) para validar que las reglas definidas cumplen con la estructura esperada, atrapando errores antes de llegar a producción.
En palabras simples: no necesitas construir un compilador ni un validador personalizado. El lenguaje ya trae todo eso incluido, lo que lo hace un DSL «barato» en términos de costo de implementación y mantenimiento.
Declarativo vs. Imperativo: por qué importa para la lógica de negocio
El corazón del debate está en el paradigma. Cuando el código tributario se implementa de forma imperativa (por ejemplo, en JavaScript puro con bucles y condicionales), el resultado es código que mezcla la lógica del dominio con detalles de implementación. Esto genera tres problemas críticos para equipos técnicos en startups y organismos públicos:
- Dificultad de auditoría: Un experto en impuestos no puede leer ni validar el código directamente.
- Rigidez ante cambios: Cada actualización anual del código fiscal implica refactorizaciones peligrosas.
- Acoplamiento plataforma: La lógica queda atada a un lenguaje o framework específico.
El enfoque declarativo con XML resuelve los tres: las reglas se expresan como datos estructurados («si el ingreso supera X, aplicar tasa Y»), separadas del motor de ejecución. Esto permite que un analista fiscal valide las reglas sin conocer programación, que los cambios anuales se implementen editando un archivo XML, y que el mismo conjunto de reglas sea ejecutado por diferentes plataformas (web, móvil, APIs).
XML vs. las alternativas: una comparación honesta
El artículo no ignora a los competidores. Aquí un resumen de por qué XML resulta ganador para este caso de uso específico:
JSON
JSON es más compacto y tiene soporte nativo en JavaScript, pero carece de comentarios nativos, de un sistema de validación de esquemas tan robusto como XSD y de herramientas de transformación equivalentes a XSLT. Para reglas de negocio complejas con condiciones anidadas, JSON se vuelve difícil de leer y auditar.
JavaScript
Usar JavaScript directamente —el lenguaje del propio Tax Withholding Estimator— significaría codificar la lógica tributaria de forma imperativa. El problema es la «barrera simbólica»: la lógica de dominio queda mezclada con detalles de implementación, elevando el riesgo de errores y dificultando la participación de expertos no técnicos.
S-Expressions (Lisp) y Prolog
Las s-expressions son expresivas y homoicónicas, pero su legibilidad fuera del ecosistema Lisp es limitada. Prolog, aunque naturalmente declarativo para inferencia lógica, tiene una curva de aprendizaje pronunciada y un ecosistema de herramientas reducido comparado con XML.
KDL
KDL es un formato moderno y legible, pero al ser emergente carece del ecosistema de parsers, validadores y editores que XML ha acumulado durante décadas. Para software público que necesita durabilidad y amplio soporte, esto es un riesgo real.
Usos reales de XML como DSL en software público y automatización
Este patrón no es exclusivo del IRS. XML como DSL tiene precedentes sólidos en software ampliamente adoptado:
- Maven y Ant: configuración declarativa de builds en proyectos Java.
- Android layouts: definición de interfaces de usuario en XML, validadas por esquemas.
- Office Open XML (OOXML): la estructura de documentos Word y Excel es un DSL en XML.
- WSDL/SOAP: contratos de APIs y servicios web interoperables.
- SVG: gráficos vectoriales escalables como lenguaje declarativo sobre XML.
Todos estos casos comparten una característica: la lógica o la estructura del dominio se expresa de forma separada de su ejecución, con herramientas de validación incluidas.
¿Qué puede aprender un founder de esto?
Para un founder tech que diseña sistemas con reglas de negocio complejas —tarifas dinámicas, flujos de aprobación, reglas de elegibilidad, lógica de precios—, el artículo ofrece una lección poderosa: no siempre necesitas un lenguaje nuevo o una solución de moda para modelar tu dominio.
Antes de optar por un motor de reglas de pago, un microlenguaje personalizado o embeber toda la lógica en código imperativo, vale la pena preguntarse:
- ¿Qué tan seguido cambian estas reglas?
- ¿Quién además de los devs necesita leerlas o modificarlas?
- ¿Necesito que sean auditables por terceros (reguladores, clientes, inversores)?
Si la respuesta a alguna de estas preguntas es «sí», un DSL declarativo en XML puede ser la solución más pragmática y duradera disponible, sin costos de licencias y con décadas de tooling maduro respaldándote.
Conclusión
El artículo XML Is a Cheap DSL es una defensa inteligente y práctica de una tecnología que muchos dan por obsoleta. A través del caso real del Tax Withholding Estimator del IRS, demuestra que XML sigue siendo una opción legítima, eficiente y auditabledel para modelar lógica de dominio compleja en software público —y por extensión, en cualquier sistema donde la separación entre reglas de negocio e implementación sea crítica.
Para el ecosistema startup, la lección va más allá de XML: se trata de elegir las herramientas correctas para el problema correcto, priorizando claridad, mantenibilidad y apertura sobre la novedad tecnológica. En un mundo donde la automatización y el software público ganan relevancia, estos principios son más vigentes que nunca.
Descubre cómo otros founders implementan estas soluciones de automatización y DSL en sus productos. Únete gratis a la comunidad de Ecosistema Startup.
Fuentes
- https://unplannedobsolescence.com/blog/xml-cheap-dsl/ (fuente original)
- https://martinfowler.com/articles/languageWorkbench.html (fuente adicional)
- https://en.wikipedia.org/wiki/Domain-specific_language (fuente adicional)
- https://opensource.com/article/20/2/domain-specific-languages (fuente adicional)
