Pobre XML...

En los últimos días se le estuvo pegando bastante a XML en este blog.

Primero fue XML * Inconciencia, donde referenciaba un post de Lucas Ontivero con malas prácticas y delirios malos con XML.

Luego fue XML donde citaba "XML is like Violence, if it doesn't solve the problem, use some more".

Y encima estoy preparando un post sobre mi propio aprendizaje de XML, que se dio a través de la construcción de una aplicación web que almacenaba sus datos enteramente en XML... muchas frases en el estilo de "estaba aprendiendo" y un alto contenido de "mea culpa".

A ver, XML es una herramienta fabulosa, fácil de entender (casi intuitivo si uno viene del viejo mundo HTML), popular (con mucha documentación y herramientas disponibles), ampliamente utilizada (es *EL* estándar para intercambio de información entre aplicaciones) y sobre todo flexible.

Lo mismo que Javascript, ASP 3.0, PHP... antes de saltarme al cuello déjenme explicar qué les veo en común todos estos lenguajes: en todos ellos, sobre todo cuando se los ve junto a HTML o XML, es frecuente el abuso de alguna de sus características, sobre todo de aquellas que nos permiten esquivar rápidamente los tipos de datos o que tienen que ver con la ejecución de código generado "on the fly", o con el pasaje de datos del servidor al cliente, en divertidísimas combinaciones.

Creo que para muestra basta un botón. El ejemplo es una hermosa combinación de ASP 3.0, HTML y Javascript (¡qué lindos colores!). Lástima que no se me ocurrió generar XML embebido en la misma página.

El problema no está en la herramienta sino en cómo es utilizada, sobre todo en manos de un principiante (el código de ejemplo es mío, así que créanme que sé de lo que hablo). Como no me canso de repetir, ser un "junior" no implica solamente el manejo de una herramienta. Para el caso, en el momento en que escribí eso (que podemos llamar... un colorido desastre) tenía bastante idea de HTML, ASP y Javascript, pero no tenía la más mínima idea de cómo construir una capa de presentación en una aplicación web medianamente compleja, con lo cual terminé abusando de todo lo que sabía.

Uno puede saber todo sobre XML, pero se necesita bastante práctica para crear un documento coherente. Como la herramienta nos permite hacer casi cualquier cosa, estamos librados a nuestro criterio al momento de producir algo legible, que dependerá de nuestra comprensión teórica del modelo: ¿cuándo un dato es un atributo? ¿cuándo debe ser un nodo? ¿cuándo tengo que englobar varios nodos en un nuevo nivel?

También se necesita práctica para saber cuándo parar. Con XML podemos hacer de todo, pero eso no significa que debamos hacer de todo. En los post que mencionaba al principio se menciona el caso del sistema con una tabla única con dos campos del tipo "ID" y "XMLData" en el que se guardaban todos los datos de la aplicación. A ese tipo de cosas me refiero cuando menciono "saber cuándo parar".

Ésas no son preguntas fáciles de responder, y los programadores con poca experiencia tienden a subestimar las consecuencias, argumentando que son "bla bla bla teórico" y que "de cualquier manera funciona"... Algunos programadores con mucha experiencia piensan lo mismo, desgraciadamente. Son los que Rafael Gil en un momento de inspiración nombra "Programadores Romario" en su blog "Diario de un Director de sistemas".

Creo que el título XML * Inconciencia es perfecto. El problema es la inconciencia. De alguna manera todo el mundo reconoce que diseñar una base de datos es difícil, y que un error puede tener un serio impacto a futuro, así que en general se le presta la debida atención. Esto no sucede tan seguido con el XML (aunque diseñar un documento es prácticamente lo mismo que diseñar una base de datos), hay casos en los que se supone que es una herramienta sencilla y fácil de usar que nos puede sacar de apuros y que no merece mayor análisis. Termina siendo una navaja nueva para un monito aburrido.

En algún otro post comentaré con más detalle los casos en los que sí se utilizó XML razonablemente con muy buenos resultados, por ahora simplemente una lista:

• Para archivos de configuración de la aplicación del tipo "web.config" o "app.config". Son el equivalente a los viejos archivos ".ini". La ventaja es que el XML documenta muy bien las secciones y los valores que puede tomar cada parámetro.
• Para guardar datos que hacen a la estructura de la aplicación. Por ejemplo la relación entre página-controlador en un patrón MVC.
• Para guardar parámetros por defecto que necesita la aplicación.
• Como alternativa a los archivos de recursos (del tipo ID+Cadena) cuando se necesitan almacenar datos complejos.
• Por supuesto, para intercambiar datos entre aplicaciones. Pero con cuidado, no puede ser gran cantidad de información (XML es muy ineficiente en cuanto a tamaño) y, sobre todo, que sea simple: descargo a un archivo la información (o cualquier equivalente) y punto.

Dos puntos importantes:

• Mantener siempre actualizada la documentación sobre la estructura del archivo. Si es un XSD o un DTD, mejor. Si la aplicación lo valida al levantar los datos, perfecto.
• Siempre encapsular el archivo en una clase que devuelva los datos tipados al resto de la aplicación. Es fácil, no cuesta nada, mucho más cómodo que buscar todo el tiempo en XML (por ejemplo utilizando XPath en todos lados) y encima ahorra un montón de problemas a futuro, permitiéndonos cambiar la estructura del archivo prácticamente sin impacto.

Como conclusión: XML es grandioso. Pero, como toda herramienta, no puede ser utilizada a la ligera. Es tan fácil y divertido como buscar un poco en Google antes de empezar.