XML significa eXtensible markup language, o lenguaje de anotación extensible. Ya conocemos el lenguaje HTML (hypertext markup language), lenguaje de anotación para página webs que permite navegación tipo hipertexto; sin embargo, XML no es sólo un lenguaje, es una forma de especificar lenguajes, de ahí lo de extensible. Todo lenguaje que se exprese de una forma determinada puede ser XML. Por lo tanto, XML no es un lenguaje para hacer mejores páginas web, sino un lenguaje para información auto-descrita, o al menos, auto-descrita si las etiquetas están bien puestas.

XML se inició como un subconjunto de SGML (structured generalized markup language), un standard ISO para documentos estructurados que es sumamente complejo para poder servir documentos en la web. XML es algo así como SGML simplificado, de forma que una aplicación no necesita comprender SGML completo para interpretar un documento, sino sólo el subconjunto que se defina. Los editores SGML, sin embargo, pueden comprender XML.

Por tanto, no debe uno de pensarse que XML es para crear páginas web, o algo parecido a las página web. XML es un lenguaje que cambia el paradigma de publicación, de basado en el programa a programación basada en el documento. XML se puede usar para cambiar totalmente el paradigma de publicación; de un programa que recibe unas entradas y produce unas salidas, se pasa a un documento que genera otro documento, o bien programas que toman documentos y producen otros documentos. Por eso, también, y, en general, salvo en entornos de servicios web, lo normal es que el XML se use en el servidor, y se sirva otro tipo de documentos, HTML, por ejemplo, que se obtienen a base de una serie de transformaciones. Precisamente, esto hace que los documentos XML se usen dentro de entornos de aplicaciones. Este entorno de aplicaciones permite publicar documentos XML, que, antes de ser enviados al cliente, sufrirán una serie de transformaciones para adaptarlo a los requisitos del mismo. Algunos ejemplos de entorno de aplicaciones son el Cocoon, un entorno basado en Java, libre, que permite no sólo publicar páginas XML, sino también incluir programas dentro de las páginas (XSP). No se caracteriza por su velocidad ni amigabilidad, pero es excelente como entorno de desarrollo (y el precio es inmejorable). Otra alternativa gratuita es el AxKit. Como alternativas de pago (y bien pagadas) están el Bea Weblogic, y el IBM transcoding publisher. Sobre todos estos y muchos más se trata en esta discusión en barrapunto, en la cual se menciona, por ejemplo Krysalis, un entorno de publicación basado en PHP, que incluye facilidades para ser usado a través de SOAP.

Dentro de estos entornos de desarrollo, o usándolo de cualquier otra forma, XML tiene gran número de aplicaciones. La mayor parte de los portales y sitios de noticias ya están basados en XML, porque permite estructurar la información y luego aplicarle transformaciones fáciles para presentarlo. Lo más normal es que la información esté almacenada en una base de datos, se convierta a XML y luego se transforme para servirlo al cliente. Otro ejemplo de aplicación basada en XML es la base de datos discográfica de Siniestro Total está también basada en XML, y además el código es libre. Muchos weblogs, tales como barrapunto y Slashdot, sirven sus titulares en XML (y RDF), lo cual permite procesarlo fácilmente para, por ejemplo, incluirlos en la página personal de uno (ver la barra de la derecha). Todos los sitios que sirven, o servían, páginas WAP también usan, sin otro remedio, XML. Google ofrece un interfaz de programación para acceder a sus servicios usando SOAP, un interfaz de acceso remoto que usa XML. Y se puede usar en cualquier aplicación web donde haga falta programación estructurada.

¿Cómo se usa XML?

Para editar documentos XML, al igual que para hacerlo con HTML, se puede hace de dos formas: editándolos como cualquier otro fichero ASCII, usando, si acaso, un editor estructurado como el XEmacs, o bien usar un editor específico para XML, que entiende las particularidades del lenguaje, lo indenta como está mandado, y te cierra solito las etiquetas.

Para hacer esto hay muchas opciones, tanto en Windows como en Linux, aunque la mayoría son de pago. Por ejemplo, XMLSpy tiene un buen entorno, funciona solo para Windows, paro es relativamente inestable (al menos las versiones probadas). eXcelon Stylus permite además aplicar transformaciones, en un entorno de tres paneles bastante pijo. También es relativamente caro. <oXygen/> es bastante económico para uso personal o académico, y tiene una versión de prueba de treinta días. Está basado en Java, y funciona tanto en Windows como en Linux. Te completa las etiquetas, y es aceptablemente rápido. Se basa también en bastantes herramientas libres, tales como batik y fop de Apache. Una lista extensa, pero sin ningún tipo de comentario, está en Userland software. También suele haber una buena lista en XMLsoftware, pero en julio 2002 está caido. Habrá que esperar a que vuelva. En freshmeat se listan hasta 15 herramientas, algunas de las cuales son editores.

