El API JAXP

Esta p�gina cubre algunas cosas que podemos usar cuando tomemos decisiones de dise�o XML.

�Ahorrarnos Alg�n Trabajo

Siempre que sea posible, usaremos un DTD existente. Es mucho m�s sencillo ignorar las cosas que no necesitamos que dise�ar todo desde el principio. Adem�s, al usar un DTD est�ndard hace posible el intercambio de datos, y puede ser posible usar datos en herramientas desarrolladas por otros.

Por eso, si existe un est�ndard de la industria, debemos considerar referenciar ese DTD con un par�metro de entidad externo. Un lugar para buscar DTDs est�ndards de la industria es el repositorio creado por la "Organization for the Advancement of Structured Information Standards (OASIS)" en http://www.XML.org. Otro lugar para chequear es "CommerceOne's XML Exchange" en http://www.xmlx.com, que se describe como "un repositorio para crear y compartir definiciones de tipos de documentos".

�Atributos y Elementos

Uno de los problemas que encontraremos m�s frecuentemente mientras dise�amos una estructura XML es modelar un �tem de dato dado como un subelemento o como un atributo de un elemento existente. Por ejemplo, podr�amos modelar el t�tulo de un deslizamiento como.

<slide>
  <title>This is the title</title>
</slide>

o como:

<slide title="This is the title">...</slide>

En algunos casos, las diferentes caracter�sticas de atributos y elementos hacen f�cil la elecci�n. Consideremos primero estos casos, y luego veremos casos donde la elecci�n es m�s ambigua.

�Elecci�n Forzada

Algunas veces, la elecci�n entre un atributo y un elemento se ve forzada por la naturaleza de los atributos y los elementos. Veamos algunas de estas consideraciones.

El dato contiene subestructuras: En este caso, el �tem de datos debe ser modelado como un elemento. No puede ser modelado como un atributo, porque los atributos s�lo toman strings sencillos. Por eso si el t�tulo puede contener texto enfatizado como este:The <em>Best</em> Choice, entonces puede ser un elemento.
El dato contiene m�ltiples l�neas: Aqu�, tambi�n tiene sentido usar un elemento. Los atributos necesitan ser sencillos, strings cortos o de otro modo no se pueden leer.
El dato cambia frecuentemente: Cuando el dato va a ser modificado frecuentemente, especialmente por el usuario final, tiene sentido modelarlo como un elemento. Los editores de XML tienden a hacer muy sencillo encontrar y modificar elementos de datos. Los atributos pueden ser m�s dif�ciles de conseguir, y por lo tanto m�s dif�ciles de modificar.
El dato es un string peque�o que raramente cambia: Este es el dato que puede ser modelado como un atributo. Sin embargo, s�lo porque pueda no quiere decir que se deba. Chequearemos la siguiente secci�n "Elecciones de estilo" para asegurarnos.
El dato est� confinado a un peque�o n�mero de elecciones fijas: Esta es una de las veces en que realmente tiene sentido usar un atributo. Usando el DTD, puede prevenirse que el atributo tome cualquier valor que no est� permitido. Un editor XML puede incluso proporcionar estas elecciones en una lista desplegable. El autor del documento XML no puede usar ning�n valor que no sea parte del DTD. Si en el futuro se quiere usar un nuevo valor, se tendr� que modificar el DTD antes de que el autor del documento pueda hacer uso de �l.

�Elecciones de Estilo

Frecuentemente las elecciones no son tan claras como hemos visto arriba. Cuando una elecci�n no est� forzada, necesitamos un sentido de "estilo" para guiarnos. La pregunta a responder es, qu� hace un buen estilo XML y por qu�.

Desafortunadamente, definir un sentido de estilo para XML es tan nebuloso como definir "estilo" cuando se habla de arte o m�sica. Sin embargo, tenemos unas cuantas formas de aproximarnos. El objetivo de esta secci�n es darnos algunos pensamientos �tiles sobre el sujeto "Estilo XML".

Visibilidad: Primero usaremos el concepto de visibilidad de los elementos XML y los atributos. Si se espera que el dato sea mostrado al usuario final - debe ser modelado como un elemento. Por otro lado, si la informaci�n gu�a el procesamiento XML pero nunca ser� mostrada, podr�a ser mejor modelarlo como un atributo.
Proveedor/Consumidor: Otra forma de pensar en la visibilidad es preguntarnos qui�n es el consumidor y/o productor de la informaci�n. Tambi�n podemos pensar en t�rminos de qui�n o qu� est� procesando la informaci�n.
Contenedor contra Contenido: Otra forma de pensar entre elementos y atributos es pensar en un elemento como un contenedor. Por analog�a, los contenidos del contenedor corresponden a los modelos de datos XML como elementos. Por otro lado, las caracter�sticas del contenedor corresponden a los modelos de datos XML como atributos. Un buen estilo XML ser�, de una forma consistente, la separaci�n de los contenidos de un contenedor de sus caracter�sticas.

�Normalizar Datos

En el tutorial de SAX, la secci�n Definir Atributos y Entidades en el DTD muestra como crear una entidad externa que podemos referenciar en un documento XML. Como una entidad tiene todas las ventajas de una rutina modularizada -- cambiar una copia afecta a todos los documentos que la referencian. El proceso de eliminar redundancias es conocido como normalizaci�n, por eso definir entidades es una buena forma de normalizar nuestros datos.

En un fichero HTML, la �nica forma de conseguir est� clase de modularidad es con enlaces HTML -- pero por supuesto entonces el documento esta fragmentado, y no completo. Por otro lado, las entidades XML, no sufren dicha fragmentaci�n. La entidad referenciada act�a como una macro -- el contenido de la entidad es expandido en su lugar, produciendo un documento completo. Y cuando la entidad est� definida como un fichero externo, m�ltiples documentos pueden referenciarlo.

Las consideraciones para definir una referencia de entidad, son pr�cticamente las mismas que usamos para modularizar el c�digo del programa.

Si nos encontramos escribiendo lo mismo m�s de una vez, debemos pensar en una entidad. Que nos permita escribirla en un lugar y referenciarla en muchos lugares.

Si la informaci�n va a cambiar, especialmente si se usa en m�s de un lugar, debemos pensar en una entidad.

Si la entidad nunca ser� referenciada desde fuera del fichero actual, la definiremos en el local_subset del DTD del documento, como definiriamos un m�todo o una clase interna en un programa.

Si la entidad va a ser referenciada desde m�ltiples documentos, debemos definirla como una entidad externa, de la misma forma que definir�amos una clase externa.

Las entidades externas producen XML modular que es m�s peque�o, m�s f�cil de actualizar y de mantener. Tambi�n pueden resultar documentos m�s dif�ciles de visualizar.

�Normalizar DTDs

Tambi�n podemos normalizar nuestras declaraciones DTD fabricando externamente piezas comunes y referenci�ndolas con un par�metro de entidad. Este proceso se describe en la secci�n de SAX en Definir Par�metros de Entidad.

Tambi�n podemos configurar DTDs condicionales, como se describe en la secci�n Secciones Condicionales del tutor de SAX. Si el n�mero y tama�o de las secciones condicionales es relativamente peque�o con respecto al tama�o del DTD completo, puede permitirnos una "sola fuente" un DTD que podemos usar para m�ltiples prop�sitos. Si el n�mero de secciones condicionales crece, el resultado puede ser un documento tan complejo que sea dif�cil de editar.