Última revisión del documento:

AUTOR: Angel Barbero paniagua

TUTORIAL DE

0.-Sobre el tutorial:

Este documento pretende ser una introducción al XML, aunque también entrará en algunos detalles técnicos avanzados. Para entenderlo no hace falta tener conocimiento de ninguna otra tecnología Internet: HTML, SGML, hojas de estilo, DHTML, etc. Pero mi opinión es que para comprender el entorno en el que se coloca XML es bueno haber trabajado con ellas en algún momento, porque sólo entonces se puede obtener una visión completa de las capacidades y potencial de este nuevo lenguaje.

1.-Introducción:

Durante el último año, y sobre todo estos últimos meses se ha estado hablando del Lenguaje Extensible de "Etiquetado", eXtensible Markup Language, o XML, y en todos los foros de Internet que se precien de estar a la última no se puede tratar n ingún tema sin hacer mención a este nuevo estándar. Pero muchas veces se habla de él con poco o nigún conocimiento de causa, y son demasiados los que alaban sus virtudes sin entenderlas ni alcanzarlas por completo.

Antes de nada conviene repasar su historia y precedentes. La versión 1.0 del lenguaje XML es una recomendación del W3C desde Febrero de 1998, pero se ha trabajado en ella desde un par de años antes. Está basado en el anterior estándar SGML (Standard Gene ralized Markup Language, ISO 8879), que data de 1986, pero que empezó a gestarse desde principios de los años 70, y a su vez basado en el GML creado por IBM en 1969. Esto significa que aunque XML pueda parecer moderno, sus conceptos están más que asentado s y aceptados de forma amplia. Está además asociado a la recomendación del W3C DOM (Document Object Model), aprobado también en 1998. Éste no es más que un modelo de objetos (en forma de API) que permite acceder a las diferentes partes que pueden componer un documento XML o HTML.

SGML proporciona un modo consistente y preciso de aplicar etiquetas para describir las partes que componen un documento, permitiendo además el intercambio de documentos entre diferentes plataformas. Sin embargo, el problema que se atribuye a SGML es su e xcesiva dificultad; baste con pensar que la recomendación ocupa unas 400 páginas.

Así que, manteniendo su misma filosofía, de él se derivó XML como subconjunto simplificado, eliminando las partes más engorrosas y menos útiles. Como su padre, y este es un aspecto importante sobre el que se incidirá después, XML es un metalenguaje: es un lenguaje para definir lenguajes. Los elementos que lo componen pueden dar información sobre lo que contienen, no necesariamente sobre su estructura física o presentación, como ocurre en HTML.

Usando SGML, por otro lado, se definió precisamente el HTML, el lenguaje que nos es tan conocido. Entonces, ¿cuál es la diferencia entre ambos?

En una primera aproximación se puede decir que mediante XML también podríamos definir el HTML, con lo que podríamos considerar los siguientes conjuntos:

De hecho, HTML es simplemente un lenguaje, mientras que XML como se ha dicho es un metalenguaje, esto es, un lenguaje para definir lenguajes. Y esa es la diferencia fundamental, de la que derivan todas las demás, que iremos viendo a lo largo del document o.

Desde su creación, XML ha despertado encontradas pasiones, y como para cualquier tema en Internet, hay gente que desde el principio se ha dejado iluminar por sus expectativas, mientras que otras muchas lo han denostado o simplemente ignorado. Debo recono cer que soy de las primeras personas :-), pero espero que esto no afecte al contenido del tutorial, que pretende ser objetivo y sencillo.

Durante el año 1998 XML ha tenido un crecimiento exponencial, y con ello me refiero sobre todo a sus apariciones en los medios de comunicación de todo tipo, menciones en páginas web, soporte software, tutoriales, etc. Para dar una idea, mientras mi fiche ro de bookmarks sobre el tema en septiembre de 1998 tenia unas 5-7 entradas, ahora se me ha hecho imposible el poder controlar todo lo que aparece sobre él, y tengo del orden de 25-30 entradas que debo cambiar y revisar continuamente.

