Enlaces interesantes (algunos relacionados =) ) (y que auspician sin saberlo esta página):
Nunca fue una tarea fácil en la computación el mover información de un lugar a otro. La información queda generalmente fuertemente ligada al programa con que fue creada, y es así como se pierde mucho tiempo en pasar de Word a Excel a Quatro Pro a páginas HTML a lo-que-sea. Y además esa información está también fuertemente ligada a cómo quiso verla el que la creó. Muchos seguramente han tenido que sobrellevar la ardua tarea de reacomodar un documento de Word hecho por un neófito, usando espacios en vez de tabs o poniendo enter al final de cada renglón… =).
Sería conveniente entonces disponer de algún mecanismo para tener información pura. ¿Sirve usar sólo texto? No, porque la información tiene su propia estructura interna que es importante preservar, más aún si debemos manejar colecciones importantes de muchos documentos similares en su tipo. Deberían poderse extraer fácilmente todos los títulos de los documentos de una colección así.
Un ejemplo sencillo (y quizá trillado): una colección de 750 recetas de cocina. ¿Escribirlas todas en Word? ¡Qué peligro! ¿Qué pasaría si me dicen que es necesario tenerlas en HTML? ¿O imprimirlas en un libro usando programas específicos y cierto estilo de tipografía para los ingredientes? Entonces es conveniente poner mayor atención al elegir el formato a emplear. ¿Sólo texto? nah… es evidente que una receta se divide en partes bien identificadas, así que usar sólo texto es perder información, y estamos acá para tratar de guardar la mayor cantidad.
XML nos dice que podemos estructurar la información en un árbol. Es decir imaginar a la receta como un componente, que a su vez esta formado de componentes, y así sucesivamente. Cada componente podría tener texto y/o más componentes. ¿Se entiende? Una posible estructura sería imaginar que la receta tiene un componente llamado necesitamos. No todo el texto estaría dentro de necesitamos, solamente aquellas cosas que el potencial ejecutor de la receta necesitaría para llevarla a cabo exitosamente. Dentro podríamos tener uno o más componentes llamados ingrediente. Veamos como se ve esto (usando ya la sintaxis de XML).
<receta>
…
<necesitamos>
<ingrediente>2 cucharadas de azúcar</ingrediente>
<ingrediente>3 manzanas</ingrediente>
</necesitamos>
…
</receta>
¿Se adivina cuál es la sintaxis de XML? Es simplemente encerrar al texto que pertenece a un componente entre <componente> y </componente>. Bueno, en realidad nadie les llama componentes, a cada uno de estos bichos se les suele decir elemento, y las marcas que marcan su comienzo y su fin son etiquetas o tags.
El círculo se completa mediante una hoja de estilo, que es una descripción de como debe verse una información en determinado medio. A un mismo documento XML se le pueden aplicar distintas hojas de estilo según convenga. Por ejemplo usando una hoja de estilo por cada medio en la que se debe representar la información. Una para imprimir un libro, otra para una página web y otra para un programa que lee la información en voz alta. Las primeras dos dirán algo así:
En cambio, una hoja de estilo destinada a formatear la información para su lectura en voz alta tendrá algo así como
También podría controlarse el volumen, o incluso de qué lado viene la voz.
Si bien no sé hasta qué punto está implementado esto, es interesante ver esta propuesta de hojas de estilo aurales que hicieron los que establecen los estándares en la web.
Las hojas de estilo también pueden controlar la conversión de esta
“información pura” en formatos más pedestres, como RTF
(para usar con el Word), HTML, etc. De esta manera, cuando ya tenga las 750
recetas tipeadas y puestas en la web mediante una hoja de
estilo adecuada, y alguien me diga Me traés todo mañana en tal formato
para publicar un libro
, yo podré responder orgulloso: ¡Claro que
sí!
.
Existen actualmente dos lenguajes de hojas de estilo, y los describo
brevemente a
continuación.
Uno de ellos es el bastante conocido CSS (Cascading Style Sheets), que ya está parcialmente implementado en los navegadores actuales más importantes. Este lenguaje simplemente permite definir como deben tratarse los tags. Solamente se pueden brindar indicaciones simples como… ponés eso de rojo, y esto de azul y grande.
Una descripción en CSS se ve más o menos así:
ingrediente {
font-family: sans-serif;
color: red;
}
El W3 Consortium creó nuevo lenguaje de hojas de estilo llamado XSL (eXtended Stylesheet Language) que además de lo que brinda el CSS tiene la capacidad de funcionar como un lenguaje de transformación, alcanzándose la funcionalidad que describía más arriba.
XSL es en verdad dos estándares muy diferentes:
Es un lenguaje que describe cómo debe transformarse un archivo XML en otro archivo XML. Por ejemplo, un archivo conteniendo tags que describen una receta puede convertirse mediante este sistema a otro archivo conteniendo tags que solamente describen la posición del texto en una página impresa. Obviamente en semejante transformación hay información que se pierde. La idea es que aplicando diferentes archivos XSLT se puedan obtener archivos XML diferentes, adecuados a diferentes presentaciones o usos de la información.
La versión 1.0 de esta parte del estándar fue publicada en 1999, y existen varias implementaciones de diferente calidad.
FO quiere decir formatting objects. Un archivo XSLFO es una especie de HTML muy sucio de tags de colores, tamaños y posición. Es un archivo que no preserva nada de la semántica de la información original, solamente describe como debe mostrarse en pantalla, o en papel. Es similar en concepto al lenguaje PostScript, o quizá al TEX.
Este formato, que obviamente es un formato XML, se puede usar generándolo mediante una transformación XSLT. Siguiendo el ejemplo que usé antes ya podemos describir un circuito bastante completo de lo que pasa con la información:
Esta parte del estándar es un trabajo en progreso y todavía ningún browser está ni cerca de soportarlo. El tiempo dirá si se convierte en un estádar de la industria o no. Lo que sí se está empezando a usar mientras tanto como lenguaje presentacional es XML+CSS. Es decir, del limpio, lindo y buen XML generar sucio HTML, que no es otra cosa que un lenguaje presentacional… no está tan mal.
Otras tecnologías asociadas son DOM (Document Object Model) y SAX, que son APIs estándares para acceder a los "árboles" de información XML.
A partir de aquí ya le estoy hablando a los programadores, están avisados.
Vamos a ver también que la pantalla no es el único destino
posible de un documento XML. Estos archivitos se usan muy fácilmente
como entrada para programas. Las recetas del capítulo anterior,
podrían, en algún otro siglo, activar un plugin conectado a un
robot, replicador o lo que sea encargado de ejecutarla automáticamente
=).
Esto suena quizá demasiado loco, pero en el caso del
MathML, que va
a distribuir ecuaciones matemáticas semánticamente, tiene mucho
sentido mover el mouse sobre la ecuación, y en el menú del
botón derecho decirle al browser: despejame x por favor
.
Todos trabajamos alguna vez con archivos CSV (de campos separados por comas o tabs) producidos por una hoja de cálculo. Los archivos CSV pueden ser muy útiles para llevar información de un lado al otro. Bueno, XML es una especie de súper-CSV, al cumplir la misma función pero resolviendo varios temas importantes. Diferencias con CSV: Flexibilidad, un elemento puede estar o no, se pueden agregar nuevos elementos sin romper al programa que interpreta el archivo. Los campos son auto-descriptos, tanto que incluso pueden estar en cualquier orden (da lo mismo <uno/><dos/> que <dos><uno/> si al intérprete no le interesa el orden).
¿Cuál es la cualidad distintiva de la informacion estructurada?
Que tiene estructuras
, es la respuesta obvia. Y esas estructuras
son las que uno quiere manipular desde algún programa. Ya entendimos
que un archivo XML cargado en memoria se modela como un árbol. Entonces,
una API que nos permita trabajar con los datos de un archivo XML es muy
semejante a una API que nos permita manejar árboles. Una API así tendrá
obviamente funciones del tipo "agregar hijo", "dame padre", etc. Esa API
es DOM. Se puede encontrar más información sobre DOM en
la página de DOM del W3C.
Los diseñadores de la API DOM se impusieron la misión de diseñar una API no para un lenguaje, sino para todos. Esta API está disponible en Java, en C/C++, en Perl, etc. Siendo la API tan sencilla, y teniéndola ya disponible en todos los lenguajes… ¿para qué yo programador voy a ponerme a construir un componente que sepa analizar un archivo de texto (un parser)? ¡No cree más código para analizar formatos por usted! ¡Salte a la moda XML que además hace que su aplicación parezca más moderna! (Esto además del detalle de que a menos código propio menos bugs, pero eso es siempre un detalle, lo que importa es impresionar a los demás).
XML se está mencionando mucho hoy en día cuando hay varias partes que desean dialogar entre sí. XML les provee una forma de definir un vocabulario y de definir interfaces entre ellos que vayan evolucionando decente con el tiempo. Por ejemplo un sitio de compras por internet dialogando con una empresa de tarjetas de crédito.
Existen tres maneras fáciles de usar XML para comunicar procesos:
Visite también mi página de GNU/Linux.