Curso de XML

Autor: Joaquin Bravo Montero

Introducción

Desde que el W3C aprobó la especificación 1.0 del XML en febrero de 1998, ha sido
increible la cantidad de información, aplicaciones y software que se ha ido
generando alrededor de este nuevo estándar.

En este tutorial veremos las principales caracteríticas del XML y como podemos irlo
utilizando para crear nuestras aplicaciones para internet.

Orígenes del XML

HTML

El lenguaje HTML, a pesar de su sencillez, es sin duda un invento prodigioso. Es el

más existoso sistema de presentación de documentos de la historia. Desde que
apareció el WWW, gracias al HTML hemos podido publicar y acceder a más
información de la que jamás podiamos haber imaginado.

Pero, a su vez, el HTML ha sido víctima de su propio éxito. El gran crecimiento de

Internet, los intereses comerciales y la necesidad de poder realizar páginas web
vistosas, ha dado lugar a que en poco tiempo este lenguaje haya evolucionado muy
rápidamente y, por desgracia, no siempre por el camino más adecuado.
Actualmente estamos en la versión 4.0 y, sin embargo, sigue siendo igual de rígido
e inflexible como era en un principio. Y es que es un lenguaje limitado en cuanto
que no nos permite realizar sobre Internet todas las aplicaciones o cosas que nos
gustaría.

XML

Estas razones han obligado a los miembros del W3 Consortium a desarrollar nuevas
versiones de HTML un nuevo lenguaje (mejor dicho, metalenguaje), que han
denominado XML (Extensible Markup Language); que aproveche las innegables
ventajas del HTML, pero que a su vez permita realizar muchas cosas más. Esto no
signfica, al me nos por el momento, el fin del HTML. Existen demasiadas páginas en
HTML y resulta muy sencillo crearlas. Además, los navegadores no soportarán
todavía en toda su potencia el XML y tecnologías asociadas, pero es evidente una
reformulación del HTML como una aplicación XML y un cambio radical en la forma
de elaborar las páginas web en los próximos años.

La diferencia es clara en el siguiente ejemplo:

donde podemos observar cómo Amazon presenta en su web información sobre los
libros.

El código en HTML es el siguiente:

Libro de Amazón en HTML
<p>
<dt>
<b>
<a href="/exec/obidos/ASIN/0764531999/qid=919015337">
Xml : Extensible Markup Language</a></b> ~
<NOBR><font color=#990033>Usually ships in 24 hours</font></NOBR>
<dd> Elliotte Rusty Harold / Paperback / Published 1998
<br>
Our Price: $31.99 ~
<NOBR><font color =#990033>You Save: $8.00 (20%)</font></NOBR>
<br>
<a href="/exec/obidos/ASIN/0764531999/qid=919015337">
<i>Read more about this title...</i></a>

y en XML lo podríamos escribir de la siguiente manera:

Libro de Amazón en XML

<?xml version="1.0"?>
<libro>
<titulo>Xml: Extensible Markup Language</titulo>
<disponible tiempo="24" unidad="hours"/>
<autor>Elliotte Rusty Harold</autor>
<formato>Paperback</formato>
<publicacion>1998</publicacion>
<precio cantidad="31.99" moneda="dolar"/>
<descuento cantidad="20"/>
<enlacelibro href="/exec/obidos/ASIN/0764531999/qid=919015337"/>
</libro>

Es evidente que no hay que ser ningún programador experto para entender que
cualquier programa informático podrá trabajar de forma más eficiente sobre el
segundo ejemplo que sobre el primero.

Esto permitirá, por ejemplo, realizar motores de búsqueda mucho más eficaces, lo
que nos permitirá un acceso más rápido y eficiente a la información. Nos permitirá
acceder a nuestras páginas favoritas desde nuestro teléfono móvil, o desde la ra dio
de nuestro coche, en el momento en el que los programas de reconocimiento de
voz trabajen con XML. Facilitará el intercambio de información y la cooperación
entre las empresas facilitando el comercio electrónico, etc. Y es que el XML busca
precisamente crear la capacidad de hacerlo todo en la web.

La potencia de esta forma de trabajar radica en que estamos etiquetando e

identificando el contenido, olvidándonos en un principio por la forma de presentarlo.
¡Ya nos encargaremos luego de darle un formato de salida! El W3c está trabajando
actualmente en el desarrollo de un lenguaje de hojas de estilo que nos lo permita,
denominado XSL (Extensible Style Languaje). Mediante una XSL podremos
transformar un document XML en otro XML (por ejemplo en HTML) o convertirlo a
un formato de impresión: RTF, PDF, etc.
Si el HTML supuso una revolución porque permite la comunicación entre las
personas, el XML supondrá una revolución porque va a permitir la comunicación
entre las máquinas.

HTML, XML versus SGML

Tampoco tenemos que equivocarnos y pensar que el XML es un HTML++. Tanto el

XML como el HTML tienen su base en el SGML. El SGML (Standard Generalized
Markup Language, ISO 8879) es el estándar internacional para la definición
de la estructura y el contenido de diferentes tipos de documentos
electrónicos. Es decir, es un metalenguaje que nos permite definir lenguajes para
definir la estructura y el contenido de nuestros documentos. La definición de la
estructura y el contenido de un tipo de documento se realiza en una DTD. En ella
definimos los elementos que conformarán ese tipo de documentos y cómo tienen
que estar organizados para que sea correcto.

Un ejemplo de DTD puede ser la que define cómo tendrán que ser los documentos
HTML. Por tanto, el HTML no es más que un tipo de documento SGML que se utiliza
en el web, y esto es importante, ya que aquí radica su principal diferencia con el
XML.

El XML no es ningún tipo de documento SGML, sino que es una versión abreviada
de SGML optimizada para su utilización en Internet. Esto significa que con él vamos
a poder definir nuestros propios tipos de documentos (podremos definir nuestras
propias etiquetas) por lo que ya no dependeremos de un único e inflexible tipo de
documento HTML.

El XML, más que un HTML++, hay que considerarlo como un SGML--

optimizado para su utilización en Internet. Como escribió Richard Ligth en su
libro Presenting XML: "XML ofrece el 80% de las ventajas del SGML con un 20% de
su complejidad". Y es que los diseñadores de XML intentaron dejar fuera sólo
aquellas partes que raramente se utilizan. Esta reducción resultó ser muy
importante: la especificación XML ocupa aproximadamente 30 páginas, frente a las
500 del SGML.

Ventajas de utilizar XML en las aplicaciones Web.

Entre las muchas que existen podemos destacar tres:

• Sencillez
• Variedad de estructuras de datos
• Excelente tratamiento de caracteres internacionales.

Sencillez

La primera y más importante ventaja del XML se refiere a su sencillez, en

especial si lo comparamos con los formatos binarios.

El XML es un formato basado en caracteres y por tanto comprensible para los seres
humanos. Además los documentos XML pueden leerse fácilmente, crearse y
modificarse por medio de las herramientas que utilizamos normalmente, como
editores de texto. Todo esto hace que la compresión y el análisis de documentos
XML resulte mucho más sencillo que los escritos en formato binario.

Otro ejemplo de la sencillez de XML tiene que ver con su habilidad para representar
datos estructuras en forma de árbol con todas las ventajas que esto comporta.
Existen otras sintaxis estandar, como por ejemplo la ANS.1 (Abstract Syntaxt
Notation 1) que nos permiten representar datos estructurados en forma de árbol.
Pero dicho estandar resulta bastante complicado de entender y generar. Se pueden
utilizar herramientas de generación automática para facilitar la tarea, pero las
herramientas adecuadas suelen ser bastante costosas. Por el contrario el XML
posee la misma habilidad para representar datos estructurados en forma de árbol y
su compresión y manejo son más sencillos.

Si algo puede decirse del intrincado mundo de Internet es que la "sencillez gana y
la eficacia pierde". En Internet la regla de oro es la apertura, es decir, accesibilidad
y disponibilidad para todos. Incluso si se trata de una tecnología totalmente
revolucionarias, sólo logrará imponerse si cuenta con el apoyo de la mayoría de la
población afectada. Un tecnología menos eficaz pero abierta a todo el mundo y
fácilmente comprensible tendrá más probabilidad de imponerse en Internet que
otra mejor pero de acceso restringido. Por esto ha triunfado el HTML y por esta
razón esta triunfando el XML: es sencillo.

Variedad de estructuras de datos

Aunque sencillo, XML tiene la potencia suficiente para expresar estructuras

complejas de datos. Para muchas aplicaciones, una estructura en forma de
árbol es lo suficientemente general y potente como para expresar datos
con un cierto nivel de complejidad. De hecho, supone un buen equilibrio entre
el nivel de expresividad y sencillez. Incluso estructuras de datos tan complicadas
como gráficos (VML, SVG) pueden llegar a representarse en un arbol. Por todo esto,
XML permite expresar estructuras complejas de datos que satistfacen las exigencias
de casi todas las aplicaciones.

Tratamiento de caracteres internacionales

Una de las grandes ventajas del XML que no debe subestimarse es su
capacidad para gestionar conjuntos de caracteres internacionales. Incluso si
se está diseñando un documento muy simple, esta sola característica basta para
decantarse por XML.

Hoy en día, los negocios se realizan a escala mundial. Esto es especialmente cierto
cuando se trata de aplicaciones Web, puesto que Internet se ha encargado de
borrar las fronteras nacionales. Resulma muy común que las transacciones
comerciales contengan, por ejemplo, nombres de calles en chino o nombres propios
de origen árabe. La recomendación 1.0 de XML está definida de acuerdo con el
conjunto de caracteres ISO-10646(Unicode), por lo que virtualmente todos los
caracteres que actualmente se utilizan en el mundo son caracteres oficiales.

Areas de aplicación del XML

En este tutorial se estudia la utilización de XML para el etiquetado y la

estructuración de documentación. Pero el XML es tan potente y flexible que muchos
personas lo utilizan para otros fines. Algunas de estas otras aplicaciones las
podemos englobar en estos tres grupos:

• Uso de XML para describir metacontenidos respecto a documentos o recursos

en línea.
• Uso de XML para publicar e intercambiar contenidos de bases de datos.
• Uso de XML como formato para sistemas de mensajería con el fin de permitir
la comunicación entre programas de aplicaciones.

Metainformación

En 1997 XML se consideraba fundamentalmente un lenguaje para definir

metacontenidos. Un metacontenido no es más que la información relativa al
contenido del documento, como su título, autor, amaño del archivo, fecha de
creación, historial de cambios, palabras clave, y demás información asociada. Se
puede utilizar un metacontenido, por ejemplo, para realizar búsquedas, filtrar
información y gestionar el documento.

El HTML, dado que es un lenguaje de marcas enfocado a la presentación,

proporciona mecanismos muy pobres para la manipulación de metacontenidos.

XML está considerado el mejor vehículo para definir una sintaxis de metacontenidos
dada su flexibilidad, legibilidad y capacidad de ampliación. Ademas nos proporciona
la posibilidad de definir estos metacontenidos fuera del documento. RDF, CDF y
OSD son ejemplos de formatos de metacontenidos definidos en XML.

Bases de datos

Muchos aplicaciones basadas en el modelo de tres capas extraen los datos a partir
de sistemas remotos de bases de datos. Por lo general, los resultados se
transforman a través de la etiquta <table> del HTML y se muestran en pantalla. Si
los datos se suministran en un documento XML que preserva la información
original, como nombres de columnas y tipos de datos, el cliente puede utilizarlos
para otros fines además de visualizarlos en pantalla. Por ejemplo, podrá descargar
los datos e insertarlos en una hoja de cálculo para realizar sumas y promedios.

Mensajería
Es sin duda alguna el área de aplicación más importante del XML. Por
mensajería se entiende el intercambio de mensajes entre organizaciones o entre
sistemas de aplicación dentro de una misma organización.

La mensajería entre distintas compañías se ha realizado tradicionalmente a través

del EDI (Intercambio ELectrónico de Datos) que ha sido ampliamente utilizado por
sectores tan importantes como el financiero o productivo desde la década de los
setenta.

Uno de los problemas técnicos del EDI tiene que ver con el formato estándar que
debe adoptarse, y aqui XML puede desempeñar un papel decisivo. Entre las
habilidades necesarias para construir un sistema EDI, destaca el conocimiento de
los formatos de los mensajes X12 y EDIFACT. El formato de estos fichero es
complicado de leer. La gran diferencia entre EDI y XML es que en XML, lo nombres
de elementos tienen sentido por si mismos. Es verdad que los mensajes los
procesan normalmente los programas, y no los usuarios de carne y hueso. Pero la
legibilidad sigue siendo un aspecto fundamental para los programadores de
aplicaciones, que desarrollan, depuran y mantienen los programas que procesan los
mensajes EDI.

Aplicaciones para trabajar con XML

Una de las ventajas de trabajar con XML es la gran cantidad de aplicaciones de que
disponemos.

Ni mucho menos vamos a realizar una enumeración exhaustiva de las que existen,
ya que resulta imposible y seguramente en pocas semanas la lista se quedaría
anticuada. Para estar al dia sobre este tipo de aplicaciones os recomiendo que
visiteis las siguientes páginas webs:

• XMLSoftware de James Tauber

• Free XML tools de Lars Marius Garshol.

Pero a continuación vamos a describir brevemente qué tipos de aplicaciones XML

existen y qué podemos hacer con ellas.

Como veremos, existen para todos los lenguajes y plataformas aunque el Java es
sin duda el lenguaje más utilizado para desarrolla rlas. Y es que el Java y el XML
son la pareja perfecta, ya que estamos combinando código portable con
datos portables.

Parsers XML

Son la base de cualquier aplicación XML. Nos permiten:

• Validar un documento XML

• Mediante APIs estandares como son el DOM y el SAX poder manipular (crear,
modificar, leer) los documentos XML
Existen para todos los lenguajes sistemas operativos, y todas las grandes
compañías han desarrollado el suyo.

• IBM
• Microsoft
• Sun
• Oracle

Incluso SUN ya ha incorporado en su API de Java clases que nos permiten trabajar
con documentos XML directamente desde Java.

Browsers XML

Son las herramientas mediante las cuales podemos visualizar los documentos XML.

La última versión de los navegadores más utilizados nos permiten visualizar y

trabajar con documentos XML.

• Las versiones 5 y 6 del Explorer nos permiten visualizar XML utilizando XSLT
y CSS y manipularlo utilizando DOM y JavaScript.
• Las versiones 6.x de Netscape o las versiones más recientes de Mozilla,
permiten también visualizar XML utilizando CSS y DOM.

Pero además existen multiples browsers que nos permiten visualizar algunos
vocabularios XML concretos.

• El navegador CML JUMBO, que nos permite visualizar documentos CML. Este
es un lenguaje XML mediante el cual se pueden describir fórmulas moleculares
y químicas.
• El Amaya Browser, mediante el cual, entre otros, podemos visualizar y crear
documentos Mathml, que es un vocabulario XML para la descripción de
fórmulas matemáticas.
• Un móvil con tecnología WAP incorpora un browser capaz de mostrar páginas
WML, que no es más que un vocabulario XML desarrollado para escribir
páginas para móviles.
• etc.