Los mismos entornos incluyen facilidades para validar el código XML resultante, pero esto se puede hacer también usando analizadores XML, de los cuales hay muchos, de bastante buena calidad, y la mayor parte de ellos gratuitos. Uno de los más conocidos y usados es el Xerces, del cual hay versiones en Java, en Perl y en C++. Es adecuadamente rápido, y además incorpora todos los últimos estándares del W3. Otra opción, que además se puede usar desde Internet, es el XParse de Jeremie, que te analiza directamente el documento y te lo presenta en forma de árbol.

La mayor parte de los validadores pueden trabajar de dos formas: de forma independiente, y usándolos como librerías desde el lenguaje de programación de la elección de uno; por ejemplo, Xerces se puede usar stand-alone, o bien como una librería xerces.jar, cuyos objetos se pueden instanciar o usar desde el programa de uno.

En muchos casos, como en el caso de C#, el XML se puede generar automáticamente a partir de la definición de una clase, o bien, al revés, una clase o un objeto de una clase se puede generar automáticamente a partir de XML a partir de un fichero, de esta forma:

De la misma forma, usando la herramienta xsd permite convertir definiciones de clase en definiciones de tipos de datos en XML y viceversa, usándolo de esta forma:

convierte una definición de clase en código C#, o, de forma análoga, pero al contrario:

que convierte un ensamblaje en una definición de tipo de datos en XML

La mayoría de los navegadores actuales son capaces de entender XML. Por ejemplo, el Internet Explorer lee los ficheros XML y los trata de una forma especial, pudiendo presentar la jerarquía a diferentes niveles. Otros navegadores, como el Mozilla o el Netscape, también entienden XML, aunque no permiten editarlo de forma adecuada ni de presentarlo de forma jerárquica como el IE. En algunos casos, son capaces también de aplicar transformaciones tales como XSLT o CSS (cascading style sheets).

XML bien formado

Como lenguaje de anotación, las sentencias en XML consisten en una serie de etiquetas (llamadas elementos) con una serie de modificadores (llamados atributos). Las etiquetas pueden estar anidadas unas dentro de otras, pero toda etiqueta que se abra se tiene que cerrar, y siempre en el mismo orden. En caso de que un elemento no tenga pareja (por no tener ningún contenido dentro), se le denomina elemento vacío y se indica con un / al final. Los elementos se agrupan en documentos, tales como el siguiente ( ej1.xml):

Todos los documentos XML deben estar bien formados, y este es el requisito mínimo que deben cumplir los documentos. Eso que significa que se debe cumplir lo siguiente:

• si no se utiliza DTD, el documento debe comenzar con un Declaración de Documento Standalone, tal como la que se pone en la primera línea.
• todas las etiquetas deben estar equilibradas: esto es, todos los elementos que contengan datos de tipo carácter deben tener etiquetas de principio y fin
• todos los valores de los atributos deben ir entrecomillados (el carácter comilla simple [el apóstrofe] puede utilizarse si el valor contiene caracteres comillas dobles, y viceversa): si necesitas ambos, utiliza &apos; y &quot;. Así es como se hace en el elemento habitacion
• cualquier elemento VACÍO (p.e. aquellos que no tienen etiqueta final como <IMG>, <HR>, y <BR> y otros de HTML) deben terminar con '/>' o debes hacerlos no VACÍOS añadiéndoles una etiqueta de fin, tal como se ve en el elemento puerta.
• no debe haber etiquetas aisladas (< ó &) en el texto (p.e. debe darse como &lt; y &amp;), y la secuencia ]]> debe darse como ]]&gt; si no ocurre esto como final de una sección marcada como CDATA;
• los elementos deben anidar dentro de sí sus propiedades (no se deben sobreponer etiquetas, como en el resto de SGML);
• Los ficheros bien-formados sin-DTD pueden utilizar atributos en sus elementos, pero éstos deben ser todos del tipo CDATA, por defecto. El tipo CDATA (character DATA) son caracteres..
• Los nombres de las etiquetas pueden ser alfanuméricos, comenzando con una letra, e incluyendo los caracteres - y :, aunque este último tiene un significado especial.

En este caso usamos un documento XML para describir las estancias de una casa. Con él podemos hacer poca cosa, salvo analizarlo a ver si es correcto. Lo podemos hacer usando el parser XML de Jeremie, que nos dará un resultado tal como el de la imagen.

Lo que ocurre con el parser este es que se lo traga todo, y ya puede uno meter los errores que sean, que no da ninguno. Por eso, merece la pena usar un parser tal como el Xerces, que te puedes bajar directamente de aquí. Para usarlo, tenemos que dar las órdenes siguientes (en Windows)

