El API JAXP

Despu�s de la declaraci�n XML, el prologo del documento puede incluir un DTD, que nos permite especificar los tipos de etiquetas que se pueden incluir en nuestro documento XML. Adem�s de decirle al analizador de validaci�n qu� etiquetas son validas, y en qu� disposici�n, un DTD le dice a los analizadores con validaci�n y sin validaci�n donde se espera que vaya el texto, lo que permite al analizador determinar si los espacios en blanco que ve son significantes o ignorables.

�Definiciones DTD B�sicas

Por ejemplo, cuando estabamos analizando el visualizador de disapositivas, vimos que el m�todo characters fue invocado varias veces antes y despu�s de los comentarios y los elementos slide. En dichos casos, los espacios en blanco que constituian el final de l�nea y la identaci�n rodeaban la marca. El objetivo era hacer le�ble el documento XML -- los espacios en blanco de ninguna forma eran parte del contenido del documento. Para empezar a aprender sobre definiciones DTD, empecemos dici�ndole al analizador d�nde se pueden ignorar los espacios en blanco.

Empezamos creando un fichero llamado slideshow.dtd. Introducimos una declaraci�n XML y un comentario para identificar el fichero, como se ve abajo.

<?xml version='1.0' encoding='us-ascii'?>

<!-- DTD for a simple "slide show". -->

Luego, a�adimos el texto en negrita de abajo para especificar que un elemento slideshow contiene elementos slide y nada m�s.

<!-- DTD for a simple "slide show". -->

<!ELEMENT slideshow (slide+)>

Como podemos ver, la etiqueta DTD empieza con <! seguido por el nombre de etiqueta (ELEMENT). Despu�s del nombre de etiqueta viene el nombre del elemento que est� siendo definido (slideshow) y, entre par�ntesis, uno o m�s �tems que indican los contenidos v�lidos para ese elemento. En este caso, la notaci�n dice que un slideshow consta de uno o m�s elementos slide.

Sin el signo m�s, la definici�n dir�a que un slideshow consta de un �nico elemento slide. Aqu� podemos ver los cualificadores que podemos a�adir a las definiciones de elementos.

Podemos incluir varios elementos dentro de los par�ntesis en una lista separada por comas, y usar un cualificador en cada elemento para indicar cu�ntos ejemplares de ese elemento podr�an ocurrir. La lista separada por comas dice qu� elementos son v�lidos y el orden en el que pueden ocurrir.

Tambi�n podemos anidar par�ntesis para agrupar varios �tems. Por ejemplo, despu�s de definir un elemento image, podr�amos declarar que cada image debe estar emparejada con un elemento title en un slide especificando ((image, title)+). Aqu� el signo m�s se aplica a la pareja image/title para especificar que pueden ocurrir una o m�s parejas de los �tems especificados.

�Definir Texto y Elementos Anidados

Ahora que le hemos dicho al analizador algo sobre donde no se espera texto, veamos como decirle d�nde si puede ocurrir el texto. A�adimos el siguiente texto en negrita para definir los elementos slide, title, item, y list.