De este modo se ha entrado en 1999 como si se hubiera llegado al final de una pista de despegue; y ahora XML por fin ha despegado. Y esto significa simplemente que desde noviembre del año pasado hasta hoy ha pasado de mera especulación a ser una realidad empresarial palpable y mesurable: los programas que lo soportan han crecido del mismo modo exponencial, y a día de hoy no hay empresa de software que se precie que no anuncie la compatibilidad de sus productos más vendidos con este nuevo estándar: Micros oft (Office 2000), Oracle (Oracle 8i, Web Application Server) o Lotus (Notes) son tres claros ejemplos de ello. Aún más increíble es pensar que hay empresas que se han creado entorno a él, u otras que han movido su actividad hacia su ámbito (de SGML a XML , por ejemplo, como ArborText).

Una pregunta que ha acudido a muchos de nosotros es: ¿será XML el sustituto de HTML, que tan bien conocemos, dominamos, amamos y odiamos? No. Esa es la respuesta, e intentaré explicar porqué: básicamente XML no ha nacido sólo para su aplicación en Inter net, sino que se propone como lenguaje de bajo nivel (a nivel de aplicación, no de programación) para intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo, y casi cualqu ier cosa que podamos pensar. Sin ir más lejos, algunos lenguajes de los que hablaremos, definidos en XML, recorren areas como la química y la física, las matemáticas, el dibujo, tratamiento del habla, y otras muchas.

Pues bien, no lo sustituirá, pero, aplicado en Internet, sí va a mejorar algo de lo que HTML empezaba a adolecer desde hace un tiempo: establece un estándar fijo al que atenerse, y separa el contenido de su presentación. Esto significa que a partir de ah ora, o mejor desde el momento que se aplique definitivamente, para ver un documento web no estaremos sujetos a la parte del estándar de hojas de estilo (CSS) que soporte el Navigator de Netscape o el IExplorer de Microsoft, ni al lenguaje de script del se rvidor y al modelo de objetos definido por MS, Nestcape, etc. Además tampoco estaremos atados a la plataforma: podremos ver la misma información desde nuestro PC o desde un Hand-HeldPC, un navegador textual, una lavadora, un microondas o un reloj con acce so a Internet, con presentaciones adecuadas a cada entorno. Ya veremos más adelante el porqué de estas afirmaciones.

Se puede suponer de este modo que XML constituye la capa más baja dentro del nivel de aplicación, sobre el que se puede montar cualquier estructura de tratamiento de documentos, hasta llegar a la presentación. Y así podemos ver la compartición de documen tos entre dos aplicaciones como intercambio de datos a ese nivel:

Pero ahora, y antes de seguir divagando sobre sus posibilidades, expliquemos los conceptos en los que se basa y la teoría de su aplicación, para que podamos escribir documentos XML en poco tiempo.

2.-La teoría:

Lo primero que debemos saber es que hay dos tipos de documentos XML: válidos y bien formados. Éste es uno de los aspectos más importantes de este lenguaje, así que hace falta entender bien la diferencia:

¿Y qué es un DTD? Pues es una definición de los elementos que puede haber en el documento XML, y su relación entre ellos, sus atributos, posibles valores, etc. De hecho DTD está por Document Type Definition, o Definición de Tipo de Documento. Es una especie de definición de la gramática del documento, en definitiva. Más adelante hablaré de cómo se incluye un DTD en un documento XML, pero lo importante ahora es entender que cuando se procesa cualquier infomación formateada mediante XML, lo primero es comprobar si está bien formada, y luego, si incluye o referencia a un DTD, comprobar que sigue sus reglas gramaticales. Hay pues diferencia entre los parsers que procesan documentos XML sin comprobar que siguen las reglas marcadas por un DTD (sólo comprue ban que está bien formado), que se llaman parsers no validadores, y los que sí lo hacen, que son parsers validadores (comprueba que además de bien formado se atiene a su DTD y es válido).

Y ahora, ¿qué pinta tiene un documento XML? Aquí podemos ver uno muy sencillo, que iremos estudiando para ver las características del lenguaje:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ficha>
<nombre>Angel</nombre>
<apellido>Barbero</apellido>
<direccion>c/Ulises, 36</direccion>
</ficha>

Lo primero que tenemos que observar es la primera línea. Con ella deben empezar todos los documentos XML, ya que es la que indica que lo que la sigue es XML. Aunque es opcional, es más que recomendable incluirla siempre. Puede tener varios atributos (los campos que van dentro de la declaración), algunos obligatorios y otros no:

En cuanto a la sintáxis del documento, y antes de entrar en el estudio de las etiquetas, hay que resaltar algunos detalles importantes y a los que nos debemos acostumbrar:

Pasando al contenido en sí, vemos etiquetas que nos recuerdan a HTML, y que contienen los datos. Es importante diferenciar entre elementos y etiquetas: los elementos son las entidades en sí, lo que tiene contenido, mientras que las etiquetas sólo descr iben a los elementos. Un documento XML está compuesto por elementos, y en su sintáxis éstos se nombran mediante etiquetas.

Hay dos tipos de elementos: los vacíos y los no vacíos. Hay varias consideraciones importantes a tener en cuenta al respecto:

Hasta aquí la sintáxis de XML resumida. Aunque la especificación entera es más prolija en cuanto a detalles sintácticos, codificaciones, etc., creo que no hace falta extenderse mucho en ello, ya que realmente "el movimiento se demuestra andando" ;, y será en la práctica cuando veamos los posibles problemas que se pueden plantear. Ahora quedan por ver otros aspectos, el más prioritario, los DTD.

3.-DTD: Definición de Tipos de Documento

Como antes se comentó, los documentos XML pueden ser válidos o bien formados (o no serlo, claro, pero entonces no serían documentos XML :-). En cuanto a los válidos, ya sabemos que su gramática está definida en los DTD.

Pues bien, los DTD no son más que definiciones de los elementos que puede incluir un documento XML, de la forma en que deben hacerlo (qué elementos van dentro de otros) y los atributos que se les puede dar. Normalmente la gramática de un lenguaje se defi ne mediante notación EBNF; si alguno la conoce, se habrá dado cuenta de que es bastante engorrosa. Pues el DTD hace lo mismo pero de un modo más intuitivo.

Hay varios modos de referenciar un DTD en un documento XML:

En cuanto a la definición de los elementos, es bastante intuitiva: después de la cláusula <!ELEMENT se incluye el nombre del elemento (el que luego se indicara en la etiqueta), y después diferentes cosas en función del elemento:

Ejemplos de cada caso se pueden ver en el DTD de muestra.

A la hora de indicar los elementos descendientes (los que están entre paréntesis) vemos que van seguidos de unos caracteres especiales: '+', '*', '?' y '|'. Sirven para indicar qué tipo de uso se permite hacer de esos elementos dentro del documento:

De este modo, si por ejemplo encontramos en un DTD la siguiente declaración:

	<!ELEMENT ficha (nombre+, apellido+, direccion*, foto?, telefono*|fax*)> 

sabremos del elemento ficha que puede contener los siguientes elementos: un nombre y un apellido como mínimo, pero puede tener más de uno de cada; opcionalmente puede incluirse una o varias direcciones, pero no es obligatorio; opcionalmente también se pu ede incluir una única foto; y por fin, pueden incluirse, aunque no es obligatorio en ninguno de los dos casos, uno o más teléfonos o uno o más números de fax.

Como ya se comentó un documento XML presenta una jerarquía muy determinada, definida en el DTD si es un documento válido, pero siempre inherente al documento en cualquier caso (siempre se puede inferir esa estructura a partir del documento sin necesidad de tener un DTD en el que basarse), con lo que se puede representar como un árbol de elementos. Existe un elemento raíz, que siempre debe ser único (sea nuestro documento válido o sólo bien formado) y que se llamará como el nombre que se ponga en la definición del <!DOCTYPE si está asociado a un DTD o cualquiera que se dese e en caso contrario. Y de él descienden las ramas de sus respectivos elementos descendientes o hijos. De este modo, la representación en forma de árbol de nuestro documento XML de ejemplo sería:

Vemos que es un documento muy sencillo, con una profundidad de 2 niveles nada más: el elemento raíz ficha, y sus hijos nombre, apellido, direccion, foto. Es obvio que cuanta más profundidad, mayor tiempo se tarda en procesar el árbol, pero la dificultad siempre será la misma gracias a que se usan como en todas las estructuras de árbol algoritmos recursivos para tratar los elementos (comentario para aquellos que han programado algo con árboles, aunque habrá un capítulo dedicado a la programación para XML)

