| Artículos | 01 ENE 2000

XML: validación de documentos

Tags: Histórico
Para validar un documento XML hay que escribir una DTD, sepa cómo se hace
Francisco Charte.
Un documento XML puede estar bien formado y, sin embargo, ello no implica que sea válido. En este artículo le explicamos cómo usar una DTD para validar documentos, introduciendo también nuevos conceptos como los atributos.

En la introducción a XML publicada en un número anterior, se indicó qué era un documento XML bien formado y qué un documento válido, haciéndose hincapié en las diferencias entre ambos términos. También se vio que existían analizadores XML validantes y no validantes. Los primeros comprueban que el documento esté bien formado y, además, que sea válido. Los segundos, por el contrario, tan sólo verifican si el documento está bien formado.
Aunque es posible verificar manualmente la corrección de un documento, no se trata desde luego de un método práctico, sobre todo cuando se manejan documentos extensos y, además, elaborados por distintas aplicaciones o usuarios. Lógicamente, es mucho más cómodo y eficiente utilizar un analizador validante. Éste, no obstante, necesita conocer las reglas que rigen el documento, de lo contrario no sabrá si es o no válido.
El método utilizado para facilitar las reglas al analizador, consiste en escribir una definición de tipo de documento, conocida abreviadamente como DTD. No es necesario escribir una DTD nueva para cada documento XML. De hecho, uno de los mayores objetivos actuales de muchas empresas es crear DTDs estándar, que puedan ser usadas para el intercambio de documentos en formato XML. Una DTD generalmente se almacena en un archivo independiente, aunque también puede facilitarse integrada en el propio documento XML.

¿Qué es una DTD?
Físicamente, una DTD es un documento con estructura similar a un documento XML. El contenido, sin embargo, no son datos propiamente dichos, como en el caso de XML, sino indicaciones acerca de la estructura de un determinado tipo de archivo.
A pesar de que una DTD puede parecer, sobre todo al principio, relativamente compleja, en su formato más básico no es más que una enumeración de los elementos que podrán existir en un documento XML, indicando el tipo de cada uno de ellos. Cada elemento se describe en el interior de una etiqueta <!ELEMENT>, en la cual se incluirá su nombre y, entre paréntesis, su tipo o la lista de elementos que podrá contener.
Como es obvio, antes de poder escribir una DTD es preciso un análisis y, posiblemente, una plasmación gráfica de la estructura del documento que quiere definirse. Partiendo de este trabajo, escribir la DTD no será una tarea especialmente compleja.
En lugar de describir teóricamente cuál sería la estructura de una DTD, definición que puede encontrar en cualquier momento en la especificación del estándar, vamos a ver en la práctica cómo crear una DTD. Ésta nos servirá para validar el documento XML, creado en la entrega previa, que contenía una lista de productos.

Análisis de la estructura del documento
El Listado 1 muestra el documento XML utilizado como último ejemplo en la entrega anterior a ésta, conteniendo una lista de productos de un hipotético comercio. Como puede verse en la Figura 1, existe un nodo raíz, <ListaProductos>, que contiene a otras dos: <Software> y <Libros>. Ambas sirven como contenedores de varias etiquetas <Producto> y es ahí, precisamente, donde empiezan nuestros problemas de estructura.
Unas etiquetas <Producto> contienen directamente un dato en su interior: el nombre del producto. Otras sirven como contenedor de las etiquetas <Nombre>, <Descripcion>, <Fabricante> y <Distribuidores>, en el caso de los productos de software, o <Titulo>, <Autor> y <Editorial> si el producto es un libro. Validar un documento de este tipo resultaría relativamente complejo, puesto que la etiqueta <Producto> no sigue un patrón fijo de comportamiento.
Tras remodelar la jerarquía de elementos y pensar la relación existente entre ellos, una estructura mucho más lógica podría ser la mostrada en la Figura 2. Sigue existiendo un elemento raíz contenedor de otros dos, pero los problemas que existían con los elementos <Producto> desaparecen por completo. Esta representación gráfica y parcial de la estructura nos servirá para escribir la DTD que, a su vez, se utilizará para validar el documento.
No hace falta decir que el documento XML de ejemplo que estamos usando, según se ve en Listado 2 o la Figura 1, no cumple con la estructura de la Figura 2. Esto significa que, tras escribir la DTD y aplicarla, el analizador nos comunicará que no se trata de un documento XML válido, a pesar de que esté bien formado.

Elaborar la DTD
Teniendo a la vista la Figura 2, veamos cómo podemos elaborar la definición de tipo de documento para las listas de productos que gestionarán nuestras aplicaciones. Como se ha indicado antes, cada uno de los elementos que aparece en la mencionada figura se traducirá en una etiqueta <!ELEMENT>, en la cual se indicará el contenido que puede tener el elemento.
El primer elemento, actuando como raíz de todos los demás, es ListaProductos. Éste contendrá en su interior dos subelementos: Software y Libros. Observe el término contendrá, casi imperativo. No se ha dicho podrá contener, en cuyo caso los subelementos anteriores podrían o no existir en la lista de productos. Fíjese también en la imposibilidad de que se repitan los subelementos. ListaProductos tan sólo contendrá en su interior dos elementos, los ya indicados, ni uno más ni uno menos.
La etiqueta DTD con la que se describiría el elemento ListaProductos sería <!ELEMENT ListaProductos (Software, Libros)>. Tras la marca de proceso !ELEMENT se indica el nombre de la etiqueta raíz y, entre paréntesis, el nombre de las etiquetas que contendrá.
A diferencia de ListaProductos, los elementos Software y Libros pueden contener un número indeterminado de subelementos aunque, eso sí, todos ellos con la misma estructura. Dentro de un elemento Software existirán uno o más Producto, mientras que en el interior de un Libros el elemento repetitivo sería Libro. La correspondiente entrada en la DTD, por ejemplo en el caso del elemento Software, sería <!ELEMENT Software (Producto+)>. Observe el símbolo + dispuesto detrás de Producto, él es el que especifica que se repetirá tantas veces como sea necesario.
La definición DTD de un Producto o un Libro es bastante sencilla. Basándonos en la definición anterior de ListaProductos, lo único que habría que hacer sería enumerar los elementos que habría en su interior, indicando la posible repetición.
En el último nivel se encuentran los elementos que contienen datos, como Descripción o Autor. Éstas etiquetas no servirán como contenedoras de otras, sino que contendrán un texto. Este tipo de dato se identifica en una DTD como #PCDATA. Así, la definición del elemento Titulo, por ejemplo, quedaría como <!ELEMENT Titulo (#PCDATA)>.
Con todo, la DTD completa para nuestro documento sería la mostrada en el Listado 2. El sangrado no es algo obligatorio, pero ayuda a identificar los distintos niveles de contención de unos elementos en otros.

Aplicar una DTD a un documento XML
Una definición de tipo de documento no es útil per sé, aunque puede utilizarse como referencia para pre

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información