Habrá que dar, en cada caso, el camino a donde esté instalado, de forma efectiva, el Xerces y la máquina virtual Java. En caso de tratarse de Linux, las órdenes serán así:

Por ejemplo, en el caso del fichero anterior, el resultado sería algo así:

Que es muy parecido al original, salvo que la codificación ha sido cambiada a UTF-8 (un método de codificar caracteres UNICODE), y por eso los acentos aparecen de forma extraña. En este caso, la clase dom.Domwriter lo que hace es leer el fichero de entrada, validarlo, y escribirlo en la salida con indentaciones. En caso de que hubiéramos introducido un error, por ejemplo, el fichero siguiente:

Nos daría un error de este estilo:

Que indica que, efectivamente, el elemento tipo aqui-peta debe de estar emparejado con su anti-elemento correspondiente.

En un documento XML, aparte de elementos y atributos, puede haber otras cosas: entidades, que representan símbolos "atómicos", que habitualmente deben ser entendidos por el navegador, y que se muestran en la tabla adjunta; como se ve, las entidades van encerradas entre los símbolos & y ;; comentarios, que se procesan de forma diferente al texto, y que, tal como en HTML, van precedidos por <!-- y acaban con -->; secciones CDATA, que sirven para extraer del documento XML una sección, que va a ser interpretada tal cual, sin hacer ninguna modificación. Puede servir, por ejemplo, para meter HTML "mal-formado" dentro de un documento XML. Por ejemplo, el documento siguiente incluiría todas los elementos anteriores (ej3.xml):

En este caso, al procesarlo con Xerces, la salida dejará fuera los comentarios, que no forman parte del documento, a no ser que se quieran usar de verdad.

Ejercicios 1. Crear un documento XML, que contenga la descripción de un equipo de la liga (jugadores, nombre, entrenador). Procesarlo en el parser JavaScript, y con el Xerces. Usar alternativamente un editor para Windows. Comprobar que es XML válido.
2. Crear un documento XML que describa varios libros de una biblioteca o librería, con título, autores, resumen, editorial y los datos que se quieran incluir.

Cada cosa en su sitio: XML namespaces

Si todo el mundo fuera definiendo etiquetas por ahí, un documento acabaría siendo un caos de diferentes etiquetas procedentes de diferentes sitios, y, lo que es peor, de etiquetas con el mismo nombre que, en realidad, significan cosas diferentes. El concepto de espacios de nombres (namespaces) permite particionar el conjunto de todos los nombres posibles, de forma que se pueda definir a qué zona de ese espacio corresponde una etiqueta. De esta forma, etiquetas con el mismo nombre, pero definidas por dos autores diferentes, pueden diferenciarse en el espacio de nombres. El espacio de nombres no es esencial en todos los documentos, pero resulta útil cuando se usan etiquetas procedentes de diferentes procedencias (por ejemplo, etiquetas nuevas dentro de un documento XML), o etiquetas que se quieren procesar de forma diferente. El especio de nombres de una etiqueta se indica con un prefijo y :: <namespace:etiqueta. Por ejemplo, se usan espacios de nombres en el documento siguiente:(ej4.xml): <mc:micasa xmlns:mc='http://www.geneura.org/micasa'> <mc:habitacion mc:id="comedor"> <mc:mueble>aparador</mc:mueble> <mc:mueble>sofá "de época"</mc:mueble> </mc:habitacion> </mc:micasa>

En este documento, donde hemos suprimido elementos que ya se han explicado, se usa la primera línea para declarar el prefijo del espacio de nombres mediante el atributo xmlns (XML namespace). En este caso, hemos elegido el prefijo mc. A la vez, el espacio de nombres tiene que tener asignado un URI (Universal Resource Identification), que es básicamente algo que parece una dirección web, pero que no lo es. Lo único que se requiere de este URI es que sea único en el documento; además, es aconsejable que sea siempre el mismo cuando se use el mismo namespace, aunque no es estrictamente necesario, ni se puede comprobar. El que sea un URI significa, entre otras cosas, que si uno se mete en esa dirección no tiene porqué haber nada. Se trata simplemente de asignar un identificador único.

En el resto de los elementos se sigue usando el espacio de nombres. Incluso se puede usar en los atributos, si pertenecen al mismo espacio de nombres.

Un documento XML puede tener tantos espacios de nombres como se quieran declarar, y se pueden mezclar elementos de diferentes espacios de nombres, e incluso sin ningún espacio, tal como se hace en el siguiente ejemplo (ej5.xml):

En este caso, hemos declarado dos espacios de nombres, mc y muebles, y cada uno lo usamos para una cosa diferente. Incluso un atributo, id, se usa sin espacio de nombres.