El DTD, por ser precisamente la definición de esa jerarquía, describe precisamente la forma de ese árbol. La diferencia (y la clave) está en que el DTD define la forma del árbol de elementos, y un documento XML válido puede basarse en ella para estructur arse, aunque no tienen que tener en él todos los elementos, si el DTD no te obliga a ello. Un documento XML bien formado sólo tendra que tener una estructura jerarquizada, pero sin tener que ajustarse a ningún DTD concreto.

Para la definición de los atributos, se usa la declaración <!ATTLIST, seguida de:

Es importante destacar un aspecto de cara a la optimización del diseño de nuestros DTDs: muchas veces tendremos que decidir entre especificar atributos de nuestros elementos como elementos descendientes o como atributos en sí mismos. Esto es, podríamo s suponer una pieza de maquinaria con unas características determinadas, y de la que podemos hablar de dos formas diferentes:

<pieza>MiPieza
	<color>Rojo</color>
</pieza>
o bien considerar la opción:
<pieza color="Rojo">Mipieza</pieza>

¿Qué diferencia habría entre ambos? Queda a discreción del diseñador el decidir entra ambas, pero hay que tener en cuenta que si se usa la primera forma, el procesador tiene que bajar al siguiente nivel del árbol de elementos para saber el color de MiPieza, mientras que en el segundo caso lo puedes obtener referenciando directamente el atributo "color" del elemento en el que estás.

Esto no quiere decir nada de todos modos, porque hay quien prefiere hacerlo del primer modo por estar más acorde con la filosofía de XML de que las etiquetas referencien siempre su contenido, sin necesidad de acudir a los atributos, que era lo que hast a ahora se hacía en HTML.

4.-Las Entidades o Entities:

Mediante estos elementos especiales es posible dotar de modularidad a nuestros documentos XML. Se pueden definir, del mismo modo que los propios DTDs de los que ya hemos hablado, dentro del mismo documento XML o en DTDs externos.

Las primeras entidades que hemos conocido son los carácteres especiales &, ", ', < y >, que vimos que debíamos escribir mediante las declaraciones: &amp, &quot;, &apos;, &lt; y &gt;. Es decir, que cuando queramos refe renciar alguna entidad definida dentro de nuestro documento o en otro documento externo, deberemos usar la sintáxis: &nombre;.

Existe un conjunto de entidades predefinidas de caracteres ISO, que se pueden ver en una lista resumida publicada en la revista Webmonkey por Jay Greenspan.

Pero por supuesto las entidades no solo sirven para incluir caracteres especiales no ASCII. También las podemos usar para incluir cualquier documento u objeto externo a nuestro propio documento.

Por ejemplo, y como uso más simple, podemos crear en un DTD o en el documento XML una entidad que referencie un nombre largo:

<!ENTITY DAT "Delegación de Alumnos de Teleco">

Y de este modo, cada vez que queramos que en nuestro documento aparezca el nombre "Delegación de Alumnos de Teleco", bastará con escribir &DAT;. Los beneficios son claros, y además es muy sencillo, ¿no?

El texto referenciado mediante la entidad puede ser de cualquier tamaño y contenido. Si queremos incluir una porción de otro documento muy largo que hemos guradado aparte, de tipo XML o cualquier otro, podemos hacerlo por lo tanto de este modo:

<!ENTITY midoc SYSTEM "http://www.dat.etsit.upm.es/~abarbero/midoc.xml">

Del mismo modo que usábamos con los DTDs externos, indicamos al procesador con SYSTEM que la referencia es externa y que lo que sigue es una URI estándar, y es lo que queda entrecomillado a continuación.

Hay que resaltar que esto se aplica dentro de documentos XML, pero no de DTDs. Para incluir entidades en DTDs debemos usar el carácter %:

<!ENTITY % uno "(uno | dos | tres)">

Y para expandirlo en un DTD tendremos que escribir:

<!ELEMENT numero (%uno;) #IMPLIED>

Escapa a mis conocimientos el por qué se ha implementado de forma diferente en los dos casos.


Hasta aquí he resumido los aspectos más importantes de la recomendación de XML y varios temas relacionados con ella. Ahora pasemos a un terreno un poco más abstracto, para conocer otros estándares de facto y tecnologías relacionadas con XML.

5.- Hojas de estilo para XML: XSL