Editores de XML y DTDs

Para escribir un documento XML o una DTD la única herramienta imprescindible es

un editor de texto, que es precisamente la que utilizaremos a lo largo del curso.

Un editor de XML es un editor de texto especial, que nos acompaña y ayuda en la

elaboración de un documento XML. Existen en los más diversos lenguajes y para las
más diversas plataformas.

En el momento de elegir un editor de XML hay que tener en cuenta sobretodo si

permite trabajar contra una DTD o no. Todos nos ayudarán a construir un
documento XML bien formado, la mayoría nos permitiran comprobar qué es
correcto respecto de una DTD, pero sólo los mejores nos permiten ir
construyendo el documento XML en función de la DTD que lo determina.
De los que conozco, el más recomendable es el XMetal de SoftQuad.

Algunos editores de XML también incorporan herramientas para trabajar con DTD,
aunque para estos casos lo mejor es utilizar herramientas específicas que nos
permiten, por ejemplo, diseñar la DTD de forma gráfica.

Sin duda, las dos mejores son:

• Near and Far Designer de Microstar

• Turbo XML de TIBCO Extensibility

Procesadores XSLT

Estas herramientas nos permiten convertir un documento XML en otro XML (en
particular, en HTML) mediante una XSLT.

Los más conocidos son:

• El XT de James Clark, que es el que utilizaremos durante el curso.

• El Saxon de Michael Kay.
• El Xalan del proyecto XML Apache.

Todos ellos escritos en Java.

El Explorer 5 (y 6) es en sí un procesador XSLT y, por tanto, es capaz de mostrar

un documento XML utilizando este lenguaje de hojas de estilo. Esta característica
también la podemos incorporar en programas en Visual Basic o desde nuestras
ASP.

Otras herramientas

Pero todo lo anterior no es más que un pequeño ejemplo de lo que existe y

podemos hacer:

• Existen conversores de XML a PDF, RTF, etc. y viceversa.

• Hay aplicaciones que permiten buscar en documentos XML.
• Existen utilidades para trabajar con XML y bases de datos.
• Hay herramientas para trabajar con enlaces entre documentos XML.
• etc.

Lo que puede ser más util es que visitéis las dos direcciones que os recomiendo al
principio de esta sección, aunque a lo largo del curso utilizaremos las que indicamos
en el siguiente capítulo.

Aplicaciones que utilizaremos durante el curso

A lo largo de este tutorial se utilizan principalmente las siguientes herramientas

XML:

• Nuestro editor de textos preferido como editor de XML, XSLT, DTD, etc.. Ya
hemos visto que existen editores especializados en este tipo de documentos pero
creo que por el momento es recomendable hacerlo a mano.
 • El Explorer 5 (o 6), que utilizaremos como buscador de XML. Lo encontrareis
facilmenten en el CD que acompaña cualquier revista sobre Internet o lo podéis
bajar del Web de Microsoft. También utilizaremos otros buscadores que nos
permitan visualizar y trabajar con algún vocabulario concreto de XML, aunque
esto ya lo iremos viendo a lo largo del curso.
• La máquina virtual Java de Sun, ya que la otra aplicación que vamos a utilizar
necesita tener instalada dicha máquina virtual para poder funcionar. Si no vais a
desarrollar en Java, es recomendable bajar el JRE, que es más pequeño y
sencillo de instalar.
• El parser de IBM, para validar nuestros documentos XML. En principio
podéis utilizar cualquier parser, aunque los ejemplos que desarrollemos a lo
largo de este tutorial han sido probados y validados con este parser, exactamente
con la versión 1_1_14.

Empezando a trabajar con XML

A lo largo de los capítulos anteriores ya hemos visto algún ejemplo de documento

XML e incluso de DTD, pero sin profundizar en su sintaxis.

A lo largo de este capítulo y los siguientes vamos a estudiar con más detalle la
sintaxis y los elementos que forman un documento XML y cómo podremos
construirlos y comprobar que son correctos.

El siguiente código:

Un documento XML sencillo.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE documento [
<!ELEMENT documento (p | imagen | ejemplo)*>
<!ELEMENT p (#PCDATA|destacar)*>
<!ELEMENT destacar (#PCDATA)>
<!ATTLIST destacar
importancia CDATA #REQUIRED>
<!ELEMENT imagen EMPTY>
<!ATTLIST imagen
fichero CDATA #REQUIRED>
<!ELEMENT ejemplo (#PCDATA)>
]>
<!-- Esto es un comentario -->
<documento>
<p>Mi Primer <destacar importancia="1">documento XML</destacar></p>
<p>Comienza con la etiqueta &lt;documento&gt;</p>
<p>A continuación colocamos un elemento sin contenido</p>
<imagen fichero="imagen.gif"/>
<p>Y ahora una etiqueta CDATA.</p>
<ejemplo>
<![CDATA[
Aqui puedo poner lo que quiera.
] ]>
</ejemplo>
</documento>
Es un ejemplo de documento XML con DTD incorporada. Para cualquier persona que
esté familiarizada con el HTML esta sintaxis le resultará conocida, aunque a simple
vista se pueden observar algunas diferencias importantes:

• Utilizo mis propias etiquetas. Y es que en XML no estamos trabajando

con etiquetas predefinidas. Nosotros podemos crearnos nuestro propio
lenguaje de etiquetas en función de nuestras necesidades.
• La sintaxis es estricta. Ya no vale dejar de entrecomillar los atributos o
utilizar las mayúsculas y minúsculas sin ningún control. La especificación
XML determina claramente una serie de reglas que especifican cuando un
documento está bien formado.
• La utilización de una DTD. En HTML, a pesar de ser una aplicación SGML,
no era obligatorio utilizarlas y, aunque para trabajar con XML tampoco será
necesario, sí que será recomendable. Posiblemente no acompañen al
documento XML en su distribución, pero resultan muy útiles en la
elaboración y validación de los documentos.
• Los elementos vacíos. Son los elementos del tipo <img>, <hr>, etc. de
HTML, en los que no existe etiqueta final al no tener contenido. Ahora, en el
XML, la propia etiqueta de inicio llevará una contrabarra al final que los
identificará.

A lo largo de este capítulo estudiaremos todos estos detalles y muchos más, que
nos permitirán ir entiendo y trabajando con documentos XML.

Marcado y datos

Un documento XML es simplemente un conjunto de cadenas de carácteres en el

que, al igual que en el HTML, podemos diferenciar dos tipos de construcciones:
el marcado y los datos de carácter.

El texto incluido entre los carácteres menor que < y mayor que > o entre los signos
& y ; corresponde al marcado. Son exactamente las partes del documento que tiene
que entender el procesador de XML.

El marcado entre los signos < y > se denomina etiqueta.

El resto no son más que datos de carácter, que corresponden a lo que sería el
contenido del documento; es decir, la parte imprimible de éste.

Componentes de un documento XML

Elementos

Como podemos observar, todo documento XML se compone de uno o más

elementos, cuyos límites están delimitados por etiquetas de comienzo y etiquetas
de fin en el caso de que tengan contenido:

<p>Mi Primer <destacar importancia="1">documento XML</destacar></p>

Y por una etiqueta de elemento vacío en el caso de ser elementos sin contenido:

<imagen fichero="imagen.gif"/>
Cada elemento puede contener datos de carácter, elementos, ambas cosas a la vez
o puede que estén vacíos.

En nuestro caso:

• El elemento documento está formado por otros elementos: p, imagen y ejemplo.

• El elemento p está formado por un contenido mixto: el elemento destacar y datos
de carácter.
• El elemento imagen no tiene ningún contenido.

En el caso de elementos con contenido, las etiquetas de comienzo se componen

del símbolo menor que "<", el nombre del tipo de elemento, los atributos, si los
tiene, y el símbolo mayor que ">". Mientras que las etiquetas de fin se componen
del símbolo menor que seguido de contrabarra "</", el nombre del tipo del
elemento y el símbolo mayor que ">".

En el caso de ser un elemento vacío, sólo hay una etiqueta de elemento vacío que
se forma del símbolo menor que "<", el nombre del tipo de elemento, los atributos
si los tiene y se cierra con el símbolo "/>". Es importante destacar este tipo de
elementos, ya que hasta ahora en el SGML y, por tanto, en el HTML entendido
como aplicación SGML, los elementos vacíos sólo se representaban con una
etiqueta de inicio.

Atributos

Cada elemento puede tener atributos (propiedades) que nos ofrecen información
sobre el elemento.

En nuestro ejemplo:

• El elemento destacar va caracterizado con el atributo importancia, que nos

indicará el grado de relevancia de su contenido.
• El elemento imagenva caracterizado con el atributo fichero, donde indicaremos
el archivo que contiene la imagen.
<p>Mi Primer <destacar importancia="1">documento XML</destacar></p>
.....
<imagen fichero="imagen.gif"/>

Como podemos observar, la definición de un atributo está formada por el nombre

del atributo seguido del símbolo igual "=" y, entrecomillado, el valor del atributo.

Prólogo

Los documentos XML pueden empezar con un prólogo, en el que esencialmente se

define:

• Una declaración XML

• Una declaración de tipo de documento

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE documento [
<!ELEMENT documento (p | imagen | ejemplo)*>
<!ELEMENT p (#PCDATA|destacar)*>
<!ELEMENT destacar (#PCDATA)>
<!ATTLIST destacar
importancia CDATA #REQUIRED>
<!ELEMENT imagen EMPTY>
<!ATTLIST imagen
fichero CDATA #REQUIRED>
<!ELEMENT ejemplo (#PCDATA)>
]>

En la declaración XML,

<?xml version="1.0" encoding="UTF-8"?>

Indicamos:

• Información sobre la versión de XML que estamos utilizando. Por el momento

sólo puede ser la versión 1.0.
• Información sobre el tipo de codificación de carácteres que estamos utilizando.
En nuestro caso es el código ASCII de 7 bits, que es un subconjunto del código
Unicode denominado UTF-8. No hubiese sido necesario declararlo, ya que es el
que los parsers manejan por defecto.El XML soporta los siguientes esquemas de
codificación:
o UTF-8
o UTF-16
o ISO-10646-UCS-2
o ISO-10646-UCS-4
o ISO-8859-1 a -9
o ISO-2022-JP
o Shift_JIS
o EUC-JP
Para que no tengamos problemas con nuestros documentos XML y podamos incluir
tranquilamente acentos, ñ y demás símbolos propios de nuestra lengua es
recomendable que comencemos nuestra declaración XML de la siguiente manera:

<?xml version="1.0" encoding="ISO-8859-1"?>

En la declaración del tipo de documento,

<!DOCTYPE documento [
<!ELEMENT documento (p | imagen | ejemplo)*>
<!ELEMENT p (#PCDATA|destacar)*>
<!ELEMENT destacar (#PCDATA)>
<!ATTLIST destacar
importancia CDATA #REQUIRED>
<!ELEMENT imagen EMPTY>
<!ATTLIST imagen
fichero CDATA #REQUIRED>
<!ELEMENT ejemplo (#PCDATA)>
]>

Asociamos la DTD respecto de la cual construimos el documento. En nuestro

ejemplo va implícita en el propio documento XML, aunque también puede hacerse
externa al documento e incluso de una forma mixta. Si la hubiésemos escrito en un
fichero ejemplo.dtd tendríamos que referenciarla de la siguiente manera:

<!DOCTYPE documento SYSTEM "ejemplo.dtd">

Aunque debemos recordar que a diferencia del SGML, tenemos la posibilidad de no

utilizarla.

Ambas partes del prólogo son opcionales pero en el caso de incluir ambas ,la
declaración XML tiene que ir antes.

Otras construcciones de marcado

Hasta aquí hemos visto los componentes más importantes de un documento XML.
Se todos modos, si observamos el ejemplo veremos que existen otros componentes
que podemos utilizar:

Comentarios

Mediante los cuales podemos proporcionar información que el parser no tendrá en

cuenta.

<!-- Esto es un comentario -->

Los comentarios empiezan con los caracteres "<!--" y terminan con "-->" y pueden
colocarse en cualquier sitio, excepto dentro de las declaraciones, etiquetas y otros
comentarios.

CDATA
Permiten integrar texto en un documento en XML,que de otra forma sería
interpretado como etiqueta. Es decir, estamos introduciendo texto que luego el
procesador XML va a mostrar pero que no va a procesar como marcado.

<![CDATA[
Aqui puedo poner lo que quiera.
] ]>

Los CDATA empiezan con los caracteres "<![CDATA[" y termina con "]]>".

Dentro de ellos podemos colocar cualquier cosa,ya que no va a ser interpretado,

con la salvedad de la cadena que indica el final de CDATA, "]]>",debido a que el
procesador, al encontrársela, entendería que la sección CDATA ya ha terminado con
las nefastas consecuencias que ésto puede tener.

Entidades predefinidas

En XML existen algunos caracteres reservados que no podemos utilizar para evitar
problemas con el marcado, lo que no significa que no tengan que salir en nuestros
documentos XML.

En nuestro ejemplo nos aparece el caso cuando intentamos escribir la etiqueta

<documento>

<p>Comienza con la etiqueta &lt;documento&gt;</p>

Ya hemos visto que una posible solución es la utilización de CDATA, pero sin duda
es poco útil cuando simplemente queremos escribir un carácter.

Las entidades predefinidas son marcas XML que se utilizan para representar estos
caracteres. El XML especifica cinco entidades predefinidas:

• &amp; para el &

• &lt; para el <
• &gt; para el >
• &apos; para el '
• &quot; para el "

Como podemos observar, se reconocen al ir entre los símbolos "&" y ";".

Documentos bien formados y documentos válidos

Como ya hemos mencionado anteriormente, a diferencia del SGML, no es necesario

que un documento XML esté asociado a una DTD.

El documento XML con el que empezábamos este capítulo,lo podíamos haber escrito
de la siguiente manera:

<?xml version="1.0" encoding="UTF-8"?>

<!-- Esto es un comentario -->
<documento>
<p>Mi Primer <destacar importancia="1">documento XML</destacar></p>
<p>Comienza con la etiqueta &lt;documento&gt;</p>
<p>A continuacion colocamos un elemento sin contenido</p>
<imagen fichero="imagen.gif"/>
<p>Y ahora una etiqueta CDATA.</p>
<ejemplo>
<![CDATA[
Aqui puedo poner lo que quiera.
] ]>
</ejemplo>
</documento>

Y si lo pasásemos por un parser de XML no nos daría ningún error.

Por tanto, en función de si lleva asociada una DTD o no, podemos diferenciar dos
tipos de documentos XML:

• Válidos, aquellos que siguen las reglas de una DTD específica.

• Bien formados (well- formed), que no tienen necesariamente una DTD asociada,
pero siguen las reglas del XML al pie de la letra.

Evidentemente, los documentos válidos son bien formados.

Documentos XML bien formados

En los capítulos anteriores ya hemos visto de forma generalizada que una de las
características que diferencian al XML del SGML es la posibilidad de no utilizar DTD.

En una DTD definimos cómo va a ser un tipo de documento; es decir, definimos los
elementos, atributos y entidades que lo van a formar, cómo se estructuran y
relacionan. Por tanto, si en la elaboración de nuestros documentos XML no
utilizamos ninguna, el parser no puede proporcionarnos información sobre la
validez de ese documento; dicho de otro modo , no nos puede indicar que los
elementos y atributos que utilizamos son los correctos y si encuentran en el orden
adecuado.Simplemente nos indicará si ese documento está bien formado o no, es
decir, si respeta las reglas sintácticas del lenguaje XML.

Según la especificación, un objeto de texto es un documento XML bien

formado si:

• Tomado como un todo, cumple la regla denominada "document".

• Respeta todas las restricciones de buena formación dadas en la
especificación.
• Cada una de las entidades analizadas que se referencia directa o
indirectamente en el documento está bien formada.

A lo largo de los próximos dos capítulos vamos a estudiar con más detalle esta
definición, de manera que tengamos claro cómo tiene que ser un documento de
texto para ser aceptado por un parser como un documento XML bien formado.

La regla "document"

Cumplir la regla "document" antes mencionada significa:

1. Que contiene uno o más elementos.

 2. Hay exactamente un elemento, llamado raíz, o un elemento documento del cual
ninguna parte aparece en el contenido de ningún otro elemento.
3. Para el resto de elementos, si la etiqueta de comienzo está en el contenido de
algún otro elemento, la etiqueta de fin está en el contenido del mismo elemento.
Es decir, los elementos delimitados por etiquetas de principio y final se anidan
de forma adecuada mutuamente.

El siguiente ejemplo no es un documento XML bien formado,

Mi primer documento XML

ya que no contiene ningún elemento y, por tanto, está incumpliendo la regla

número 1.

En cambio,

<p>Mi primer documento XML</p>

sí que lo es, al contener al menos el elemento "p". La principal razón por la que el
procesador comprueba los elementos es para determinar si el documento tiene
estructura de datos que pueda extraer. Un documento que carece de elementos no
tiene estructura de datos. Un documento con al menos un eleme nto tiene
estructura de datos.

En cambio,

<p>Mi primer documento XML</p>

<p>Mi primer documento XML</p>

no es un documento XML bien formado al incumplir la regla número 2, según la

cual sólo puede existir un único elemento raíz.

Aunque escrito de la siguiente manera sí que es correcto,

<documento>
<p>Mi primer documento XML</p>
<p>Mi primer documento XML</p>
</documento>

al convertirse el elemento "documento" en el elemento raíz, ser único y no formar

parte del contenido de ningún otro elemento.

En cambio, el siguiente ejemplo,

<documento>
<p>Mi primer <destacar>documento XML</p></destacar>
<p>Mi primer documento XML</p>
 </documento>

es incorrecto al incumplir la regla 3, ya que la etiqueta inicio del elemento

"destacar" está dentro del contenido del elemento "p", pero su etiqueta final está
fuera.

La forma correcta sería la siguiente:

<documento>
<p>Mi primer <destacar>documento XML</destacar></p>
<p>Mi primer documento XML</p>
</documento>

Ejercicio: Documento XML que incumple la regla Document

Para practicar, vamos a realizar varios ejercicios durante el curso. En este, deberéis
indicar qué partes de la regla "document" incumple el siguiente documento:

<libro>
<titulo>El Quijote</titulo>
<libro>
<titulo>EL Lazarillo de Tormes</titulo>
<autor>Anonimo
<libro></autor>
<libro>

Solución:

Incumple las reglas 2 y 3.

• La regla 2 porque el elemento raíz libro existe más de una vez.

• La regla 3 porque el eleme nto autor empieza dentro del elemento libro pero en
cambio termina fuera.

Sintaxis correcta y restricciones de buena formación

Además de las reglas anteriormente mencionadas, para escribir documentos XML

bien formados tenemos que conocer perfectamente la sintaxis del lenguaje XML y
algunas restricciones que la especificación impone.

Es como en cualquier lenguaje tenemos que conocer la sintaxis de cómo se

escriben los elementos, atributos y entidades, y ,si las incumplimos, el "parser" nos
dará un error de mala formación. Algunas de estas reglas ya las hemos visto en el
capítulo anterior: cómo se escriben las etiquetas de inicio y final, cómo se escriben
las etiquetas de elementos vacios, cómo tenemos que escribir los atributos etc. y es
evidente que si no seguimos estas reglas el parser nos dará error.

En el siguiente ejemplo:

Documento XML mal formado. Miscelánea de errores,

<?xml version="1.0"?>
 <documento>
<p>Mi Primer <destacar importancia=1>documento XML</destacar></p]
<p>Comienza con la etiqueta <documento&gt;</p>
<p>A continuacion colocamos un elemento sin contenido</p>
<imagen fichero="imagen.gif">
</documento>

nos encontramos con cuatro errores:

• El valor del atributo "importancia" no está entrecomillado. En HTML es

posible no entrecomillar el valor de los atributos, pero en XML es obligatorio.

Tendríamos que haber escrito:

...<destacar importancia="1">documento XML</destacar>...

• La etiqueta final, del elemento "p", está mal cerrada. En lugar del carácter
"]" , tendríamos que poner el símbolo mayor que ">".
•
• <p>Mi Primer <destacar importancia=1>documento
XML</destacar></p>
•
• Estamos utilizando el símbolo menor que "<" sin que forme parte de la
definición de una etiqueta. Al ser un carácter reservado, tendríamos que
escribirlo como la entidad predefinida &lt;.
•
• <p>Comienza con la etiqueta &lt;documento&gt;</p>
•
• Estamos escribiendo el elemento vacío "imagen" de forma incorrecta. Al ser
un elemento sin contenido tendríamos que haberlo escrito con una etiqueta
de elemento vacío:
•
• <imagen fichero="imagen.gif"/>
•

o también de la siguiente manera:

<imagen fichero="imagen.gif"></imagen>

Ambas son correctas, aunque es recomendable la primera.

Por tanto, el ejemplo anterior bien escrito:

Documento XML bien formado

<?xml version="1.0"?>
<documento>
<p>Mi Primer <destacar importancia="1">documento XML</destacar></p>
<p>Comienza con la etiqueta &lt;documento&gt;</p>
<p>A continuacion colocamos un elemento sin contenido</p>
<imagen fichero="imagen.gif"/>
</documento>

Otras reglas que debemos tener en cuenta son:

• El XML es sensible a la utilización de mayúsculas y minúsculas.

En el siguiente ejemplo:

<p>Mi primer documento XML</p>

<P>Mi primer documento XML</P>

los elementos "p" y "P" son diferentes.

Hay que tener mucho cuidado con esta regla, ya que su incumplimiento es
habitual y suele ser la causa de la mayor parte de los errores. Es
recomendable antes de empezar a escribir un documento XML establecer un
criterio al respecto.

• El nombre de la etiqueta de inicio y final debe ser el mismo.

El siguiente ejemplo es incorrecto

<p>Mi primer documento XML</P>

ya que al hacer diferencia entre mayúsculas y minúsculas, el parser no

entiende ambas etiquetas como del mismo elemento.

• Ningún nombre de atributo puede aparecer más de una vez en la misma

etiqueta de inicio o de elemento vacío.

El siguiente ejemplo es incorrecto:

...<destacar importancia="1" importancia="2">documento

XML</destacar>...

Un consejo; si utilizais el bloc de notas recordad que para que funcione todo el
tinglado debeis guardar los ficheros con extensión ".xml". El bloc de notas
procurará por todos los medios que los ficheros se guarden con extensión ".txt".
Para conseguir que guarde el fichero con la extensión que deseamos, cuando
tengamos la ventana de diálogo escogeremos en el desplegable "Todos los ficheros
(*.*)" y pondremos el nombre del fichero con la extensión entre comillas dobles en
el campo correspondiente.

Ejercicio: Documento XML no valido

Reescribir el siguiente ejemplo para que sea un documento XML bien formado.

<?xml version="1.0"?>
 <libros>
<libro id="quijote">
<titulo>El Quijote</titulo>
<autor nombre=cervantes nombre=cervantes>
<descripcion>Es el m<ejor libro de cervantes.</descripcion>
</libro]
</Libros>

Solución:

Aprovecharemos este ejercicio para ver que el IE5 es una estupenda herramienta
para comprobar que nuestros documentos son documentos XML bien formados.

Por ejemplo, si abrimos el XML del enunciado de este ejercicio observaremos

cómo nos va indicando de forma muy clara los errores que tiene.

En primer lugar, nos indica que el valor del atributo nombre no está entrecomillado.

En segundo lugar, nos indica que se produce un error por tener duplicado el
nombre del atributo nombre.

En tercer lugar, ya nos indica un error que no resulta tan claro, aunque nos debe
resultar fácil adivinar que se produce porque estamos utilizando el símbolo menor
que "<" sin que forme parte de la definición de una etiqueta. Al ser un carácter
reservado, tendriamos que escribirlo como la entidad predefinida &lt;.

A continuación se está dado cuenta de que el elemento autor está mal anidado, es
decir, que parece ser que queremos cerrar el elemento linea sin tener cerrado el
elemento autor. Hay que tener en cuenta que, en nuestro ejemplo, el autor es un
elemento vacio y que, por tanto, deberíamos cerrarlo.
A continuación produce un error porque hemos cerrado con un carácter no válido la
etiqueta libro.

Y en último lugar nos indica que no reconoce </Libros> como etiqueta de cierre
para el elemento libros. Hay que recordar que el XML diferencia entre mayúsculas y
minúsculas, lo que significa que libros y Libros no es lo mismo.

Por tanto, el documento XML bien formado quedará de la siguiente manera:

<?xml version="1.0"?>
<libros>
<libro id="quijote">
<titulo>El Quijote</titulo>
<autor nombre="cervantes"/>
<descripcion>Es el m&lt;ejor libro de cervantes.</descripcion>
</libro>
</libros>

Ejercicio: Escribir un documento XML bien formado que represente un catálogo de

libros

Escribir un documento XML válido que represente un catálogo de libros.

Como mínimo sería recomendable que cada libro tuviese información sobre:

• Título
• Autor
• ISBN

Utilizar el IE5 para verificar que esté bien formado e incluir al menos dos o tres
libros.

Solución:

Un documento XML que se ajuste a estas condiciones podría ser por ejemplo:

<?xml version="1.0" encoding="ISO-8859-1"?>

<libros>
<libro isbn="91-901-533-7">
<titulo>XML: Extensible Markup Languge</titulo>
<autor>Elliote Rusty Harold</autor>
<editorial>Prentice Hall</editorial>
<descripcion>Estupendo libro sobre XML</descripcion>
</libro>
<libro isbn="84-415-0845-3">
<titulo>XML</titulo>
<autor>Natanya Pitts</autor>
<editorial>Anaya Multimedia</editorial>
<descripcion>Buen libro de introducción al XML</descripcion>
</libro>
</libros>

Lo más posible es que la estructura de este XML sea diferente a la que vosotros
hayáis escrito, pero esto por el momento no es importante.

Lo interesante del ejercicio es que hayáis escrito un documento XML que se

visualice correctamente en el IE5.

Ejercicio: Validar el documento XML utilizado parser de XML

Validar el anterior documento XML, mediante el cual representábamos un catálogo

de libros utilizando un parser de XML.

Solución:

Como ya comentamos en un principio, cualquier parser de XML es válido para

realizar este ejercicio.

En este tutorial utilizaremos el parser de IBM, exactamente la versión

xml4j_1_1_14. Es una versión antigua del parser. No importa, ya que esta
versión sirve perfectamente para nuestras necesidades.

Para ello nos podemos bajar el siguiente fichero zip., que contiene:

• Los dos ficheros .jar que realmente hacen falta para utilizar el parser.
o xml4j_1_1_14.jar, que contiene el parser propiamente dicho.
o xml4jSamples_1_1_14.jar, que contiene unos ejemplos de como
utilizarlo.

Una vez que tenemos los jar, y declarados en nuestro classpath para validar un
documento XML, no tendremos más que escribir:

java samples.XJParse.XJParse -d [nombreficheroXML] >tmp.txt

Por si alguno no está muy puesto en Java, se puede hacer de la siguiente manera:

1. Colocar los .jar en un directorio classes que tengo colgando de la unidad C, y

donde estan todos los .jar que utilicen las aplicaciones en Java.
2. Luego en lugar de declarar estos .jar en el classpath, se definen desde linea de
comandos en el momento que ejecutar la clase Java correspondiente. Como esto
en algunas ocasiones puede ser farragoso, es aconsejable crear un fichero .bat
donde se coloca el código. Para este caso he creado un fichero pxml.bat que
lanza el parser xml.

Por tanto, en nuestro ejemplo, para validar nuestros documentos xml, no

tendremos más que escribir:
pxml catalogo_libros.xml

Si tenemos instalado el JRE, lo mejor será colocar los .jar directamente en el

directorio lib/ext , dentro del directorio donde esté instalado el JRE, puesto que Java
busca en dicho directorio por defecto los .jar que pueda necesitar. Entonces con
escribir la línea:

java samples.XJParse.XJParse -d [nombreficheroXML] >tmp.txt

Será suficiente. Os recomiendo que modifiquéis el documento XML de manera que

sea erróneo para observar cómo el parser indica los errores.

Las entidades

Todavía no hemos hablado mucho de las entidades,pero, como veremos más

adelante, resultan muy importantes en la elaboración y mantenimiento eficiente de
nuestros documentos XML.

Una de sus funcionalidades es la de permitirnos elaborar un documento XML en

"trozos"; es decir, tendremos un único documento XML, pero éste físicamente se
encontrará dividido en varios ficheros.

Por el momento no vamos a profundizar más en este aspecto, pero lo que hay que
tener en cuenta es que para el parser se trata de un único documento XML y que,
por tanto, sus diferentes partes, aún encontrándose en ficheros distintos, deben
verificar las reglas de buena formación descritas anteriormente.

Documentos XML válidos. Las DTD

En el anterior capítulo estudiamos las reglas a seguir para poder crear documentos
XML bien formados. En este capítulo avanzamos un paso más y veremos qué son y
qué tenemos que hacer para crear documentos XML válidos

Un documento XML válido es un objeto de texto que,además de ser un documento

XML bien formado, sigue las reglas de una DTD específica.

Pero veamos qué es exactamente una DTD.

¿Que es una DTD?

Una DTD (Document Type Definition) es un conjunto de reglas para definir un

documento XML y etiquetarlo adecuadamente. En una DTD definimos los
"componentes" de un documento XML y cómo se relacionan y estructuran.

Es importante tener en cuenta que una DTD no es más que una interpretación de
un texto. Si tenemos un conjunto de documentos de texto que queremos convertir
en documentos XML, en primer lugar debemos abstraer y generalizar los elementos
de que se componen y cómo están estructurados. La declaración práctica de estos
elementos y las reglas que los componen será la DTD de ese tipo de documentos.
Evidentemente, esta abstracción y la forma de implementarla depende del autor
que la elabore y,por tanto, es subjetiva, por lo que es posible que para un mismo
documento se elaboren diferentes DTD.

La siguiente porción de texto es una DTD:

Ejemplo de DTD para HTML simple
<!ELEMENT mihtml (c1 | parrafo)*>
<!ELEMENT c1 (#PCDATA)>
<!ELEMENT parrafo (#PCDATA|negrita)*>
<!ELEMENT negrita (#PCDATA)>

Como podemos observar, en la práctica no es más que un conjunto de

declaraciones.

Cada declaración empieza con la cadena "<!" y termina con la cadena "mayor que"
">". A continuación del símbolo de admiración viene una de las palabras reservadas
del XML para especificar el tipo de objeto que se quiere definir, seguido del nombre
del objeto declarado y los parámetros asociados.

<!objeto_declarado nombre_de_objeto parametros_asociados>

El XML soporta cinco tipos de declaraciones:

• DOCTYPE
• ELEMENT
• ATTLIST
• ENTITY
• NOTATION

de las cuales DOCTYPE, ELEMENT y ATTLIST serán estudiadas con más detalle en
este capítulo.

Declarando la DTD

Las declaraciones que forman la DTD pueden estar definidas en los siguientes
lugares:

• Dentro del propio documento XML.

• En algún fichero externo que luego referenciamos desde el documento XML.

Aunque esto no significa que se tengan que definir en su totalidad en alguno de

estos lugares. Las declaraciones que la forman puede estar en parte en el fichero
externo y en parte en el propio documento XML. Por tanto, hay que tener cuidado y
no considerar simplemente como DTD el fichero externo, sino el conjunto de todas
las declaraciones DTD, tanto las externas como las internas.

La declaración de una DTD empieza con la declaración DOCTYPE seguida del

nombre de un ele mento, que debe corresponder con el que definamos en la DTD,
como el elemento raíz (Elemento documento).

<!DOCTYPE nombre_de_tipo_de_documento ....

En nuestro ejemplo tendría el siguiente aspecto:

<!DOCTYPE mihtml ....

A partir de aquí, dependiendo de si las declaraciones de la DTD, son exclusivamente
internas, externas o mixtas, cambiará lo que tenemos que colocar en los puntos
suspensivos.

La DTD en el interior del documento XML

En el caso de que las declaraciones de la DTD sean exclusivamente interiores, la

declaración DOCTYPE tiene el siguiente aspecto:

<!DOCTYPE nombre_de_tipo_de_documento
[declaracions que forman la DTD]>

quedando en nuestro ejemplo de la siguiente manera:

<?xml version="1.0"?>
<!DOCTYPE mihtml [
<!ELEMENT mihtml (c1 | parrafo)*>
<!ELEMENT c1 (#PCDATA)>
<!ELEMENT parrafo (#PCDATA|negrita)*>
<!ELEMENT negrita (#PCDATA)>
]>
<mithml>
.....
</mithml>

es decir, a la expresión de partida abrimos un corchete '[' realizamos las

declaraciones, en las que definimos elementos, atributos, entidades, etc., y
cerramos la declaración con la expresión "]>".

No es demasiado frecuente que una DTD sea declarada en su totalidad dentro del
documento XML

La DTD exterior al documento XML

En este caso, el conjunto de las declaraciones DTD irán en un fichero externo, por
lo que parece normal que a la declaración DOCTYPE tendremos que indicarle de
alguna manera donde se encuentra este fichero.

Esto se realiza añadiendo a la expresión inicial las palabras clave SYSTEM o PUBLIC.

En el caso de que sea "SYSTEM",a continuacion indicamos el identificador de

sistema, que no es más que una URI (Indenficador Universal de Recursos, una
forma ampliada del URL) donde se encuentra el fichero que contiene la DTD.

Suponiendo que hemos guardado las declaraciones de la DTD en un fichero

mihtml.dtd que se encuentra en el mismo directorio que el fichero XML,la
declaración tendría el siguiente aspecto:

<!DOCTYPE mihtml SYSTEM "mihtml.dtd">

<mihtml>
....
</mihtml>

En el caso de utilizar PUBLIC estaremos indicando que, además del identificador de

sistema, identificamos la DTD con un identificador público (unívoco).
<!DOCTYPE mihtml PUBLIC "-//Joaquin Bravo//DTD HTML Ciberaula//EN"
"mihtml.dtd">
<mihtml>
....
</mihtml>

De esta manera el procesador XML ya se encargará de convertir dicho identificador

en un URI. Esta equivalencia posiblemente se obtenga en un fichero que suele
denominarse "catalógo de entidades" que es donde se establece tal relación.

En el caso de que no se pueda establecer esta relación utilizará el identificador de

sistema.

Cabe destacar que esta última característica depende mucho de las

aplicaciones XML que utilicemos y debemos tener en cuenta qué formato de
catálogos maneja y si los maneja.

La ventaja de trabajar con DTD declaradas en ficheros externos es evidente, si

tenemos en cuenta que esa misma DTD puede ser utilizada para múltiples
documentos XML. La modificación de esta DTD sólo implicaría realizar
modificaciones en un único fichero y no en todos los documentos XML que la
utilizan.

La DTD con declaraciones interiores y exteriores

Es posiblemente la forma más habitual de trabajar con las DTD. En la declaración

externa de la DTD se definen los elementos, atributos y entidades que formarán
ese tipo de documento, y en la declaración interna se definen algunas
características propias de ese documento que no van a aparecer en otros del mismo
tipo.

La forma de indicarlo en la declaración DOCTYPE es una mezcla de las formas

anteriores. Se define como una DTD externa, pero en lugar de cerrar con el símbolo
mayor que ">" abrimos el símbolo "[" para poder definir declaraciones de DTD
internas y cerramos con la expresión "]>".

Por ejemplo, esta forma de trabajar es muy utilizada para la declaración de

entidades (en un capítulo posterior se estudia en detalle el tema de las entidades)
particulares de ese documento. Imaginemos que estamos escribiendo un
documento XML en el que una cadena de texto se repite constantemente y
queremos evitarnos el tener que escribirla cada vez. Este problema lo podemos
solucionar de la siguiente manera:

<!DOCTYPE mihtml SYSTEM "mihtml.dtd" [

<!ENTITY texto "En un lugar de la mancha"
]>
<mihtml>
<p>&texto;</p>
<p>&texto;</p>
<p>&texto;</p>
<p>&texto;</p>
</mihtml>

Si observamos este documento XML en el IE5 nos lo mostrará de la siguiente

manera:
También se puede utilizar para añadir nuevos elementos, listas de atributos, etc..
Imaginemos que queremos añadir texto en cursiva dentro del elemento parrafo en
un documento XML basado en nuestra mihtml, y sólo queremos que funcione en
este documento. Y lo haremos creando un nuevo elemento que denominamos
cursiva

<!DOCTYPE mihtml SYSTEM "mihtml.dtd" [

<!ELEMENT parrafo (#PCDATA|negrita|cursiva)*>
<!ELEMENT cursiva (#PCDATA)>
]>
<mihtml>
<parrafo>Texto en <cursiva>cursiva</cursiva></parrafo>
</mihtml>

Evidentemente, hemos tenido que redefinir el elemento parrafo para que en su

contenido contemple el elemento cursiva. Hay que tener en cuenta que se
procesan antes las declaraciones internas que las externas.

Definición de los elementos

El XML no tiene elementos predefinidos. Cuando nos ponemos a escribir un

documento XML, no disponemos del H1, A o del IMG del HTML. Podemos utilizar
nuestros propios elementos, los cuales se definen en la DTD.

Esto lo realizamos mediante la declaración ELEMENT cuya sintaxis es la siguiente:

<!ELEMENT nombre_elemento (especificacion del contenido)>

Especificación del contenido

En esta parte de la declaración indicamos cúal va a ser el contenido de ese

elemento. Como ya hemos visto en capítulos anteriores tenemos cuatro
posibilidades:

• Que no tenga contenido.

• Que esté formado sólo por texto.
• Que esté formado únicamente por elementos.
• Que tenga un contenido mixto de texto y elementos.

Sin contenido
Esto se determina colocando la palabra clave EMPTY en la declaración del
contenido. Son elementos que no tienen contenido y su valor suele estar
determinado por los atributos. Es el caso de los elementos IMG, HR, BR, etc., del
HTML.

Si a nuestro ejemplo de miniHTML queremos añadirle la posibilidad de trabajar con

imágenes, como un elemento sin contenido cuyas propiedades especificaremos en
los atributos, y que éstas puedan aparecer en cualquier lugar del documento,
tendremos que añadir las siguientes declaraciones:

<!ELEMENT mihtml (c1 | parrafo | imagen)*>

....
<!ELEMENT imagen EMPTY>

Luego en el XML lo tendremos que escribir de la siguiente manera:

<imagen ...atributos... />

Contenido formado sólo por texto

Esto lo conseguimos colocando la palabra clave #PCDATA en la espeficicación del

contenido. De esta manera estamos indicando que dentro de ese elemento no
puede haber ningún otro elemento y que, por tanto, sólo nos encontraremos texto.
En nuestro ejemplo es el caso del elemento negrita.

<!ELEMENT negrita (#PCDATA)>

Este elemento en XML se escribirá:

....<negrita>texto</negrita>.....

Contenido formado sólo por elementos

En este caso en la especificación del contenido sólo debemos indicar los nombres
(identificadores genéricos) de otros elementos. Posiblemente éstos estén
relacionados mediante los indicadores de aparición y conectores de grupo que
explicamos más adelante.

En nuestro ejemplo es el caso del elemento mihtml en cuya declaración indicamos

que estará formado por los elementos: c1, para e imagen.

<!ELEMENT mihtml (c1 | parrafo | imagen)*>

Este elemento en XML se escribirá por ejemplo:

<mihtml>
<parrafo>....</parrafo>
<parrafo>....</parrafo>
</mihtml>

Contenido mixto
También es posible combinar los dos últimos casos y declarar la especificación de
contenido, de manera que un elemento tenga texto y otros elementos.

En nuestro ejemplo es el caso del elemento para, que puede estar formado de texto
y de elementos negrita.

<!ELEMENT parrafo (#PCDATA|negrita)*>

Como podemos observar, no tenemos más que combinar la palabra clave #PCDATA
con los nombres de los elementos que contendra.

Este elemento en XML se escribirá por ejemplo:

<parrafo>Esto es un <negrita>parrafo</negrita></parrafo>

<parrafo>Esto es un parrafo</parrafo>

Posiblemente, el nombre de contenido mixto no sea el más adecuado, ya que como

vemos en el ejemplo el modelo de contenido mixto no significa que siempre deban
incluirse tanto elementos como texto.

También es posible indicar que un elemento puede contener cualquier elemento o

carácter. Esto se consigue mediante la palabra clave ANY . Es muy poco utilizado,
aunque puede ser muy útil durante el proceso de creación de una DTD cuando
todavía no tenemos muy claro cuál será el contenido de un elemento.

Conectores de grupo

El modelo de contenido puede contener más de un elemento y,por tanto, se

necesita información adicional que especifica el orden en el que aparecen. Para ello
utilizamos los contectores de grupo. En el XML hay dos posibles conectores de
grupo:

• , indica que deben aparecer en ese orden.

• | indica que sólo uno de los componentes puede aparecer.

Si nos fijamos en nuestro ejemplo, utilizamos esencialmente el conector | mediante

el cual indicamos que el autor del documento XML puede elegir entre un elemento u
otro.

Por ejemplo, en:

<!ELEMENT mihtml (c1 | parrafo | imagen)*>

estamos indicando que dentro del elemento mihtml el autor puede poner o el
elemento c1, o el elemento parrafo, o el elemento imagen.

Es decir, que los siguientes ejemplos son todos válidos.

<mihtml>
<parrafo>...</parrafo>
</mihtml>
<mihtml>
 <c1>...</c1>
</mihtml>
<mihtml>
<imagen/>
</mihtml>

Otro tema es el indicador ,* que nos indica que ese modelo de contenido se puede
repetir y que, por tanto, esos tres elementos pueden aparecer tantas veces como
quieran.

En cambio el conector "," establece una secuencia que debe seguirse. Imaginemos
que en nuestro pequeño HTML queremos incluir la posibilidad de tener listas
ordenadas y que éstas puedan estar ordenadas. Si al elemento lista ordenada lo
identificamos mediante el elemento lo y a sus entradas "items" mediante el
elemento item, su declaración en la DTD quedaría de la siguiente manera:

<!ELEMENT lo (item, (lo|item)*)>

<!ELEMENT item (#PCDATA)>

Mediante el conector ,, estamos indicando que dentro de un lo en prime r lugar debe

haber un item y que luego puede venir otro "item" o empezar otra lista. Un texto
XML que se ajuste a esta definición podría ser:

<lo>
<item>Texto</item>
<item>Texto</item>
<lo>
<item>Texto</item>
<item>Texto</item>
</lo>
</lo>

Indicadores de aparición

Se utilizan para indicar cuántas veces puede aparecer el elemento referenciado en

el modelo de contenido. Hay tres indicadores de aparición:

• + Indica que puede haber una o más apariciones del elemento.

• ? Indica que puede haber a lo más una o ninguna aparición del elemento.
• * Indica que el elemento puede estar ausente, una o más veces.

Como ya hemos explicado, dentro del elemento mihtm, los elementos c1, parrafo o
elemento imagen pueden aparecer en el orden que quieran, pero tantas veces
como quieran, o incluso ninguna. Esta última característica la indicamos mediante
el indicador *.

Pero imaginemos que queremos que el primer elemento de una lista ordenada no
sea siempre el elemento item, sino que queremos permitir que sea lo. En tal caso
podríamos definir el elemento de la siguiente manera:

<!ELEMENT lo (item?, (lo|item)*)>

Donde con item? estamos indicando que puede aparecer 0 o 1 veces y que, por
tanto, el siguiente ejemplo es válido.
<lo>
<lo>
<item>Texto</item>
<item>Texto</item>
</lo>
</lo>

Aunque en este caso conseguiríamos el mismo efecto definiendo el elemento de la

siguiente manera:

<!ELEMENT lo (lo|item)*>

Añadiendo atributos a los elementos

Del mismo modo que los elementos, los atributos se declaran en la DTD utilizando
una sintaxis bastante similar. En este caso se realiza mediante el término ATTLIST,
que en el comienzo de una declaración indica que es una especificación de una lista
de atributos.

<!ATTLIST nombre_elemento
nombre_atributo tipo valor_defecto>

Como podemos observar, la primera muestra indica el elemento sobre el cual se

van a definir los atributos y, a continuación, viene una tripla de datos en los que
indicamos:

• El nombre del atributo

• El tipo
• Y su valor por defecto.

Esta tripla se puede repetir tantas veces como queramos dentro de la declaración,
es decir, podemos declarar una lista de atributos, de ahí su nombre.

Un ejemplo de definición de atributos para nuestro elemento imagen podría ser:

<!ATTLIST imagen
direccion CDATA #REQUIRED
alineacion (izquierda, centrada, derecha) "izquierda">

Tipo

Una utilidad importante de los atributos es que mediante el tipo podemos hacer
cumplir al elemento obligaciones léxicas o semánticas. Las obligaciones léxicas son
por ejemplo "este atributo debe contener sólo números" y las semánticas son "este
atributo debe contener el nombre de una entidad declarada". Evidentemente estas
obligaciones son muy útiles, ya que nos permiten garantizar la integridad de
algunos de los valores de los atributos, pero la verdad es que son bastante
limitadas y en muchas ocasiones insuficientes.

Los tipos de atributos pueden ser:

• CDATA
• NMTOKEN
• NMTOKENS
• ENUMERADOS
 • NOTATION
• ID
• IDREF
• IDREFS
• ENTITY
• ENTITYS

En teoria las posibilidades son muchas, aunque luego en la práctica sin duda alguna
los más utilizados son los CDATA y el ID.

CDATA

Es el tipo de atributo más sencillo.Mediante su utilización estamos indicando que el

valor del atributo debe ser de tipo carácter. Es, por tanto, de todos los tipos el que
menos obliga.

Al especificar el atributo direccion de nuestro elemento imagen:

<!ATTLIST imagen
direccion CDATA #REQUIRED
...

estamos indicando que el valor del atributo dirección puede llevar cualquier tipo de
carácter.

ID

Mediante este tipo de atributo identificamos de forma unívoca un elemento del

documento XML. Su valor debe ser único en el documento.

Imaginemos que queremos identificar de forma unívoca los elementos c1, de

manera que luego sean fácilmente identificables y referenciables. Esto lo
tendríamos que indicar:

<!ATTLIST c1
id ID #REQUIRED
...

IDREF

Está estrechamente ligado al tipo de atributo ID, y mediante su utilización estamos

indicando que hacemos referencia al valor de algún atributo ID.

NMTOKEN

Estos atributos se parecen en parte a los atributos CDATA. La principal diferencia es

que sólo aceptan lo caracteres.

ENUMERADOS

Ofrecen al usuario la posibilidad de elegir entre un número reducido de valores.

Es el caso, por ejemplo, del atributo alineacion en el elemento imagen:

<!ATTLIST imagen
.....
alineacion (izquierda, centrada, derecha) "izquierda">

Donde estamos indicando que los únicos valores permitidos para el atributo
alineacion son: izquierda, centrada y derecha.

Valor por defecto

La última parte de la especificación sirve para indicar al parser cómo debe

interpretar la ausencia de atributo.

Ya hemos visto que en este lugar podemos indicar, el valor que puede tener por
defecto.

Pero en el caso de que esto no sea así,indicamos al parser cómo debe interpretar la
ausencia de atributo con las siguientes palabras reservadas:

• #REQUIREDestamos indicando que es obligatorio colocar un valor en el

atributo.
• #IMPLIED, indicamos que el valor para ese atributo es opcional, puede tener o
no tener.
• #FIXED, estamos fijando el valor del atributo y el docume nto no será válida si a
ese atributo le damos un valor diferente al especificado.

Escribiendo nuestras propias DTD

En los próximos capítulos vamos a escribir unas DTD complejas que os servirán de
ejemplo para futuros desarrollos.

Cada una se corresponderá con un tipo de documento, de los que distinguiremos

cuatro, por lo que trabajaremos con cuatro DTD diferentes. Tres las elaboraremos
nosotros:

• articulo.dtd
• bookmark.dtd
• novedades.dtd

y una cuarta, que nos permitirá escribir las FAQs; utilizaremos la QAML.dtd, que ya
está desarrollada.

En el próximo capítulo empezaremos describiendo en detalle el proceso de

elaboración de una DTD para escribir artículos y, en los siguientes, explicaremos de
forma más breve el resto de las DTD.

DTD de artículos

En la elaboración de una DTD podemos diferenciar tres pasos:

• El proceso de abstracción de los elementos que forman un tipo de documento y

las relaciones que existen entre ellos.
• Plasmación de este proceso de abstracción en una DTD.
 • Validación de la DTD y verificación práctica de que se ajusta a nuestras
necesidades.

Estructura lógica del tipo de documento artículo

La primera parte es sin duda alguna la más complicada y posiblemente la más

importante. Es el momento en el cual vamos a estructurar la información que luego
representaremos mediante una DTD. No es un problema de conocer el XML o de
saber las DTD. Es sobretodo una cuestión de tener clara la información con
la que vamos a trabajar, qué elementos la componen,qué características tienen y
cómo vamos a organizarla.

Un artículo a un nivel general está formado por dos partes bien diferenciadas: el
contenido del artículo y la metainformación sobre el artículo.

La metainformación no es más que la información relativa al contenido del

documento, como su título, autor, tamaño del archivo, fecha de creación, historial
de los cambios, palabras clave, y demás información asociada.

En nuestro caso vamos a utilizar:

• título
• autor
• palabras clave
• resumen

En esta parte podríamos poner mucha más información, toda la que creamos que
nos puede hacer falta. Toda esta información nos puede resultar útil, por
ejemplo,para la búsqueda y gestión de estos documentos.

En la parte de contenido tendremos que identificar los elementos que nos

permitan representar esos contenidos. Si tomamos como ejemplo este tutorial, que
puede considerarse como una generalización de nuestro documento artículo,
observamos que la información está organizada en bloques de texto (párrafos,
listas, tablas) e imágenes. Y que además estos bloques están organizados
estructuralmente en capítulos y subcapítulos Esta estructura para nuestros artículos
será igual: representaremos la información mediante elementos párrafos, listas,
imágenes, etc. y la organizaremos en subcapitulo1es y subsubcapitulo1es.
En nuestro caso utilizaremos exactamente los siguientes eleme ntos:

• párrafos
• listas, tanto ordenadas como desordenadas
• imágenes
• código, ya que nuestros artículos (al menos en el ejemplo que desarrollamos)
serán sobre temas informáticos.

Y estructuralmente toda la información anterior podrá estar organizada en

subcapitulo1es.

También debemos tener en cuenta qué elementos pueden existir dentro de esos
bloques de texto. Podríamos querer destacar parte del contenido del texto, porque
es el nombre de una función o el nombre de un autor; podríamos querer poner
referencias a otro documentos u otros direcciones, etc.

En nuestro caso, utilizaremos exactamente los siguientes:

• Un elemento mediante el cual destacaremos parte del contenido

• Enlaces
Hasta el momento ya hemos visto qué elementos pueden formar nuestro
documento artículo y cómo están organizados. Pero nos falta por ver un detalle
muy importante: que propiedades tienen.

Por ejemplo, tenemos el elemento imagen mediante el cual nos será posible incluir
imágenes en nuestro artículo. Algunas propiedades posibles son: el fichero en el
que se encuentra la imagen, qué dimensiones tendrá, cuál será su tamaño, etc.

Nuestro ejemplo será sencillo, y los únicos elementos que tendrán propiedades
serán los elementos enlace e imagen.

• El enlace tendrá una propiedad mediante la cual indicaremos la ubicación del

recurso destino y otra mediante la cual describiremos el recurso.
• La imagen tendrá una propiedad mediante la cual indicaremos la ubicación del
fichero que la contiene y otra mediante la cual describiremos el recurso.

Representación en una DTD de esta estructura lógica

Ya tenemos una representación abstracta de la estructura de un tipo de documento

artículo y ,por tanto,ya estamos en condiciones de escribir una DTD que represente
dicha estructura.

Lo primero es elegir el nombre del elemento raíz, que denominaremos articulo. Por
tanto, el documento XML tendrá el siguiente aspecto:

<articulo>
.......
</articulo>

y en nuestra DTD:

<!ELEMENT articulo (metainfo, cuerpo)>

donde indicaremos que está formado por los elementos metainfo y cuerpo
obligatorios y en ese orden.

El elemento metainfo estará formado por los elementos titulo, autor, pclave, y
resumen.

<!ELEMENT metainfo (titulo, autor, pclaves?, resumen?)>

Donde indicaremos que los elementos pclaves y resumen son optativos.

El contenido del elemento titulo sólo puede ser texto:

<!ELEMENT titulo (#PCDATA)>

El contenido del elemento autor serán los elementos nombre, email, url. De esta
manera permitimos incluir más información sobre el autor del artículo,

<!ELEMENT autor (nombre, email?, url?)>

aunque solo es obligatorio el elemento nombre. El contenido de estos tres

elementos es simplemente texto:

<!ELEMENT nombre (#PCDATA)>

<!ELEMENT email (#PCDATA)>
<!ELEMENT url (#PCDATA)>

El elemento pclaves, que no es obligatorio, tiene como contenido sólo texto:

<!ELEMENT pclaves (#PCDATA)>

Y el elemento resumen, que tampoco es obligatorio, está formado sólo por texto:

<!ELEMENT resumen (#PCDATA)>

A continuación pasamos a describir los elementos del elemento contenido, que

identificaremos mediante la etiqueta cuerpo.

El elemento cuerpo empezará por un elemento titulo seguido de subcapitulo1es,

aunque puede ser que el autor comience el artículo por alguno de los elementos
que hemos englobado como bloques de texto e imágenes.

<!ELEMENT cuerpo (titulo, (para | imagen | lds | lo | codigo)*

,subcapitulo1*)>

Mediante el elemento para representaremos los párrafos.

<!ELEMENT para (#PCDATA|destacar|enlace)*>

Su contenido, además de texto, es el elemento destacar y enlace.

Y el elemento imagen:

<!ELEMENT imagen EMPTY>

<!ATTLIST imagen
direccion CDATA #REQUIRED>
descripcion CDATA #REQUIRED>
Será un elemento vacio. Sus características están determinadas en el valor de sus
atributos:

• direccion, donde indicaremos la localización del fichero que contiene la imagen.

Es obligatorio.
• descripcion, donde escribiremos una descripción de la imagen. Es obligatorio.

Mediante el elemento lds indicamos las listas desordenadas las cuales pueden estar
formadas por los elementos de entrada de lista o por otras listas:

<!ELEMENT lds (il, (il | lds | lo)*)>

Y el elemento lo indicará listas ordenadas:

<!ELMENT lo (il, (il | lds |lo)*)>

Mediante el elemento il indicamos los ele mentos que forman la lista, y cuyo
contenido es el siguiente:

<!ELEMENT il (#PCDATA|destacar|enlace)*>

Mediante el elemento codigo indicamos que lo que vamos a escribir es código.

<!ELEMENT codigo (#PCDATA)>

Su contenido sólo es texto.

El artículo podrá estar dividido en subcapitulo1es. Vamos a limitar las

subcapitulo1es posibles a dos niveles. Las de primer nivel las identificaremos
mediante el elemento subcapitulo1 y las de segundo nivel mediante el elemento
subcapitulo11. Aunque esta estructuración no es obligatoria.

<!ELEMENT cuerpo (titulo, (para | imagen | lds | lo | codigo)*

,subcapitulo1*)>
<!ELEMENT subcapitulo1
(titulo, (para | imagen | lds | lo | codigo)*,
subcapitulo11*)>
<!ELEMENT subcapitulo11 (titulo, (para | imagen | lds | lo |
codigo)*)>

Las subcapitulo1es deben comenzar por el elemento titulo y van a estar

identificadas de forma unívoca por un atributo id.

<!ATTLIST subcapitulo1
id ID #REQUIRED>

<!ELEMENT subcapitulo11 (titulo, (para | imagen | lds | lo |

codigo)*)>
<!ATTLIST subcapitulo11
 id ID #REQUIRED

Hay que tener claro que cuanto más identificados tengamos los elementos y
más información tengamos sobre cada uno ,mejor;.más acciones podremos
realizar posteriormente sobre el documento. En nuestro caso,por sencillez, sólo
identificaremos mediante un atributo de tipo ID las subcapitulo1es. Pero en los
próximos capítulos, que veremos la DTD para escribirlas FAQS, o la DTD del
WML,comprobaremos quw como todos los elementos están identificados mediante
el atributo de ID.

Y, por último, sólo nos faltan definir los elementos en línea que como ya hemos
visto aparecen en los elementos para y il.

Mediante el elemento destacar, resaltaremos texto.

<!ELEMENT destacar (#PCDATA)>

Su contenido sólo puede ser texto.

Mediante el elemento enlace podremos hacer referencia a un recurso externo.

<!ELEMENT enlace (#PCDATA)>

Su contenido sólo puede ser texto y será precisamente el ancla del enlace.

Sus atributos coinciden con las del elemento imagen, teniendo la misma
funcionalidad.

<!ATTLIST imagen
direccion CDATA #REQUIRED>
descripcion CDATA #REQUIRED>

La DTD completa la podéis encontrar en el archivo articulo.dtd

Ejercicio: Ejemplo mínimo de XML para la DTD artículo.

Escribir el mínimo XML válido que se ajuste a la DTD que nos define la estructura
de la DTD para escribir artículos.

Solución:

Simplemente tenemos que fijarnos en los elementos que hemos indicando que son
obligatorios.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE articulo SYSTEM "articulo.dtd">
<articulo>
<metainfo>
<titulo>Documento XML mínimo para la DTD de artículos</titulo>
<autor>
<nombre>Joaquin Bravo Montero</nombre>
</autor>
</metainfo>
<cuerpo>
<titulo>Documento XML mínimo para la DTD de artículos</titulo>
</cuerpo>
</articulo>

Y para verificarlo, suponiendo que a dicho fichero lo hemos llamado

minimoarticulo.xml y que el archivo articulo.dtd se encuentra en el mismo
directorio:

pxml minimoarticulo.xml

minimoarticulo.xml

Ejercicio: Artículo en XML

Escribir en XML un artículo sobre un tema que te interese.

Solución:

En el artículo se describe cómo generar WML desde un Servlet.

DTD de bookmarks

En este apartado vamos a escribir una DTD que nos permitirá estructurar y
mantener en formato XML nuestras direcciones preferidas.

Para hacernos una idea de los elementos que nos permiten definir una dirección
podemos dar una vuelta por algunos de los buscadores más conocidos y observar
qué información suelen presentar sobre una dirección.

Si por ejemplo visitamos Altavista, observaremos que al presentarnos una dirección

nos ofrece la siguiente información:

Por tanto, una dirección la podríamos representar mediante los siguientes

elementos:

• Título de la dirección
• URL de la dirección
• Descripción
• Idioma del contenido de la dirección.
A los cuales nosotros añadiremos también un elemento valoración, que nos
permitirá indicar nuestro criterio sobre una dirección.

Un borrador de documento XML, mediante el cual representamos una dirección,

podría ser:

<direccion>
<titulo>....</titulo>
<url>...</url>
<descripcion>...</descripcion>
<idioma>...</idioma>
<valoracion>...</valoracion>
</direccion>

Y ordenándolo un poco:

<direccion idioma="" valoracion="">

<titulo>....</titulo>
<url>...</url>
<descripcion>...</descripcion>
</direccion>

Ejercicio: Escribir DTD para el elemento direccion.

Escribir una pequeña DTD que se ajuste al XML anterior. Teniendo en cuenta que:

• El contenido de los elementos titulo, url y descripcion:

o Sólo pueden ser texto.
o Tienen que aparecer en ese orden.
o Y el único elemento no obligatorio es la descripción.
• Los atributo idioma son obligatorios.
• El atributo valoracion sólo puede tener valores entre 1 y 5 y por defecto su valor
es 1.
• El atributo idioma sólo puede tener los valores esp y ing.

Solución:

La solución es:

<!ELEMENT direccion (titulo, url, descripcion?)>

<!ATTLIST direccion
valoracion (1|2|3|4|5) "1"
idioma (esp|ing) #REQUIRED>

<!ELEMENT titulo (#PCDATA)>

<!ELEMENT url (#PCDATA)>
<!ELEMENT descripcion (#PCDATA)>

Ahora lo que nos falta es crear unos elementos que nos permitan agrupar las
direcciones en grupos (al estilo de las carpetas de Windows), de manera que las
podamos tener ordenadas en conjuntos y subconjuntos.
Es decir, de una forma similar a ésta:

<bookmark>
<titulo>Mis direcciones favoritas</titulo>
<descripcion>Direcciones favoritas.</descripicion>
....direcciones....
<grupo id="deporte">
<titulo>Deportes</titulo>
....direcciones...
<grupo id="futbol">
<titulo>Futbol</titulo>
.....direcciones...
</grupo>
</grupo>
...direcciones
<bookmark>

Ejercicio: Escribir la DTD de bookmarks

Ampliar la mini DTD que hemos escrito para una dirección, de manera que nos
permita agrupar las direcciones en grupos y subgrupos al estilo del Explorador de
Windows.

• El elemento raíz se llamara bookmark y está formado por los siguiente

elementos:
o Un elemento metainfo al estilo de la DTD de artículos.
o Por un elemento titulo.
o Por un elemento descripcion optativo que sólo puede aparecer una vez.
o Y a continuación aparecerán direcciones o grupos de direcciones.
• Las carpetas se llamarán grupo y podran contener otros elementos grupo y por
supuesto direcciones.
o Cada grupo tendrá un atributo id que lo identifique de forma unívoca.
o Su primer elemento es el elemento titulo.
o Luego puede estar formado indistamente por direcciones o grupos de
direcciones.
o Como mínimo, en el caso de que no tenga otro grupo, deberá tener al
menos una dirección.

Solución:

Ésta sería la DTD:

<!ELEMENT bookmark (metainfo,titulo,descripcion?,(direccion |

grupo)+)>

<!-- ...Aqui va desarrollado el elemento metainfo ... -->

<!ELEMENT descripcion (#PCDATA)>

<!ELEMENT grupo (titulo,(direccion | grupo)+)>

<!ATTLIST grupo
id ID #REQUIRED>

<!ELEMENT direccion (titulo, url, descripcion?)>

<!ATTLIST direccion
valoracion (1|2|3|4|5) "1"
 idioma (esp|ing) #REQUIRED>

<!ELEMENT url (#PCDATA)>

DTD completa

Mínimo XML para la DTD de bookmarks

Escribir el documento XML mínimo que se ajuste a la DTD para "bookmarks".

Solución:

Sólo tenemos que fijarnos en los elementos de la DTD que sean obligatorios.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE bookmark SYSTEM "bookmark.dtd">
<bookmark>
<metainfo>
<titulo>Mis direcciones favoritas</titulo>
<autor>
<nombre>Joaquin Bravo Montero</nombre>
</autor>
</metainfo>
<titulo>Mis direcciones favoritas</titulo>
<direccion idioma="esp">
<titulo>Programacion en castellano</titulo>
<url>http://www.programacion.net</url>
</direccion>
</bookmark>

NOTA: Visualizar el documento XML, por ejemplo en el IE5 y observar qué pasa
con el atributo valoracion.

minimobookmark.xml

Bookmark en XML sobre el tema seleccionado.

Escribir en XML un documento bookmark sobre el tema seleccionado.

Solución:

En el bookmark se recogen interesantes direcciones sobre WML y WAP.

La DTD de novedades

Mediante esta DTD crearemos los documentos XML en los que registraremos las
novedades que se vayan produciendo en nuestro web.

En cada novedad indicaremos:

• El título de la novedad
• La url
• La fecha
• Y una breve descripción
Ejercicio: DTD para las novedades

Escribir una DTD que nos permita escribir en un documento XML las novedades que
se produzcan en nuestro web.

Solución:

Una DTD para escribir novedades podría ser perfectamente:

<!ELEMENT novedades (novedad+)>

<!ELEMENT novedad (titulo, url, descripcion?)>
<!ATTLIST novedad
fecha CDATA #REQUIRED>

<!ELEMENT titulo (#PCDATA)>

<!ELEMENT url (#PCDATA)>
<!ELEMENT descripcion (#PCDATA)>

novedades.dtd

Ejercicio: Documento XML de novedades

Escribir un documento XML que se ajuste a la DTD de novedades.

Solución:

Este es el documento XML de novedades de mi web sobre WML

DTD. Entidades

Hasta el momento hemos asociado un documento XML con un único fichero, pero
esto no tiene porque ser así. El XML nos permite organizar el contenido de un
documento XML de forma mucho más flexible. Por ejemplo,si tenemos un libro en
formato XML éste no tiene porque incluirse en un único fichero;si queremos, cada
capítulo puede estar en un fichero.

Lo que permite esta flexibilidad se denomina entidad. Una entidad es una

unidad de almacenamiento que puede contener cualquier cosa: desde una cadena
de caracteres hasta un fichero,un gráfico,y que,por tanto,nos permite dividir el
documento XML en varios objetos de almacenamiento.Después la aplicación XML
que tenga que trabajar con ese documento XML tratará ese conjunto de objetos
como un único objeto XML.

Las ventajas que las entidades nos proporcionan son evidentes:

• Facilita la creación y el mantenimiento de documentos XML, al permitirnos

trabajar sobre partes de éstos.
• Permite que varias personas trabajen sobre diferentes partes de un documento
XML.
• Reusabilidad. Estas entidades pueden ser utilizadas en otros documentos XML.
• etc.

Declaración de una entidad

Todas las declaraciones de entidades,independientemente del tipo que sean,
utilizan la misma sintaxis:

<!ENTITY nombre "contenido">

donde nombre es el identificador de la entidad y el contenido es su contenido o una

referencia a éste.

Tipos de entidades

Debido a que las entidades XML pueden hacer tantas cosas, existen muchas
variedades de entidades. Esto no significa que existan siete u ocho tipos diferentes
con nombre sencillos.

Existen tres propiedades que definen el tipo:

• Dependiendo de si la entidad debe ser analizada o no por el parser, una entidad

se puede clasificar como analizada o no analizada.
• Dependiendo de si el contenido de la entidad es interno o externo es decir de si
su contenido aparece en la declaración o no, la entidad se puede clasificar como
interna o externa.
• Dependiendo de si se utiliza en la DTD o en el documento se clasifica como
paramétrica o general.

Pero las entidades pueden pertenecer a varios de estos tipos y, por ejemplo, tener
una entidad general interna analizada. Las posiblidades de combinación son, por
tanto ocho, pero tres de ellas imposibles, por lo que el número de entidades posible
es cinco .

• Entidad general interna analizada.

• Entidad general externa analizada.
• Entidad general externa no analizada.
• Entidad parámetro interna.
• Entidad parámetro externo.

En principio puede parecer un poco complicado, pero veamos cada caso por
separado con algunos ejemplos concretos y vereis que en el fondo todo es muy
sencillo.

Entidad general interna analizada.

Son las más sencillas de todas y son básicamente abreviaturas totalmente definidas
en la sección de declaración de tipo de documento.

En este ejemplo,

<?xml version="1.0"?>
<!DOCTYPE ejemplo [
<!ENTITY nomclub "Club de Usuarios de Internet">
]>
<ejemplo>
En el &nomclub; realizamos cursos sobre Internet.
</ejemplo>
declaramos la entidad nomclub en la línea:

<!ENTITY nomclub "Club de Usuarios de Internet">

y luego la utilizamos colocando el nombre de la entidad entre los símbolos & y ;

La consecuencia de su utilización es que cuando el parser lea el documento

cambiará la llamada a la entidad

&nomclub;
por su contenido.

Esta entidad es:

• General al ser definida en un documento XML.

• Interna al aparecer su contenido en la declaración.

Este tipo de entidades es muy utilizado también cuando es necesario emplear algún
carácter que el juego de caracteres que hemos definido en el atributo encoding de
la declaración XML no soporta. Por ejemplo, si quisiéramos colocar el símbolo del
copyright © podriamos hacerlo de la siguiente mamera:

<?xml version="1.0"?>
<!DOCTYPE ejemplo [
<!ENTITY copy "&#169;">
]>
<ejemplo>
&copy; Ciberaula.
</ejemplo>

Entidad general externa analizada

En este caso la declaración no lleva implícito el contenido de la entidad. Lleva un

identificador externo que indicará a la aplicación XML dónde se encuentra el
contenido de la entidad.

Este identificador externo es la palabra SYSTEM seguida de la dirección (URI) donde

se encuentra el recurso.

<?xml version="1.0"?>
<!DOCTYPE libro [
<!ENTITY capitulo1 SYSTEM "capitulo1.xml">
]>
<libro>
&capitulo1;
</libro>
En este ejemplo, si el contenido del documento capitulo1.xml es:

<?xml version="1.0"?>
<capitulo>
<para>Este es el primer capitulo</para>
</capitulo>

el resultado es:

Las posibilidades de esta forma de trabajar son enormes, ya que:

• Esta misma entidad podría ser utilizada desde múltiples documentos XML.
• Permite que diferentes autores desarrollen diferentes partes de un documento
XML de forma independiente,no teniéndose que preocupar del conjunto del
documento XML.

Ejercicio: Reescritura de XML

Volver a escribir el XML de bookmarks,de manera que cada dirección sea una
entidad externa.

Ejercicio:

Tenemos que definir cada direccion en un fichero XML y luego en la declaración XML
indicar dónde se encuentran estos ficheros.

En el ejemplo sobre direcciones de WML y WAP, el fichero XML quedaría de la

siguiente manera:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE bookmark SYSTEM "bookmark.dtd" [

<!-- Metainformacion -->

<!ENTITY meta SYSTEM "wapdev_meta.xml">

<!-- Direcciones -->

<!ENTITY wapfacil SYSTEM "wapdev/wapfacil.xml">

<!ENTITY wmlclub SYSTEM "wapdev/wmlclub.xml">
 <!ENTITY asphtml SYSTEM "wapdev/asphtml.xml">
<!ENTITY cestacompra SYSTEM "wapdev/cestacompra.xml">
]>

<bookmark>

&meta;
<titulo>Información general sobre WAP</titulo>
<descripcion>Recopilación de direcciones
sobre WAP y WML.</descripcion>
<grupo id="doc-portales">
<titulo>Tutoriales</titulo>
&wapfacil;
&wmlclub;
</grupo>

<grupo id="articulos">
<titulo>Artículos</titulo>
&asphtml;
&cestacompra;
</grupo>

Los nuevos ficheros XML con las direcciones han sido creados en el subdirectorio
wapdev.

Fijaros que también se ha definido fuera el elemento metainfo

Hay que destacar que para el parser de XML sigue siendo una única entidad.
Fijaros como el IE5 lo muestra completo.

Entidad parámetro

Como ya hemos dicho,las entidades XML se clasifican según puedan usarse en una
DTD o en el documento. Las entidades que sólo pueden utilizarse en la DTD se
denominan entidades parametro.

Están diseñadas para contener listas de atributos y modelos de contenido. Nos

ayudarán a organizar y agilizar la creación de las DTD, y hacerla más eficiente y
consistente.

Si nos fijamos en la DTD de artículos existen,elementos con un modelo de

contenido idéntico en su totalidad o parte de éste.

Por ejemplo los elementos cuerpo, seccion y seccion1

<!ELEMENT cuerpo (titulo, (para | imagen | lds | lo | codigo)*

,seccion*)>

<!ELEMENT seccion (titulo, (para | imagen | lds | lo | codigo)*,

seccion1*)>
<!ATTLIST seccion
id ID #REQUIRED>

<!ELEMENT seccion1 (titulo, (para | imagen | lds | lo | codigo)*)>

tienen en común.
(para | imagen | lds | lo | codigo)*

Lo que nos permiten las entidades paramétrícas es definir este modelo de contenido
como una entidad y luego hacer referencia a ella tantas veces como sea necesario.
De esta manera si necesitamos modificar estos elementos, tendremos que hacerlo
sólo una vez, en un único lugar, y no tener que ir elemento por elemento realizando
la modificación.

Las entidades paramétricas tienen un identificador especial en su declaración que

las diferencia de las generales. Este indicador es el símbolo de tanto por ciento
(%), y se usa precediendo al nombre.

<!ENTITY % nombre "contenido">

También cambia la forma de referenciarla. En lugar de colocar el nombre entre el &

y ; se coloca entre % y el ;.

Por tanto, en nuestro ejemplo podemos crear la siguiente entidad paramétrica:

<!ENTITY % bloques "para | imagen | lds | lo | codigo">

y describir el modelo de contenidos de los elementos cuerpo, seccion y seccion1 de

la siguiente manera:

<!ELEMENT cuerpo (titulo, (%bloques;)+ ,seccion*)>

<!ELEMENT seccion (titulo, (%bloques;)+, seccion1*)>

<!ATTLIST seccion
id ID #REQUIRED>

<!ELEMENT seccion1 (titulo, (%bloques;)+)>

Esto también lo podemos hacer con listas de atributos. Por ejemplo, los elementos
imagen y enlace tienen los mismos atributos.

<!ATTLIST imagen
direccion CDATA #REQUIRED
descripcion CDATA #REQUIRED>

Por tanto, podríamos definir esta lista de atributos dentro de una entidad
paramétrica.

Ejercicio: Reescribir la DTD de artículos utilizando entidades.

Reescribir la DTD de artículos redefiniendo modelos de contenidos y listas de

atributos iguales como entidades paramétricas.

Solución:

Creamos una entidad bloques para declarar el modelo de contenido que se repite
en los elementos cuerpo, seccion y seccion1.

<!ENTITY % bloques "para | imagen | lds | lo | codigo">

Creamos una entidad enlinea para declarar el modelo de contenido que se repite en
los elementos para y il.

<!ENTITY % enlinea "enlace|destacar">

Y creamos una entidad att.elementos.enlace para declarar la lista de atributos que

se repite en los elementos enlace e imagen.

<!ENTITY % att.elementos.enlace "

direccion CDATA #REQUIRED
descripcion CDATA #REQUIRED">

Por tanto, la declaración de estos elementos quedará de la siguiente manera:

<!ELEMENT cuerpo (titulo, (%bloques;)+ ,seccion*)>

<!ELEMENT seccion (titulo, (%bloques;)+, seccion1*)>
<!ELEMENT seccion1 (titulo, (%bloques;)+)>

<!ELEMENT para (#PCDATA|%enlinea;)*>

<!ELEMENT il (#PCDATA|%enlinea;)*>

<!ATTLIST imagen
%att.elementos.enlace;>
<!ATTLIST enlace
%att.elementos.enlace;>

DTD completa

Hasta el momento sólo hemos visto entidades paramétricas internas, pero también
pueden ser externas.

Esto nos permitirá crear las DTD entidades que podamos utilizar en varias DTD sin
necesidad de reescribirlas.

Por ejemplo, la DTD de artículos y de bookmark tienen en común el elemento

metainfo. Entonces podemos definir su modelo de contenido como una entidad
paramétrica externa, de manera que sólo tengamos que referenciarla desde ambas
DTD en lugar de tener que declarar todo el elemento en ambas.

Ejercicio: Definir una entidad paramétrica externa

Redefinir el elemento metainfo en la DTD de artículos y bookmark como entidad

paramétrica externa.

Solución:

Creamos un archivo metainfo.dtd en el que declaramos los elementos que

describen la metainformación.

<!ELEMENT metainfo (titulo, autor, pclaves?, resumen?)>

<!ELEMENT titulo (#PCDATA)>

<!ELEMENT autor (nombre, email?, url?)>

<!ELEMENT nombre (#PCDATA)>
<!ELEMENT email (#PCDATA)>

<!ELEMENT pclaves (#PCDATA)>

<!ELEMENT resumen (#PCDATA)>

Y luego en la DTD de artículos y bookmark borramos las declaraciones de estos

elementos y declaramos una entidad paramétrica externa de la siguiente manera:

<!ENTITY % metainfo SYSTEM "metainfo.dtd">

%metainfo;

DTD existentes

En los próximos capítulos vamos a ver ejemplos de DTD reales. Hay infinidad de
vocabularios XML, y muchos de ellos son el resultado del trabajo de los mejores
técnicos de algunas de las mayores compañías del mercado, como Microsoft,
Oracle, IBM, etc. Estas organizaciones disponen de una gran cantidad de recursos y
la motivación suficiente para crear vocabularios de calidad y bien diseñados. Por lo
tanto tiene sentido prestar atención a los mecanismos que utilizan para poner en
marcha sus propias DTD.

Sobre todo prestaremos atención a la QAML.dtd, una DTD escrita por Rick Jelliffe
del Centro de Computación de la Academia Sinica de Taipei en Taiwan y que
utilizaremos para escribir una FAQ de ejemplo.

Otras DTDs

Sólo estudiaremos unas cuantas DTDs, pero serán más que suficientes para ver
cómo el uso de los vocabularios XML se está generalizando en todos los campos de
la informática. Pero esto sólo es la punta del iceberg: hay mucho más y habrá
mucho más;aunque tampoco es una cuestión de cantidad. Una de las bases del
éxito del XML será que algunas de estas DTD se estandarice y su uso se generalice.

Para estar al día sobre los vocabularios XML que existen y los que aparecerán os
recomiendo que visitéis las siguientes direcciones:

• SHEMA.NET mantenida por James Tauber

• XML.ORG
• DTD.COM

Docbook

La Docbook es originalmente un vocabulario SGML (actualmente existe una

versión de la DTD para XML) mantenido por el DocBook Technical Committee de
OASIS, que se utiliza para escribir documentación técnica: libros, artículos,
etc. Aunque en un principio fue pensada para el mundo informático, ha tenido
tanto éxito que su uso se ha extendido a otras áreas de la ciencia.

Es realmente útil, y gran parte de la información técnica de la que se dispone hoy

en día, sobretodo en entornos Linux, se escribe utilizando esta DTD. Su principal
inconveniente es su tamaño, ya que consta de 362 elementos, frente a los 77 que
por ejemplo tiene el HTML 4.0. Sin embargo, se puede empezar a trabajar sólo
conociendo algunos pocos elementos.
Este es sin duda uno de los grandes ejemplos de vocabulario SGML/XML cuyo uso
se ha popularizado y extendido. Esto contribuye a que por ejemplo:

• Tengamos las DSSSL que nos convierten estos documentos a multiples formatos
de impresión: RTF, PDF, TEX, etc. y también a HTML.
• Dispongamos de las XSLT que nos convierten estos documentos a HTML
• Se estén desarrollando las XSL que nos converten esta información a PDF.
• Y sobretodo,que dispongamos de gran cantidad de información técnica a la que
podemos acceder en formato SGML/XML y luego visualizarla en el formato que
más nos interese utilizando las hojas de estilo antes mencionadas.

Direcciones:

• Página oficial de Docbook

• Web de Norman Walsh, el autor de las DSSSL y XSL que nos permiten
visualizar los documentos escritos con la DocBook en otros formatos: RTF,
HTML, etc.
• DocBook.org, donde os podéis bajar el libro DocBook: The Definitive Guide
en diferentes formatos y entre ellos en SGML y luego en vuestra propia página
convertirlo a HTML o RTF utilizando las DSSSL antes mencionadas.

MathML

El MathML (Mathematical Markup Language) es un lenguaje XML utilizado para

marcar una ecuación matemática en términos de su presentación y también de su
semántica.

El MathML es un intento de facilicitar el uso y la reutilización de las matemáticas y

de los contenidos cientificos en el Web y,en general en cualquier otro tipo de
aplicación donde sea necesario la representación de notación matemática.

En el momento de escribir estas líneas se encuentra en la versión 2.0 del 21 de

Febrero de 2001, que incorpora diversas mejoras sobre la 1.0 y la 1.0.1, aunque no
supone un cambio brutal sobre ellas.

Por el momento no es directamente visible en los browsers más utilizados aunque

las empresas estan desarrollando applets y plug-ins que pueden mostrar
documentos Mathtml. Los más conocidos son:

• El ICEBrowser, un buscador web escrito en Java

• El IBM techexplorer, un visualizador y plug- in de MathML y TeX/LaTex
desarrollado por IBM.
• Y el Amaya, un buscador W3c que nos permite visualizar MathML incluso en
nuestro código HTML y además incorpora un sencillo editor de MathML.

Pero lo mejor es que veamos un pequeño ejemplo en el que escribimos una

ecuación de segundo grado y la fórmula que la soluciona.

Este ejemplo visualizado en el buscador Amaya tiene el siguiente aspecto:

y la sintaxis XML que representa la ecuación de segundo grado es el siguiente:

Ejemplo código Mathml

<math>
<mrow>
<mi>a</mi>
<msup>
<mi>x</mi>
<mn>2</mn>
</msup>
<mo>+</mo>
<mi>bx</mi>
<mo>+</mo>
<mi>c</mi>
<mo>=</mo>
<mn>0</mn>
<mi></mi>
<mo>,</mo>
<mi>con a</mi>
<mo>></mo>
<mn>0</mn>
</mrow>
</math>

Ejercicio: Fichero en MathML

Generar el código MathML para la fórmula que soluciona la ecuación de segundo

grado.

Solución:

El código es el siguiente:

<math>
<mrow>
<mi>x</mi>
<mo>=</mo>
<mfrac>
<mrow>
 <mo>-</mo>
<mi>b</mi>
<mo>&PlusMinus;</mo>
<msqrt>
<mrow>
<msup>
<mi>x</mi>
<mn>2</mn>
</msup>
<mo>-</mo>
<mn>4</mn>
<mi>ac</mi>
</mrow>
</msqrt>
</mrow>
<mrow>
<mn>2</mn>
<mi>a</mi>
</mrow>
</mfrac>
</mrow>
</math>

Y aquí el código completo con el código MatHML integrado en el código HTML de

manera que sea visible en el Amaya Browser. Aunque es un tema que trataremos
más adelante, fijaros en la utilización de Namespaces que permiten la integración
de dos vocabularios XML: el XHTML y el Mathtml.

SVG y VML

El SVG y el VML son dos lenguajes XML utilizados para definición de gráficos
vectoriales. El SVG es una propuesta del W3c, mientras que el VML es la propuesta
sobre el mismo tema de Microsoft.

SVG

SVG (Scalable Vector Graphics) es un lenguaje XML que esta siendo desarrollado
por el W3c para describir gráficos en dos dimensiones.

Recientemente, el 4 de septiembre de 2001, se ha aprobado la recomendación de

la versión 1. 0. Sin embargo, ya existían aplicaciones desde los primeros borradores
y, por supuesto, tras la aprobación se incluirán unas cuantas más.

• Visualizadores
o CSRIO Viewer, que es un estupendo visualizador de documentos SVG.
Es gratis y está escrito en Java. Además viene acompañado de una
utilidad que nos permite convertir dichos documentos en imágenes en
formato JPEG.
o IBM SVG viewer,también un buen visualizador en Java desarrollado por
IBM.
o Adobe a desarrollado un plug- in que permite visualizar este tipo de
documentos en el IE y en el Nestcape.
• Conversores
o Cada día son más las aplicaciones de dibujo que nos permiten trabajar
con este tipo de documentos.
 § CorelDraw ha anunciado recientemente un filtro para su versión
9.1, que permite exportar los gráficos desarrollados con esta
aplicación a SVG. En la versión 10 viene incluido de serie.
§ Adobe también ha realizado lo mismo para la versión 8.1 del
Adobe Ilustrator, de manera que desde esta aplicación podemos
importar y exportar documentos SVG.
§ FOP de James Tauber que es una implementación gratuita en
Java de los XSL-FO que nos permite convertir nuestros
documentos XML en PDF. Lo interesante es que también
reconoce la sintaxis SVG y es capaz de pintarla en PDF.

Por tanto, a pesar de ser todavía un borrador de trabajo, las posibilidades de ir

realizando aplicaciones con esta especificación son inmesas y además considero
que es una de las aplicaciones XML con más futuro, dada la facilidad que nos
proporciona para crear, mantener y manipular gráficos y sobretodo para
incluirlos en otros vocabularios XML.

Hasta ahora siempre ha sido bastante complicado crear gráficos de forma dinámica
y todavía más difícil incluirlos en nuestros documentos. La solución siempre ha
pasado por soluciones propietarias muy vinculadas a determinadas plataformas y
entornos.

Imaginemos, por ejemplo, que tenemos que desarrollar una aplicación que debe
generar informes de forma dinámica y que hay que distribuir por Internet en HTML
y en PDF. Y supongamos que la información más importante de esos informes son
gráficos que tienen que generarse con información que hay en una base de datos y
que dicha información va cambiando constantemente (p. ej. cotizaciones de bolsa).
Una posible solución sería tener el contenido del informe en XML y enlazados los
gráficos que podríamos incluir fácilmente al haberlos generado en formato SVG
desde la base de datos. Para presentarlo en PDF podemos utilizar el FOP de James
Tauber y para presentarlo en HTML lo generamos utilizando XSLT y podemos
utilizar el plug-in de Adobe para mostrar los gráficos SVG o convertirlos en
imagenes JPG mediante el conversor que viene con el CSRIO. Como podemos
observar, las combinaciones son inmensas, y lo mejor de todo es que muchas de
las aplicaciones que tenemos que utilizar ya estan creadas. Y todo esto por trabajar
con un estándar como el XML.

Un ejemplo de código SVG es el siguiente:

Documento SVG
<?xml version="1.0" standalone="no"?>

<!DOCTYPE svg SYSTEM "svg-19990812.dtd">

<svg width="3in" height="3in">

<g style="stroke: #000000">
<line x1="0" x2="150" y1="150" y2="150"/>
<line x1="0" x2="0" y1="0" y2="150"/>
<text x="0" y="10">Resultados</text>
<text x="150" y="165">Zona</text>
<rect x="10" y="50" width="20" height="100"/>
<text x="10" y="165">Norte</text>
<text x="10" y="45">10</text>
<rect x="50" y="110" width="20" height="40"/>
<text x="50" y="165">Sur</text>
<text x="50" y="105">4</text>
 <rect x="90" y="90" width="20" height="60"/>
<text x="90" y="165">Este</text>
<text x="90" y="85">6</text>
</g>
</svg>

En el que pintamos unos gráfics que vista el CSRIO Viewer tiene el siguente
aspecto:

Es un ejemplo sencillo, pero demuestra las enormes posibilidades de este lenguaje

XML, ya que este código lo podemos generar fácilmente a partir de la información
que tenemos en una base de datos y haberlo incorporado sin problemas a nuestros
documentos XML. O con las herramientas que existen hoy en día ya podemos
convertido en una imagen JPG.

VML

VML es un lenguaje XML para definir gráficos vectoriales desarrollado por Microsoft.

Tiene la ventaja de que ya es una realidad y que el IE5 es capaz de pintarlo y las
aplicaciones que vienen con el Office 2000 ya son capaces de trabajar con él. con
las y hasta ahora pruebas que he realizado, he visto que, por ejemplo, los gráficos
que realizamos en el Word 2000 utilizando las herramientas de dibujo, al
exportarlos a HTML ya aparecen en este formato.

La desventaja es que sólo Microsoft apoya este lenguaje y que por tanto sólo sus
aplicaciones lo soportan.

Personalmente prefiero el SVG, pero evidentemente el VML es una alternativa a

tener en cuenta en ciertas condiciones: que la aplicación de la que hablabamos
anteriormente tuviera que funcionar en una intranet en la que todas las personas
que se conectan lo hacen a través del IE5.

Esta es la imagen de un gráfico en VML visualizado en el IE5:

Si observamos el código de la página HTML, veremos lo sencillo que es incluir

código VML en nuestras páginas:

• Tenemos que declarar el "namespace" vml de manera que indicamos al

procesador que dentro de nuestro HTML estamos incluyendo otro vocabulario
XML.
• <html xmlns:vml = "urn:schemas-microsoft-com:vml">
• Y luego tenemos que declarar el control Active X que lo pinta.
• <OBJECT classid=CLSID:10072CEC-8CC1-11D1-986E-00A0C955B42E
• id=VMLRender></OBJECT>
• <STYLE>vml\:* {
• BEHAVIOR: url(#VMLRender)}
• </STYLE>

Para más información sobre el tema, podéis visitar estas direcciones:

• VMLSource
• VML en Microsoft

QAML

QAML es una lenguaje XML creado especialmente para ayudar en la escritura,

utilización y mantenimiento de las FAQ,Frequently Asked Questions", es decir,
documentos en los que se da respuesta a las preguntas más frecuentes sobre un
tema. Su uso estámuy extendidos por Internet.

La versión 1.0 de la QAML fue escrita for Justin Higgens de faq.org. Pero esta
versión está escrita en SGML. La versión 2.0 ya es en XML y ha sido escrita por Rick
Jelliffe del Centro de Computación de la Academia Sinica de Taipei en Taiwan.

En el momento de escribir estas líneas se encuentra en versión 2.4 cuya DTD

podéís encontrar en el Web sobre XML de Rick Jelliffe, que por cierto es muy
interesante.
No es una sintaxis XML desarrollada por ninguna organización, pero su uso es
generalizado y utilizado en muchos Webs en las que tienen que escribir FAQ. Esto
nos facilita el trabajo, ya que disponemos de:

1. Las XSLT que nos permiten la conversión a HTML.

2. La CSS que nos permite visualizarla en el IE5.
3. También tenemos escrita la XSLT que nos permite convertirla a XSL-FO para
luego convertirla a PDF utilizando por ejemplo el FOP de James Tauber.
4. Disponemos de el html2qaml.xom,que es un Omnimark script para generar
desde HTML un QAML.
5. etc..

Es una de las DTD que vamos a utilizar en la elaboración de nuestro Web, por lo
que a continuación pasamos a estudiarla en detalle.

Como podemos observar:

<!ELEMENT faq (head, body)>

faq es el elemento raíz, que contiene una cabecera y un head.

El head se reserva para colocar información (metadata) sobre el documento:

<!ELEMENT head
(title, version?, maintain+, hdr*, althdr*, archive*,label*,
link*)>

Los únicos elementos indispensables son:

• title, que es el título de la FAQ.

• maintain, que es el elemento en el que indicamos información sobre el autor o
autores de la FAQ (pueden ser varios), teniendo que indicar obligatoriamente el
nombre y el corréo electrónico del autor.

<!ELEMENT maintain (logo*, name+, email+, subject?, address?)>

En el elemento body escribimos el contenido del cuerpo (conjunto de preguntas y

respuestas):

<!ELEMENT body (section+ | qna+)>

La funcionalidad del elemento section es la de permitir agrupar los elementos qna

en conjuntos:

<!ELEMENT section (logo*, title, (qna+ | q+ | ( p | div | section)+))

>

Es obligatorio que empiece por un título.

El elemento qna es sin duda el más importante de esta DTD, ya que contiene la
pregunta y sus respectivas respuestas.

<!ELEMENT qna (logo*, q, (logo?,topic?,author?,contributor*,a)+)>

Es obligatoria la pregunta, representada por el elemento q y la respuesta indicada
en el elemento a.

Como podemos observar, las respuestas pueden ser varias: (....a)+ y pueden estar
acompañadas de información adicional: autor, contributor, etc.

El elemento qna puede tener los siguientes atributos:

<!ATTLIST qna
id ID #IMPLIED
class CDATA #IMPLIED
xml:lang NMTOKEN #IMPLIED
date CDATA #IMPLIED>

ninguno de ellos obligatorio (todos son #IMPLIED) aunque algunos muy

recomendables como es el id, que nos permite identificar de forma unívoca una
qna.

Una pregunta (elemento q) está formada esencialmente por texto (#PCDATA):

<!ELEMENT q (#PCDATA | link | span)*>

Una respuesta (elemento a) tiene que estar formada

<!ELEMENT a (p | div)+>

al menos por un elemento p o elemento div.

Por tanto, un ejemplo de XML mínimo que se ajuste a esta DTD es:

XML QAML
<?xml version="1.0"?>
<!DOCTYPE faq SYSTEM "qaml.dtd">
<faq>
<head>
<title>Mi primer FAQ con la QAML.dtd</title>
<maintain>
<name>Joaquin Bravo</name>
<email>[email protected]</email>
</maintain>
</head>
<body>
<qna id='q1'>
<q>Aqui la pregunta</q>
<a><p>Aqui la respuesta.</p></a>
</qna>
</body>
</faq>

Mediante el elemento p indicamos bloques de contenido. Tenemos que tener

cuidado y no confundirlo con un simple párrafo, ya que el atributo class nos permite
especificar un poco más las características de su contenido.

<!ATTLIST p id ID #IMPLIED
class CDATA #IMPLIED
title CDATA #IMPLIED
xml:lang NMTOKEN #IMPLIED
 alt CDATA #IMPLIED
date CDATA #IMPLIED
xml:space ( default | preserve ) #IMPLIED >

Como podemos ver no es obligatorio, y tampoco tiene ningún valor por defecto, es
decir podemos poner el valor que queramos, y luego manipularlo de una manera u
otra desde la aplicación u hoja de estilos.

La autora de la DTD, cuando por ejemplo está introduciendo un contenido que

quiere que forme parte de una lista, da el valor li al atributo class.

<p class="li">AAAA</p>
<p class="li">BBBB</p>

Es una forma de trabajar que presenta ventajas e inconvenientes:

• Permite que los documentos XML sean bastantes flexibles aunque tengan una
DTD a la que ajustarse.
• Pero también dificulta la reutilización de documentos XML, XSLT,
etc.realizados por otras personas, ya que a priori no sabemos los valores que
utilizan para el atributo class. Y más si tenemos en cuenta que este atributo se
utiliza en varios elementos.

Además de este atributo, como podemos observar el elemento p, posee más

atributos que lo caracterizan:

• id, mediante el cual lo podemos identificar de forma unívoca. Este atributo se

utiliza en prácticamente todos los elementos.
• title, que permite asociar un título a ese contenido.
• xml:lang, mediante el cual podemos identificar el idioma en el que está escrito.
• alt, que permite asociar texto adicional sobre el contenido del párrafo.
• date, que permite escribir la fecha cuando fue colocado.
• xml:space, que indica cómo deberemos tratar los espacios en blanco que se
encuentran dentro del contenido.

Los elementos p se pueden agrupar mediante el elemento div.

<!ELEMENT div (p)+>

el cual debe estar formado por al menos un párrafo. Lo podemos utilizar por
ejemplo para crear listas ordenadas o desordenadas, tal como muestra el siguiente
ejemplo:

<div class="ul">
<p class="li">AAAA</p>
<p class="li">BBBB</p>
</div>

dándo al atributo class el valor ul. Si quisiéramos que fuese ordenada, le

pondríamos el valor ol.

El contenido del elemento p es generalmente texto:

<!ELEMENT p (#PCDATA | link | span)*>

aunque, al igual que el elemento pregunta q, también puede llevar los elementos
link y span.

Mediante el elemento link colocamos enlaces. Su contenido sólo puede ser texto:

<!ELEMENT link (#PCDATA)>

y la dirección del enlace se coloca en el atributo href.

<!ATTLIST link id ID #IMPLIED

class CDATA #IMPLIED
xml:link CDATA #FIXED "simple"
href CDATA #REQUIRED
alt CDATA #IMPLIED
role CDATA #IMPLIED
title CDATA #IMPLIED
show (embed|replace|new) "new"
actuate (auto|user) "user"
behavior CDATA #IMPLIED>

que como podemos observar es el único obligatorio (#REQUIERED).

Por tanto, un enlace tendría escrito en XML el siguiente aspecto:

<link href="http://www.altavista.com">altavista.</link>

Como podemos observar, tiene muchos más atributos, entre ellos el superutilizado
class, pero dejaremos el estudio de estos atributos para más adelante ya que están
muy relacionados con la especificación XLink en la que se define cómo tienen que
ser los enlaces entre documentos XML.

Y, por último, mediante el elemento span caracterizamos partes del contenido

dentro del elemento p. Su atributo más importante es el classcon el que podemos
indicar que si el texto está cursiva poniéndole el valor i.

<span class="i">texto en cursiva</span>

Sin embargo debemos tener claro que este texto aparecerá en cursiva porque luego
la aplicación o XSLT que lo trate lo representará como tal. La verdad es que luego,
cuando nosotros lo pintemos, podremos ponerlo como más nos guste. Los valores
que normalmente utiliza la autora de la DTD en sus ejemplos están enfocados a la
presentación y muy relacionados con el HTML y las CSS, pero nosotros, si
queremos, podemos ponerle valores que identifiquen más categóricamente
(semánticamente) el contenido de lo que califica. Por ejemplo, en lugar de i
podríamos poner el valor codigo.

Todavía falta por describir algunos elementos y atributos, pero dejo como ejercicio
estudiar con más detalle la DTD.Aunque con lo que se ha presentado hasta ahora,
deben quedar claros la utilidad y el funcionamiento de esta DTD.

Ejercicio: FAQ en XML

Escribir una FAQ en XML sobre el tema seleccionado.

Solución:
Para el Web de WML en castellano encontraréis un FAQ sobre WAP.

El documento en formato XML podéis obtenerlo aquí.

Introducción a los Namespaces

Presentación

Una de las pruebas del éxito del XML es la gran cantidad de vocabularios XML
(DTD) que están apareciendo. En algunas ocasiones al realizar nuestros
documentos XML nos podremos encontrar en la necesidad de utilizar varios de
estos vocabularios. Es posible que estemos escribendo un artículo científico en
formato XML y que tengamos la necesidad de incorporar fórmulas matemáticas.
Podemos perfectamente desarrollar nuestras propias etiquetas, pero ¿por qué no
utilizar las que nos proporciona el vocabulario MathML? Sin duda, es mejor la
reutilización de estas marcaciones que el hecho de reinventar unas nuevas.

Por tanto, estos documentos XML que contendrán elementos de múltiples fuentes
independientes entre sí, pueden tener problemas de reconocimiento y colisión.
Puede ser que estemos utilizando dos vocabularios que utilizan el mismo tipo de
elemento o nombre de atributo. Por ejemplo:

<?xml version=1.0" encoding="iso-8859-1"?>

<direccion>
<calle>Avd. Diagonal 8</calle>
<ciudad>Barcelona</ciudad>
<provincia>Barcelona</ciudad>
<pais>España</pais>
</direccion>
<?xml version=1.0" encoding="iso-8859-1"?>
<servidor>
<url>http://www.palotes.com</url>
<direccion>123.45.67.8</direccion>
</servidor>

Los dos documentos XML anteriores tienen en común el elemento direccion. Por el
momento son dos vocabularios diferentes pero puede ser que en algún momento
tengamos que integrarlos en un mismo documento XML. Supongamos que ambos
documentos juntos nos ofrecen información sobre la localización de una empresa:
su dirección física y su dirección en Internet. Está claro que el elemento dirección
va a provocar problemas. Podríamos renombrarlo y en el segundo documento XML
llamarlo ip-servidor, pero no es una buena solución. Una posible solución es ponerlo
de la siguiente manera:

<?xml version=1.0" encoding="iso-8859-1"?>

<empresa>
<nombre>Palotes S.A.</nombre>
<dirfis:direccion
xmlns:dirfis="http://www.palotes.com/direccionfisica">
<dirfis:calle>Avd. Diagonal 8</dirfis:calle>
<dirfis:ciudad>Barcelona</dirfis:ciudad>
<dirfis:provincia>Barcelona</dirfis:ciudad>
<dirfis:pais>España</dirfis:pais>
</dirfis:direccion>
<dirserv:servidor
xmlns:dirserv="http://www.palotes.com/direccionservidor">
<dirserv:url>http://www.palotes.com</dirserv:url>
 <dirserv:direccion>123.45.67.8</dirserv:direccion>
</dirserv:servidor>
</empresa>

En la que como podemos observar los elementos de ambos vocabularios están bien
diferenciados.

También puede ocurrir que sean diferentes, pero que el software que trabaja con
ellos necesite diferenciarlos claramente, ya que su procesamiento requiere
comportamientos diferentes.

Por ejemplo, esto es un documento XHTML que incorpora el vocabulario MathML:

<?xml version="1.0" encoding="ISO-8859-1"?>

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Ejemplo de documento MathML</title>
<meta http-equiv="Content-Type" content="text/html" />
</head>

<body>
<p>Ecuación de segundo grado escrita con MathML</p>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<mi>a</mi>
<msup>
<mi>x</mi>
<mn>2</mn>
</msup>
<mo>+</mo>
<mi>bx</mi>
<mo>+</mo>
<mi>c</mi>
<mo>=</mo>
<mn>0</mn>
<mi></mi>
<mo>,</mo>
<mi>con a</mi>
<mo>></mo>
<mn>0</mn>
</mrow>
</math>
</body>
</html>

Hemos diferenciado los elementos del vocabulario XHTML y MathML para que
luego,por ejemplo el buscador Amaya sea capaz de pintarlos adecuadamente.

O,por ejemplo, una XSLT (la estudiaremos en los próximos capítulos) es un

vocabulario XML mediante el cual convertimos un documento XML en otro XML. El
código del documento XML de salida va implícito en la XSLT, que a su vez es un
vocabulario XML. Por tanto,es evidente diferenciar un vocabulario de tal manera
que el procesador de XSLT sea capaz de identificar qué elementos pertenecen al
lenguaje XSLT para procesarlos. La forma de hacerlo es la siguiente:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="direccion">
 <!-- El elemento direccion no pertenece al vocabulario de la XSLT --
>
<direccion>
<xsl:apply-templates/>
</direccion>
</xsl:stylesheet>

Estas consideraciones requieren ,por tanto, que las construcciones de documentos

posean nombres universales, cuyo ámbito se extienda más allá del documento que
las contiene. Por tanto el mecanismo mediante el cual se puede llevar a cabo esta
identificación es lo que se describe en la especificación de los namespaces
(traducido podría ser "espacios de nombre").

¿Qué es exactamente un "namespace"?

Definició n de "namespace"

Por tanto, un "namespace" XML es una colección de nombres, identificados

por un URI, que se utiliza en los documentos XML para identificar los
nombres de los elementos y atributos.

Declaración de un "namespace"

Como podemos observar en el ejemplo, la declaración del "namespace" se realiza

mediante el atributo xmlns, cuyo valor es un URI que identifica de forma unívoca el
nombre.

xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

El atributo xmlns puede ir seguido del carácter dos puntos :, opcional, y el nombre
del "namespace":

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

Entonces este nombre xsl, será el prefijo de los elementos de este vocabulario XML
xsl:template.

Si no colocamos el carácter dos puntos y este nombre, entonces el nombre del

"namespace" es indicado por el nombre del elemento que tiene el atributo xmlns.

<math xmlns="http://www.w3.org/1998/Math/MathML">

En este caso, el nombre del namespace es math

Cada elemento se identifica con el namespace de dos maneras:

• Incluyéndolo como prefijo del nombre del elemento.

• <dirfis:direccion
xmlns:dirfis="http://www.palotes.com/direccionfisica">
• <dirfis:calle>Avd. Diagonal 8</dirfis:calle>
• En el caso de no declararlo implicitamente, se considera que es un"namespace"
por defecto y en tal caso el elemento en el que se especifica y todos los
elementos que contiene llevarán asociados ese "namespace".
• <math xmlns="http://www.w3.org/1998/Math/MathML">
 • <mrow>
• ......
• </mrow>
• </math>

Ambito del "namespace"

Denominamos ámbito del "namespace" al grupo de elementos y atributos a los que

afecta el "namespace". Por regla general el "namespace" es aplicable al elemento
en que se especifica y a todos los elementos dentro del contenido de ese elemento.

<dirserv:servidor
xmlns:dirserv="http://www.palotes.com/direccionservidor">
<dirserv:url>http://www.palotes.com</dirserv:url>
<dirserv:direccion>123.45.67.8</dirserv:direccion>
</dirserv:servidor>

Siempre y cuando no sea anulado por otra declaración de "namespace"

[<![CDATA[<html xmlns="http://www.w3.org/1999/xhtml">
.....
<body>
...
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
.....
</mrow>
</math>
</body>
</html>

El "namespace" html afecta al elemento body pero no al elemento mrow al tener

como padre el elemento math, en el cual se ha definido el "namespace" por defecto
math.

Direcciones

Para más información sobre el tema, podéis visitar las siguientes direcciones:

• FAQ Namespaces de Ronald Bourret

• 19 Short Questions about Namespaces, por David Megginson
• XML Namespaces by Example, por Tim Bray