Diseñar una Estructura de Datos XML
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.
Tutoriales