Aunque se ha establecido un modo para que podamos usar hojas de estilo CSS (Cascade Style Sheets) dentro de documentos XML, es lógico pensar que para aprovechar las características del nuevo lenguaje hace falta tener un estándar paralelo y similar asoc iado a él. De este modo en el W3C están trabajando sobre la nueva recomendación XSL: eXtensible Stylesheet Language. Aún no ha llegado a ser recomendación, y de momento es un public draft, esto es, un documentosujeto a comentarios y correcciones. < /P>

De todos modos, está bastante avanzado, y de hecho empresas como Microsoft e IBM ya ofrecen soporte a algunas de sus características.

Según el W3C, XSL es "un lenguaje para transformar documentos XML", asi como un vocabulario XML para especificar semántica de formateo de documentos.

En definitiva, además del aspecto que ya incluía CSS referente a la presentación y estilo de los elementos del documento, añade una pequeña sintáxis de lenguaje de script pata poder procesar los documentos XML de forma más cómoda.

Al igual que con HTML hasta ahora, se pueden especificar las hojas de estilo, sean CSS o XSL, dentro del propio documento XML o referenciandolas de forma externa.

6.-EL modelo de objetos de documentos DOM

El modelo de objetos de documentos del W3Consortium, o Document Object Model (DOM) es una representación interna estándar de la estructura de un documento, y proporciona un interface al programador (API) para poder acceder de forma fácil, consistent e y homogénea a sus elementos, atributos y estilo. Es un modelo independiente de la plataforma y del lenguaje de programación.

El W3C establece varios niveles de actuación, coincidiendo con el tiempo en que se presentan como recomendación:

Por el momento ya se ha sacado el 1er nivel como recomendación (Octubre 1998), y el public draft del 2º, es decir, está en etapa de consulta y sujeto a comentarios.

El objetivo es que de una vez por todas cualquier script pueda ejecutarse de forma más o menos homogénea en cualquier navegador que soporte dicho DOM. Siempre por supuesto se podrá elegir el implementar modelos propietarios que es lo que ahora ofrecen Ne tscape y Microsoft, pero tener una plataforma estándar en la que poder crear contenidos sin temor a no estar soportado por alguna marca o versión de navegador, que además sea potente y versátil.

Y por supuesto, como el conjunto de piezas que el W3C está creando para su uso en el intercambio de documentos e información, no estará sujeto al ámbito de los navegadores, sino que su uso será extensible a cualquier tipo de aplicación que acceda a esos documentos.

7.-XML y los navegadores:

Es importante saber qué nos depara el futuro y qué podremos obtener de XML como lenguaje de publicación en Internet. Para ello hace falta conocer de qué forma soportaran los navegadores el nuevo lenguaje. Hay que tener en cuenta que XML es un lenguaje c apaz de describir el contenido de la página, no su aspecto (un metalenguaje, vamos). ¿Y cómo un navegador puede enseñar algo de lo que no sabe su aspecto? Es la pregunta del millón.

La idea es asociar al documento XML una hoja de estilo. Se puede hacer con CSS (Cascading Style Sheets, recomendación del W3Consortium, que va por su versión 2.0), pero se va a aprobar por el W3Consortium una nueva recomendación más completa, la XSL (eXt ensible StyleSheets Language), que permite añadir lógica de procesamiento a la hoja de estilo, en forma de una especie de lenguaje de programación (una especie de lenguaje de script). De este modo, dependiendo de la hoja de estilo que asociemos al documen to o de la lógica que incluyamos, se podrá visualizar en cualquier plataforma: PalmPC, PC, microondas, nevera :-), navegador textual, IE5, Netscape, etc. Y con el aspecto (colores, fuentes, etc) que queramos.

El problema surge del hecho de que el navegador debe incluir de algún modo un parser para XML y un motor que acepte las hojas de estilo (CSS o XSL). Y aqui empiezan a verse diferencias:

Mi opinión es que parte del futuro del intercambio de datos está en el XML, con lo que el no ofrecer soporte para él es arriesgado. De hecho y para que nos hagamos una idea, algunos productos que darán soporte back-end de XML (lo usarán como formato i ntermedio y de intercambio entre aplicaciones) son el Oracle 8i (la nueva base de datos de Oracle), sus productos orientados al web (Appliaction Server y otros) Windows y Office 2000 y Lotus Notes en un cercano futuro. Y si Microsoft mete dinero ahí, desd e luego es porque algo se huele, ¿no?

8.-Enlaces Relacionados: