Los parsers de XML que son capaces de validar documentos con DTD leen esos documentos y el DTD asociado. En caso de que el documento XML no cumpla los requerimientos que le impone el DTD, nos advertirán del error y no validarán el documento.

Mediante los DTD definimos cómo será nuestro dialecto de XML (recordad que nosotros definimos qué etiquetas vamos a usar en nuestros documentos, qué significado les damos, etc.). Esta capacidad de definir un dialecto propio de XML es lo que permite que XML se denomine.

A pesar de que DTD es un estándar que deberá ser sustituido por XML Schema, sigue siendo muy usado. Además, su uso resulta más simple que el de XML Schema. Por otro lado, es más compacto. A eso hay que añadir que las mejoras que aporta XML Schema no son necesarias para la mayoría de los usos. Con DTD se han definido multitud de dialectos de XML que son usados ampliamente en Internet, como RDF para la web semántica, MathML para documentos matemáticos, XML/EDI para intercambio de datos electrónicamente para negocio, VoiceXML para aplicaciones que se utilicen mediante voz o que hagan uso de ésta, WML para representar documentos para los navegadores de dispositivos móviles como teléfonos, etc.

Veamos un posible DTD para la receta del ejemplo que nos definirá la forma que deben tener las recetas escritas en Receta XML:

<!-- DTD de ejemplo para RecetaXML -->

          <!ELEMENT Receta (Nombre, Descripcion?,

          Ingredientes?, Instrucciones?)>

          <!ELEMENT Nombre (#PCDATA)>

          <!ELEMENT Descripcion (#PCDATA)>

          <!ELEMENT Ingredientes (Ingrediente*)>

          <!ELEMENT Ingrediente (Cantidad, Item)>

          <!ELEMENT Cantidad (#PCDATA)>

          <!ATTLIST Cantidad unidad CDATA #REQUIRED>

          <!ELEMENT Item (#PCDATA)>

          <!ATTLIST Item opcional CDATA “0”

          vegetariano CDATA “si”>

          <!ELEMENT Instructiones (Paso+)>

          <!ELEMENT Paso (#PCDATA)>

De este documento DTD podemos inferir una descripción de las reglas de validez que sea un poco más legible:

• Una receta consta de un nombre (obligatorio), una descripción (opcional), unos ingredientes (opcionales) y unas instrucciones (opcionales).
• El nombre y la descripción pueden contener caracteres alfanuméricos (PCDATA corresponde a Parsed Character Data).
• Los ingredientes son una lista de elementos ingrediente.
• Un ingrediente consta de un ítem y la cantidad.
• La cantidad es un valor alfanumérico, teniendo la etiqueta un atributo, unidad que nos describe qué unidad de medida estamos utilizando.
• Un ítem de la receta consta del nombre (un valor alfanumérico) y puede tener dos atributos: opcional (si el ingrediente es o no obligatorio) y vegetariano (si el ingrediente es apto para vegetarianos).
• Las instrucciones de elaboración son una lista de pasos.
• Un paso consta de un texto alfanumérico descriptivo del paso.

Vamos a estudiar ahora la sintaxis de DTD para definir los dialectos XML.

El concepto de bien formado procede de las matemáticas, donde es factible escribir una expresión usando símbolos matemáticos como,

1)1(--5(+=)4 <3

que, a pesar de estar formado por símbolos matemáticos, no significa nada, ya quen o sigue las convenciones y normas de escritura de expresiones matemáticas. Esta expresión matemática no está bien formada.

En XML, un documento bien formado es el que sigue las siguientes normas:

Todas las etiquetas cerradas: en HTML podemos trabajar con un gran nivel de relajación de las normas sintácticas, lo cual nos permite dejar etiquetas (como <B> por ejemplo) abiertas a lo largo de todo el documento, o usando indiscriminadamente etiquetas como <P> sin cerrarlas con la correspondiente </P>. XML no permite este nivel de relajación. Todas las etiquetas abiertas deben tener su correspondiente etiqueta de cierre. Esto se debe a que las etiquetas en XML representan una información jerárquica que nos indica cómo se relacionan los diferentes elementos entre ellos. Si no cerramos las etiquetas, introducimos en esta representación una serie de ambigüedades que nos impedirían un procesamiento automático.

No puede haber solapamiento de etiquetas: una etiqueta que se abre dentro de otra etiqueta debe cerrarse antes de cerrar la etiqueta contenedora. Por ejemplo,

<Libro>Platero y Yo<Autor>J. R.Jiménez</Libro></Autor>

no está bien formado porque Autor no se cierra dentro de Libro, que es donde debería cerrarse. La sentencia correcta sería:

<Libro>Platero y Yo<Autor>J. R. Jiménez</Autor></Libro>

Es decir, la estructura del documento debe ser estrictamente jerárquica.

Los valores de los atributos deben estar entrecomillados; a diferencia de HTML, donde podemos poner atributos sin comillas. Por ejemplo:

<IMAGE src=img.jpg SIZE=10>

En XML todos los atributos deben estar entrecomillados. Los atributos anteriores quedarían, pues, de la siguiente manera:

<IMAGE src=“img.jpg” SIZE=“10”>.

Los caracteres <, > y “ siempre representados por entidades de carácter: para representar estos caracteres (en el texto, no como marcas de etiqueta) debemos usar siempre las entidades de carácter especiales: <, > y “. Estos caracteres son especiales para XML.

Bien formado equivale a analizable

La importancia que reviste el hecho de que un documento esté o no bien formado en XML deriva del hecho de que un documento bien formado puede ser analizable sintácticamente o parseable (es decir, procesable automáticamente). Existen multitud de parsers (analizadores) en numerosos lenguajes de programación que nos permiten trabajar con los documentos XML. Los parsers de XML son capaces de detectar los errores estructurales de los documentos XML (es decir, si están o no bien formados) y notificárselo al programa. Esta funcionalidad es importantísima para un programador, ya que le libera de la tarea de detectar errores para encomendársela a un programa que lo hará por sí solo (el parser).

Algunos parsers van más allá de la simple capacidad de detectar si el documento está bien formado o no y son capaces de identificar los documentos válidos , entendiendo por válido el hecho de que la estructura, posición y número de etiquetas sean correctos y tengan sentido.

Imaginemos por un momento el siguiente pedazo de nuestro documento de recetas:

<Ingrediente>

  <Cantidad unidad=“pieza”>3</Cantidad>

  <Cantidad unidad=“litro”>4</Cantidad>

  <Item>Patatas</Item>

</Ingrediente>

Este XML está bien formado, sigue todas las normas para que lo esté, pero a pesar de ello no tiene ningún sentido. ¿Que significaría? Tenemos patatas en la receta, ¿pero en qué cantidad? En este caso el problema sería que tenemos un documento XML bien formado, pero que carece de utilidad, ya que no tiene sentido. Necesitamos indicar de alguna manera cómo controlar que un documento tenga sentido. En nuestro caso, tenemos que especificar que cada ingrediente tendrá sólo una etiqueta de tipo cantidad, que ésta tendrá un atributo opcional unidad y que no contendrá etiquetas anidadas. Para ello, XML nos proporciona un par de lenguajes de especificación de estructura del documento, XML Schema y DTD, que veremos posteriormente.

XML es un estándar diseñado para permitir que se comparta información con facilidad. ¿Qué pasaría si uniésemos información en XML procedente de dos fuentes diferentes para enviarla a una tercera? ¿Podríamos en ese caso tener algún conflicto por coincidencia del nombre de las etiquetas? Imaginemos el siguiente caso: un proveedor de Internet guarda todos sus datos en XML. La sección comercial almacena la dirección de la vivienda del cliente en un campo llamado <direccion>. Por otro lado, el servicio de asistencia al cliente guarda en <direccion> la dirección de correo electrónico del cliente, y finalmente el centro de control de red guarda en <direccion> la dirección IP del ordenador del cliente. Si unimos en un sólo fichero lo procedente de las tres divisiones de la empresa, nos podemos encontrar con:

<cliente>
...
<direccion>Calle Real</direccion>
...
<direccion>ventas@cliente.com
Esta dirección de correo electrónico está
siendo protegida de "spam bots",
necesitas habilitar Javascript para poder verlo.
</direccion>
...
lt;direccion>192.168.168.192</direccion>
...
</cliente>

Evidentemente en este caso tendríamos un problema, ya que no podríamos distinguir el significado de <direccion> en cada uno de los casos. Para ello, en 1999 el W3C definió una extensión de XML llamada espacios de nombres (namespaces) que permite resolver conflictos y ambigüedades de este tipo.

Uso de los espacios de nombres

Los espacios de nombres son un prefijo que ponemos a las etiquetas de XML para indicar a qué contexto se refiere la etiqueta en cuestión. En el ejemplo anterior podríamos definir:

<red:direccion>: para uso por el centro de control de red.
<aten:direccion>: para uso por el servicio de atención al cliente.
<comer:direccion>: para uso por el departamento comercial.

De esta forma, nuestro elemento queda compuesto así:

<cliente>
...
<comer:direccion>Calle Real</comer:direccion>
....
<aten:direccion>ventas@cliente.com
Esta dirección de correo electrónico
está siendo protegida de "spam bots",
necesitas habilitar Javascript para poder verlo.
</aten:direccion>
....
<red:direccion>192.168.168.192</red:direccion>
...
</cliente>

Para usar un espacio de nombres en un documento, debemos declararlo previamente. Esta declaración puede tener lugar en el elemento raíz del documento de la siguiente forma:

<?xml version=“1.0” encoding=“iso-8859-1”?>
<carteraclientes
xmlns:comer=“http://www.empresa.com/comercial”
xmlns:aten=“http://www.empresa.com/atencion”
xmlns:red=“http://www.empresa.com/red”>
<cliente>
...
<comer:direccion>Calle Real</comer:direccion>
...
<aten:direccion>ventas@cliente.com
Esta dirección de correo electrónico
está siendo protegida de "spam bots",
necesitas habilitar Javascript para poder verlo.
</aten:direccion>
...
<red:direccion>192.168.168.192</red:direccion>
...
</cliente>
</carteraclientes>

La definición consta de unos atributos xmlns (XML namespace), donde proporcionamos el prefijo que usaremos para el espacio de nombres y una URI (Uniform Resource Identifier) que será un identificador único del espacio de nombres.

DTD (Document Type Definition) es un estándar que nos permite definir una gramática que deben cumplir nuestros documentos XML para considerarlos válidos. Una definición DTD para n documentos XML especifica: qué elementos pueden existir en un documento XML, qué atributos pueden tener éstos, qué elementos pueden o deben aparecer contenidos en otros elementos y en qué orden.

Los parsers de XML que son capaces de validar documentos con DTD leen esos documentos y el DTD asociado. En caso de que el documento XML no cumpla los requerimientos que le impone el DTD, nos advertirán del error y no validarán el documento.

Mediante los DTD definimos cómo será nuestro dialecto de XML (recordad que nosotros definimos qué etiquetas vamos a usar en nuestros documentos, qué significado les damos, etc.). Esta capacidad de definir un dialecto propio de XML es lo que permite que XML se denomine.

A pesar de que DTD es un estándar que deberá ser sustituido por XML Schema, sigue siendo muy usado. Además, su uso resulta más simple que el de XML Schema. Por otro lado, es más compacto. A eso hay que añadir que las mejoras que aporta XML Schema no son necesarias para la mayoría de los usos. Con DTD se han definido multitud de dialectos de XML que son usados ampliamente en Internet, como RDF para la web semántica, MathML para documentos matemáticos, XML/EDI para intercambio de datos electrónicamente para negocio, VoiceXML para aplicaciones que se utilicen mediante voz o que hagan uso de ésta, WML para representar documentos para los navegadores de dispositivos móviles como teléfonos, etc.

Veamos un posible DTD para la receta del ejemplo que nos definirá la forma que deben tener las recetas escritas en Receta XML:

<!-- DTD de ejemplo para RecetaXML -->
<!ELEMENT Receta (Nombre, Descripcion?,

Ingredientes?, Instrucciones?)>

<!ELEMENT Nombre (#PCDATA)>

<!ELEMENT Descripcion (#PCDATA)>

<!ELEMENT Ingredientes (Ingrediente*)>

<!ELEMENT Ingrediente (Cantidad, Item)>

<!ELEMENT Cantidad (#PCDATA)>

<!ATTLIST Cantidad unidad CDATA #REQUIRED>

<!ELEMENT Item (#PCDATA)>

<!ATTLIST Item opcional CDATA “0”

vegetariano CDATA “si”>

<!ELEMENT Instructiones (Paso+)>

<!ELEMENT Paso (#PCDATA)>

De este documento DTD podemos inferir una descripción de las reglas de validez que sea un poco más legible:

• Una receta consta de un nombre (obligatorio), una descripción (opcional), unos ingredientes (opcionales) y unas instrucciones (opcionales).
• El nombre y la descripción pueden contener caracteres alfanuméricos (PCDATA corresponde a Parsed Character Data).• Los ingredientes son una lista de elementos ingrediente.
• Un ingrediente consta de un ítem y la cantidad.
• La cantidad es un valor alfanumérico, teniendo la etiqueta un atributo, unidad que nos describe qué unidad de medida estamos utilizando.
• Un ítem de la receta consta del nombre (un valor alfanumérico) y puede tener dos atributos: opcional (si el ingrediente es o no obligatorio) y vegetariano (si el ingrediente es apto para vegetarianos).
• Las instrucciones de elaboración son una lista de pasos.
• Un paso consta de un texto alfanumérico descriptivo del paso.
• Vamos a estudiar ahora la sintaxis de DTD para definir los dialectos XML.

Como hemos visto, XML posibilita la comprobación automática de la correcta forma de un documento, pero sin información adicional es imposible comprobar la validez de éste a partir del propio documento. Para ello, el W3C ha desarrollado algunos estándares de XML que nos permiten validar un documento a partir de una especificación formal de cómo debe ser éste. Dichos estándares son DTD y XSchema.

DTD es un estándar antiguo, derivado de SGML y que adolece de algunas deficiencias graves, siendo la más grave de ellas el hecho de no estar escrito en XML. XSchema, por otro lado, es un estándar relativamente moderno, muy potente y extensible, que además está escrito en XML íntegramente.

Las convenciones sintácticas de DTD

Como hemos visto, la sintaxis de DTD no resulta evidente a primera vista. Pese a ello, tampoco es excesivamente compleja. El primer paso para entenderla es disponer de las definiciones y usos de los diferentes símbolos usados, que podemos ver en la tabla siguiente:

Los elementos de DTD llamados ELEMENT nos definen una etiqueta de nuestro dialecto de XML. Por ejemplo:

<!ELEMENT Receta (Nombre, Descripcion?,
  Ingredientes?, Instrucciones?)>

Define la etiqueta Receta, especificando qué contienen las subetiquetas: Nombre, Descripción, Ingredientes e Instrucciones, y agregando que estas tres últimas son opcionales (como indica el símbolo ?). La definición de ELEMENT es la siguiente:

<!ELEMENT nombre categoria>
  <!ELEMENT nombre (contenido)>

Elementos vacíos

Los elementos vacíos se declaran empleando la categoría EMPTY.

 <!ELEMENT nombre EMPTY>

Este elemento nombre, en XML se usaría así:

 <nombre />

Elementos con sólo caracteres

Los elementos que sólo contendrán datos alfanuméricos se declaran
usando #PCDATA entre paréntesis.

 <!ELEMENT nombre (#PCDATA)>

Elementos con cualquier contenido

Los elementos que declaremos usando ANY como indicador de contenido pueden contener cualquier combinación de datos parseables:

 <!ELEMENT nombre ANY>

Elementos con subelementos (secuencias)

Los elementos con uno o más elementos hijos se definen con el nombre de los elementos hijos entre paréntesis:

 <!ELEMENT nombre (hijo1)>
  <!ELEMENT nombre (hijo1, hijo2, ......)>

Por ejemplo:

 <!ELEMENT coche (marca, matricula, color)>

Los hijos que se declaran como una secuencia de elementos separados por comas deben aparecer en el mismo orden en el documento. Los elementos hijo también deben declararse en el documento DTD. Estos elementos hijo pueden, a su vez, tener elementos hijo. La declaración completa de coche sería entonces:

 <!ELEMENT coche (marca, matricula, color)>
  <!ELEMENT marca (#PCDATA)>
  <!ELEMENT matricula (#PCDATA))>
  <!ELEMENT color (#PCDATA)>

Cardinalidad de las ocurrencias de elementos

La siguiente declaración nos indica que el elemento hijo sólo puede ocurrir una vez dentro del elemento padre:

 <!ELEMENT nombre (hijo)>

Si deseamos que el elemento hijo aparezca más de una vez y como mínimo una vez:

 <!ELEMENT nombre (hijo+)>

Si deseamos que pueda aparecer cualquier número de veces (incluyendo la posibilidad de que no aparezca ninguna):

 <!ELEMENT nombre (hijo*)>

Si sólo deseamos que pueda aparecer una vez, pero que no sea obligatorio:

 <!ELEMENT nombre (hijo?)>

Elementos con contenido mixto

Podemos declarar también elementos que contengan otros elementos hijos y/o datos alfanuméricos.

 <!ELEMENT nombre (#PCDATA hijo hijo2)*>

Como ya hemos visto, los elementos en XML pueden tener atributos. Evidentemente, en DTD disponemos de un mecanismo para indicar qué atributos puede tener un ELEMENT, de qué tipo, si son o no obligatorios, etc. Para ello disponemos del elemento ATTLIST, cuya sintaxis es:

<!ATTLIST elemento atributo tipo-atributo valor-defecto>

Un ejemplo de uso sería:

<!ATTLIST pago metodo CDATA “contra-reembolso” >

Y su uso en XML:

<pago metodo=“contra-reembolso” />

El tipo de atributo debe ser uno de los de la lista:

Valor por defecto

En el siguiente ejemplo:

 <!ELEMENT pago EMPTY>
  <!ATTLIST pago metodo CDATA “contra-reembolso” >

El siguiente XML se considera válido:

 <pago />

En este caso, donde no especificamos valor para método, éste contendrá el valor por defecto de contra-reembolso.

Sintaxis de #IMPLIED

En el siguiente ejemplo:

 <!ELEMENT pago EMPTY>
  <!ATTLIST pago metodo CDATA #IMPLIED >

Validará correctamente el siguiente XML:

 <pago metodo=“tarjeta” />
  <pago />

Usaremos, pues, #IMPLIED en aquellos casos en los que no queremos forzar al usuario a usar atributos pero no podemos poner valores por defecto.

Sintaxis de #REQUIRED

En el siguiente ejemplo:

 <!ELEMENT pago EMPTY>
  <!ATTLIST pago metodo CDATA #REQUIRED >

Validará correctamente el siguiente XML:

 <pago metodo=“tarjeta” />

pero no validará:

 <pago />

Usaremos #REQUIRED en aquellos casos en los que no podemos proporcionar un valor por defecto, pero deseamos que el atributo aparezca y se le asigne algún valor.

Para que un documento XML quede vinculado a un DTD determinado, tenemos dos opciones: incluir el DTD en el documento XML o usar una referencia externa al DTD. La primera opción es la más fácil de usar, pero la que presenta más inconvenientes, ya que aumenta el tamaño de los documentos XML y complica su mantenimiento, puesto que un cambio en el DTD implica revisar todos los documentos en los que lo hemos incluido. El formato de un documento XML donde hubiésemos incluido sería:

<?xml version="1.0"?>
	<!DOCTYPE Receta [
	<!ELEMENT Receta (Nombre, Descripcion?,
	Ingredientes?, Instrucciones?)>
	<!ELEMENT Nombre (#PCDATA)>
	<!ELEMENT Descripcion (#PCDATA)>
	<!ELEMENT Ingredientes (Ingrediente)*>
	<!ELEMENT Ingrediente (Cantidad, Item)>
	<!ELEMENT Cantidad (#PCDATA)>
	<!ATTLIST Cantidad unidad CDATA #REQUIRED>
	<!ELEMENT Item (#PCDATA)>
	<!ATTLIST Item opcional CDATA "0"
	vegetariano CDATA "si">
	<!ELEMENT Instructiones (Paso)+>
	<!ELEMENT Paso (#PCDATA)>
	]>
	<Receta>
	<Nombre>Tortilla de patatas</NOMBRE>
	<Descripcion>
	La tradicional y típica tortilla de patatas, tal
	como la hacen todas las madres.
	</Descripcion>
	<Ingredientes>
	<Ingrediente>
	<Cantidad unidad="pieza">3</Cantidad>
	<Item>Patata</Item>
	</Ingrediente>
	<Ingrediente>
	<Cantidad unidad="pieza">2</Cantidad>
	<Item>Huevos</Item>
	</Ingrediente>
	<Ingrediente>
	<Cantidad unidad="litro">0.1</Cantidad>
	<Item>Aceite</Item>
	</Ingrediente>
	</Ingredientes>
	<Instrucciones>
	<Paso>
	Pelar y cortar la patata en rodajas
	</Paso>
	<Paso>
	Poner aceite en una paella
	</Paso>
	<!-- ... ... -->
	</Instrucciones>
	</Receta>

Podemos referenciar un DTD externo al documento XML. Para ello disponemos de dos tipos de referencias posibles: públicas o privadas. Un ejemplo de referencia privada es el siguiente:

<?xml version=“1.0”?>
	<!DOCTYPE Receta SYSTEM “receta.dtd”>
	<Receta>
	...

Y otro, usando ahora una referencia externa pública:

<?xml version=“1.0”?>
	<!DOCTYPE Receta
	PUBLIC “-//W3C//DTD XHTML 1.0 STRICT/EN”
	“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
	<Receta>
	...