<!ELEMENT slideshow (slide+)>
<!ELEMENT slide (title, item*)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT item (#PCDATA | item)* >

La primera l�nea dice que un slide consta de un title seguido por cero o m�s elementos item. Hast aqu� nada nuevo. La siguiente l�nea dice que un title consta completamente de un parsed character data (PCDATA). Lo que se conoce como "texto" en casi todo el mundo, pero hablando en XML, es llamado "parsed character data". (Que se distingue de las secciones CDATA, que contienen datos que no son analizados). La almohadilla "#" que precede a PCDATA indica que lo que sigue es una palabra especial, en vez de un nombre de elemento.

La �ltima l�nea presenta la barra vertical (|), lo que indica una condici�n OR. En este caso, pueden ocurrir un PCDATA o un item. El asterisco del final dice que puede ocurrir cero o m�s veces sucesivas. El resultado de est� especificaci�n es conocido como un modelo de contenido mixto, porque se puede interponer cualquier n�mero de elementos entre el texto. Dichos modelos siempre deben estar definidos previamente con #PCDATA, un n�mero de �tems alternativos separados por barras verticales (|), y un asterisco (*) al final.

�Limitaciones de los DTDs

Ser�a bonito si pudieramos especificar que un item contiene texto, o texto seguido por una o m�s listas de �tems. Pero esta clase de especificaciones se convierte en dificil de conseguir en un DTD. Por ejemplo, podr�amos intentar definir un item como este.

<!ELEMENT item (#PCDATA | (#PCDATA, item+)) >

Tan pronto como el analizador ve #PCDATA y una barra vertical, requiere que el resto de la definici�n est� conforme al modelo de contenido mixto. Esta especificaci�n no lo hace, por eso obtenemos un error que dice: Illegal mixed content model for 'item'. Found &#x28; ..., donde el car�cter 28 es el �ngulo derecho que termina la definici�n.

Intentar definir una doble definici�n del �tem tampoco funciona. Una especificaci�n como �sta:

<!ELEMENT item (#PCDATA) >
<!ELEMENT item (#PCDATA, item+) >

Produce unn aviso de "definici�n duplicada" cuando el analizador la ejecuta. De echo, la segunda definici�n es ignorada. Por eso parece que definir un modelo de contenido mixto (que permite que se interpongan elementos item entre el texto) es lo mejor que podemos hacer.

Adem�s de las limitaciones del modelo de contenido mezclado mencionadas arriba, no hay forma posterior de cualificar el tipo de texto que puede ocurrir donde se ha especificado PCDATA. �Deber�a contener s�lo n�meros? �Deber�a estar en formato fecha? o �posiblemente en formato de moneda? No hay forma de decirlo en el contexto de un DTD.

Finalmente, observamos que el DTD no ofrece sentido de herencia. La definici�n del elemento title se aplica igual a un t�tulo de slide que a un t�tulo de item. Cuando extendamos el DTD para permitir marcas del estilo HTML adem�s del texto normal tendr�a sentido restringir el tama�o del t�tulo de un item compar�ndolo con un t�tulo de slide,por ejemplo. Pero la �nica forma de hacer esto ser�a darle a uno de ellos un nombre diferente, como "item-title". La l�nea base es que este tipo de herencia en el DTD nos fuerza a introducir un "�rbol con guiones" (o su equivalente) en nuestro espacio de nombres. Todas estas limitaciones son motivos fundamentales detr�s del desarrollo de los esquemas de especificaciones est�ndards.

�Valores de Elementos Especiales en el DTD

En vez de usar una lista de elementos entre par�ntesis, la definici�n de elemento podr�a usar uno de los dos valores especiales: ANY o EMPTY. La especificaci�n ANY dice que el elemento podr�a contener otro elemento definido, o PCDATA. Esta especificaci�n se usa normalmente para el elemento ra�z en un documento XML de prop�sito general como el que podr�amos crear con un procesador de textos. Los elementos textuales podr�an ocurrir en cualquier orden en dicho documento, por eso, especificar ANY tiene sentido.

La especificaci�n EMPTY dice que el elemento no contiene contenidos. Por eso el DTD para mensajes de email que nos permite "marcar" el mensaje con <flag/> podr�a tener una l�nea como �sta en el DTD.

<!ELEMENT flag EMPTY>

�Referenciar el DTD

En este cado, la definici�n del DTD est� en un fichero separado del documento XML. Esto significa que tenemos que referenciarlo desde el documento XML, lo que hace que el fichero DTD sea parte del subconjunto externo de la "Document Type Definition" (DTD) para el fichero XML. Como veremos m�s adelante, podemos incluir partes del DTD dentro del documento. Dichas definiciones constituyen el subconjunto local del DTD.

Para referenciar el fichero DTD que acabamos de crear, a�adimos la l�nea en negrita de abajo a nuestro fichero slideSample.xml.

<!--  A SAMPLE set of slides  -->

<!DOCTYPE slideshow SYSTEM "slideshow.dtd">

<slideshow 

De nuevo, la etiqueta DTD empieza con "<!". En este caso, el nombre de la etiqueta, DOCTYPE, dice que el documento es un slideshow, lo que significa que el documento consta de un elemento slideshow y cualquier cosa que haya dentro de �l.

<slideshow>
  ...
</slideshow>

Esta etiqueta define el elemento slideshow como el elemento ra�z del documento. Un documento XML debe tener exactamente un elemento ra�z.

La etiqueta DOCTYPE ocurre despu�s de la declaraci�n XML y antes del elemento ra�z. El identificador SYSTEM especifica la localizaci�n del fichero XML. Como no empieza con un prefijo como http:/ o file:/, el path es relativo a la localizaci�n del documento XML. �Recuerdas el m�todo setDocumentLocator? El analizador usa esta informaci�n para encontrar el documento DTD, al igual que nuestra aplicaci�n podr�a encontrar un fichero relativo al documento XML. Tambi�n se podr�a utilizar un identificador PUBLIC para especificar el fichero DTD usando un nombre �nico -- pero el analizador tendr�a que poder resolverlo.

La espeficaci�n DOCTYPE tambi�n podr�a contener definiciones DTD dentro del documento XML, en vez de referenciarlas a un fichero DTD externo. Dichas definiciones estar�an incluidas entre corchetes cuadrados, como esta.

<!DOCTYPE slideshow SYSTEM "slideshow1.dtd" [
  ...local subset definitions here...
]>

Nos aprovecharemos de esta facilidad m�s adelante cuando definamos algunas entidades que pueden usarse en un documento.