Ejercicios
1. Con los equipos de la liga anteriores, usar diferentes espacio de nombres para el equipo en sí y para sus componentes. Por ejemplo, los elementos que se incluyan dentro de un jugador pueden tener un espacio de nombres, mientras que la descripción de un equipo puede tener otro diferente

XML y diccionarios de datos

En algunos casos, es necesario validaar que un documento XML es correcto, es decir, que las etiquetas que se usan son correctas y que están anidadas de la forma adecuada. Por ejemplo, en el caso anterior, es conveniente comprobar que la etiqueta raíz es siempre micasa, que la casa está compuesta de habitaciones, y las habitaciones tienen muebles y puertas a otros sitios. Incluso se podría intentar que las puertas fueran a otras habitaciones válidas, aunque es mucho pedir.

Para ello se pueden usar dos herramientas: DTD, o data type dictionnary, o bien XSchema, el equivalente en XML. Un XSchema describe la sintaxis correcta de un documento XML. En el caso de los documentos que hemos visto hasta este momento, hay que seguir una serie de pasos para crear un XML Schema. La forma más fácil de hacerlo es usando alguna utilidad generadora, tal como DTDGenerator, que crea un DTD tal como el siguiente (ligeramente retocado):<!ELEMENT habitacion ( mueble+, puerta+ ) > <!ATTLIST habitacion id NMTOKEN #REQUIRED > <!ELEMENT micasa ( habitacion+ ) > <!ELEMENT mueble ( #PCDATA ) > <!ELEMENT puerta EMPTY > <!ATTLIST puerta a NMTOKEN #REQUIRED >

Este DTD se puede usar para validar los ficheros XML anteriores, aunque usaremos XSchema más adelante. Lo que indica es que una habitacion tiene uno o varios muebles, y una o varias puertas (que se indica con +); a su vez, micasa puede tener una o más habitaciones, y cada uno de los elementos pueden tener los atributos que se indican con la sentencia ATTLIST. Como se puede ver, no se trata de XML, aunque se le parezca. Por eso, usando una pequeña utilidad escrita en Perl llamada dtd2xsd.pl se puede convertir a XSchema (el resultado está en micasa.xsd, aunque, como en el caso anterior hemos tenido que retocar alguna cosilla):

Este documento declara un espacio de nombres por defecto en la primera línea, que es el que corresponde a los XML Schemas; eso quiere decir que, si no se usa ningún prefijo, los elementos pertenecerán a ese espacio de nombres. También declara un espacio de nombres "objetivo" (targetNamespace), que será el que se está validando, y un prefijo para el mismo, t.

A continuación, se declaran todos los elementos, usando, como es natural, element. Los elementos pueden ser tipos simples (tal como en este caso lo es mueble), o complejos (todos los demás). En el caso del elemento simple, basta declarar el tipo, en este caso, una cadena o string.

Los elementos complejos son los que incluyen diferentes elementos anidados (que se declaran con sequence), atributos (attribute). Para cada elemento que puede aparecer dentro de un elemento complejo, se declara el número mínimo y máximo de veces que debe o puede aparecer ((min|max)Occurs). Por ejemplo, si queremos que en cada habitació haya al menos una puerta (porque si no, a ver cómo vas a entrar, listo), se puede indicar así: <element ref='t:puerta' minOccurs='1' maxOccurs='unbounded'/> , y, evidentemente, a qué elemento se refiere; como son elementos del espacio "target", se usa el prefijo t. Para los atributos, se indica si son obligatorios mediante el atributo use, y de qué tipo son.

Sin embargo, este Schema, como está generado automáticamente, puede simplificarse. Especialmente, se pueden sustituir referencias (indicadas con el atributo ref) a otros elementos con los elementos en sí. El código quedaría de esta forma:

Este Schema ejemplo se puede usar, evidentemente, para validar los ejemplso anteriores. Para ello, dentro del mismo ejemplo, basta con indicar qué XSchema o DTD es el que siguen. Por ejemplo, se puede añadir lo siguiente al principio <!DOCTYPE micasa PUBLIC "MI CASA" "micasa.dtd"> (tal como se muestra en el fichero ej6.xml, justo después de la declaración de XML, para que use ese DTD para validar. Si se quiere usar un XSchema, hay algunas formas no estándar (que se suelen usar con los XSchemata de Microsoft), pero la forma estándar es incluir una serie de atributos en la etiqueta raíz, de esta forma:

Para analizar el documento y validarlo a la vez, hay que irse a la última versión de Xerces, la 2; la primera no le hace mucho caso a los XSchemas:

En caso de que haya algún error en el Schema o en el XML, el analizador lo indicaría.

Mas recursos gratuitos para Webmasters aqui

Ver historial de noticias