Embed Size (px)
Citation preview
SEP SEIT DGIT
CENTRO NACIONAL DE INVESTIGACI~N Y DESARROLLO TECNOL~GICO
cenidet
ANALIZADOR DE ESQUEMAS DE XML PARA SU TRADUCCIÓN A ESQUEMAS DE BDOO
~ T E S I S
QUE PARA OBTENER EL GRADO DE
MAESTRO EN CIENCIAS EN CIENCIAS COMPUTACONALES
PRESENTA : ALBERTO GARCÍA ESCAMILLA
DIRECTORES DE TESIS: M.C. MARIO GUILLÉN RODRÍGUEZ
DR. JOAQUÍN PÉREZ ORTE
0 3 - 0 2 3 0 CUERNAVACA, MOR. JUNIO DE 2003
Cuemavaca, Mor., a 30 de Mayo de 2003.
Dr. Gerard0 Reyes Salgado Presidente de la Academia de Ciencias Computacionales Presente
Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: Analizador de esquemas de XML para su traducción a esquemas de BDOO, realizada por ei(ia) C. Alberto García Escamilla, y habiendo realizado las correcciones que le fueron indicadas, acordarnos no tener objeción para que se le conceda la autorización de impresión de la tesis.
Sin otro particular, quedamos de usted.
Atentamente
La comisión de revisión de tesis
\ M.C. Juanhabriel González Sema
I) ,$qfJiu-q ( t-4. 6 “,IL*& - I / M.C. Mario Guillén Rodriguez
Director de tesis i54ictor J. Sosa Sosa
Dr. Joaauin Perez Orteaa - Codirector de tesis
C.C.P. Dr. Rodolfo A. Pazos Rangel, Jefe del Depto. de Ciencias Computacionales. Lic. Olivia Maquinay Díaz, Jefe del Depto. de Servicios Escolares. C. Alberto García Escamilla, alumno del programa de rnaestria.
INTERIOR INTERNADO PALMIRA SIN, COL, PALMIRA, A.P. 5-164. CP. 62490, CUERNAVACA. MOR. - MÉXICO TELS (777) 312 23 14.318 77 A I . FAX (777) 312 2434 EMAlL oazor~rd-cenidet.com.mx
Is"' " " ....I....... ~X?F!!~.*FI?vUC*N~ --.. ~ ~. _ _ . -. . .-.-. . .. . . .. .~ ,- . .
FORMULARIO c4 i+wcmr% rrcruxwW
AUTORIZACIÓN DE IMPRESIÓN DE TESIS
Cuemavaca, Mor., a 11 de abril de 2003.
C. Alberto García Escamilla Candidato al grado de Maestro en Ciencias en Ciencias Computacionales Presente
Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en relación a su trabajo de tesis: "Analizador de esquemas de XML para su traducción a esquemas de B.D.O.O.", me es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.
C.C.P. Lic. Olivia Maquinay Díaz, Jefe Depto. de Servicios Escolares.
INTERIOR INTERNADO PALMIRA S/N, COL, PALMIRA , A.P. 5-164. CP. 62490, CUERNAVACA, MOR. - MEXICO TELS. (777) 312 23 14,318 77 41. FAX (777) 312 24 34 EMAlL Dozor~sd-cenidef.com.mx
DEDICATORIA
A mis Padres:
Alberto Garcia Alvarado y Virginia Escamilla Martinez
A mis Abuelitos:
Ana Ma. Alvarado Espinosa y Francisco Cano Ramón (Q.E.P.D.)
A mi Hermano y familia:
Ricardo Garcia Escamilla, Eufemia Mejia Betaza y
Ricky Chuy
AGRADECIEMIENTOS A Dios
"...Pero no me dejes nunca, nunca, nunca, te lo pido por favor."
En el momento que logro alcanzar algún objetivo fijado, no puedo dejar de pensar que necesité ayuda para conseguirlo. Y en esta ocasión quiero aprovechar la oportunidad para hacer llegar mi agradecimiento a quienes de una u otra forma han hecho posible este logro. Mi más sincero agradecimiento:
A mi familia, porque siempre han confiado en mi y me han dado el apoyo para conquistar los retos que me he propuesto hasta ahora.
A los amigos y amigas que me aprecian, porque en este periodo de mi vida han estado conmigo demostrándome sin palabras que puedo contar con ellos.
A los compañeros del cenidet que buscaron mi amistad desinteresadamente, porque con ellos compartí momentos alegres, otros no tanto, pero todos de llenos de aprendizaje y crecimiento personal, además de vivir la experiencia de obtener un logro más en la vida que nos ha tocado vivir.
A mis profesores que demostraron ética y entrega a su trabajo, por compartir su conocimiento, experiencia y amistad.
AI personal del cenidet que muestra voluntad de servicio, por atenderme amablemente y con una sonrisa.
A mis revisores de tesis, por sus observaciones y comentarios, fundamentales para la realización de este trabajo.
A mi director y co-director de tesis, por su paciencia y entusiasmo para encausar mi esfuerzo hasta verlo materializarlo en este trabajo.
A COSNET y CEP, por el apoyo económico brindado, indispensable para mantenerme fuera de casa.
A mi tía Teresa, a Teresita y familia, a Tori0 y familia, por estar al pendiente y hacerme sentir cerca de la familia.
A Abril, por todas las vivencias de este tiempo, que sin duda alguna me transformaron en la persona que soy ahora.
Gracias a todos.
R E S U M E N
La Web brinda la facilidad de compartir datos entre computadoras sin importar en que parte del mundo se encuentren, sin embargo estos datos deben ser compartidos de forma rápida y eficiente. Aquí es donde entra el XML extensible Markup Language (Lenguaje de Marcado Extensible) que viene a proporcionar estructura a un almacén de información masivo como es la Web y con ello lograr nuevos niveles de automatización, lo que potencia nuevos tipos de aplicaciones de Web enfocadas a los datos.
LOS documentos XML están formados por dos archivos: el primero, que contiene los datos (con extensión .xmi) que es donde se encuentra la información y el segundo, que define la estructura que deben guardar los datos (con extensión .xsd), as¡ como sus tipos y restricciones que deben cumplir. Este archivo es opcional y es llamado esquema de XML.
Con el propósito de almacenar, organizar y recuperar grandes cantidades de documentos de XML, nacen los servidores de documentos de XML. Estos servidores almacenan los documentos de XML en forma nativa o utilizando una base de datos.
El almacenamiento en bases de datos de estos documentos de XML se puede realizar tanto en el modelo relaciona1 como en el modelo orientado a objetos. Para que una BDOO pueda almacenar información necesita que previamente se haya creado su esquema. El cual consiste en una declaración de clases donde se definen los objetos que se desean hacer persistentes. Para la creación del esquema de la base de datos, se requiere conocer la estructura del documento de XML, esta estructura se encuentra contenida en el esquema del documento de XML, por lo que se requiere hacer una transformación de XML a lenguaje Java.
Considerando los antecedentes arriba mencionados podemos determinar que la problemática de esta tesis es el mapeo entre cada uno de los elementos del esquema de XML y la declaración de clases en Java correspondientes.
Este trabajo de tesis describe cómo se construyó la herramienta que realiza la traducción del esquema de XML en un esquema de BDOO y detalla las dos fases de dicha herramienta, el analizador léxico-sintáctico y el traductor:
En analizador Léxico-Sintáctico se encarga de verificar que el archivo del esquema de XML cumpla con la sintaxis propuesta por la W3C. El traductor toma cada elemento del esquema de XML y genera una declaración de clase en Java equivalente y un archivo de configuración requerido por las bases de datos orientadas a objetos. En este archivo de configuración se definen las clases que serán persistentes y la relación entre clases.
Los servidores de documentos de XML podrán usar esta herramienta traductora y generar el esquema de la BDOO a partir un esquema de XML para que posteriormente almacenen los datos contenidos en los documentos de XML correspondientes al esquema traducido.
Tabla de Contenido .. 1 . Introduccion .............................................................................................. 1
1 .I. Antecedentes ..................................................................................... 2 1.1.1. XML ............................................................................................ 2 1 . 1 . 2. Servidor de documentos XML ...................................................... 3 1 . 1 . 3. Bases de Datos ........................................................................... 3
1.2. Definición del problema ...................................................................... 4 1.3. Solucion propuesta ............................................................................ 4
1.3.1. Objetivo general ......................................................................... 5 1.3.2. Objetivos particulares ................................................................. 5
1.4. Alcance y limitaciones ........................................................................ 5 1.5. Organización del documento .............................................................. 6
2 . Marco teorico ............................................................................................. 7 2.1. Lenguaje extensible de marcado (XML) ............................................... 8
2.1.1. Documentos de XML ................................................................. I O 2.1.2. Validez de documentos de XML ................................................ 11 2.1.3. Buena formación de documentos XML ....................................... 12 2.1.4. Tecnologías asociadas ............................................................. 12
2.1.4.1. Definición de tipo de documentos ..................................... 13 2.1.4.2. Esquema de XML ............................................................... 13 2.1.4.3. XSL ................................................................................... 14 2.1.4.4. Modelo de Objetos de Documento (DOM) ........................... 14 2.1.4.5. Lenguaje Extensible de Consultas (XQC) ............................ 14 2.1.4.6. Lenguaje de Enlaces Extensible (XLL) ............................... 15 2.1.4.7. Espacio de Nombres ......................................................... 15 2.1.4.8. Xpath ................................................................................ 16
2.2. Bases de datos orientadas a objetos ................................................. 16 2.2.1. Modelo de Objeto y el lenguaje Java .......................................... 16 2.2.2. Caracteristicas de B.D.O.0 ....................................................... 17
..
. .
2.2.3. Esquemas orientados a objetos ................................................ 22 2.2.4. Bases de datos orientadas a objetos vs . relacionales ................ 22
2.3. Data-binding ..................................................................................... 25 2.3.1. Definicion ................................................................................. 25 2.3.2. Data Binding de XML ................................................................. 25
2.4. Servidor de documentos XML ........................................................... 27
. . .
2.3.3. Data Binding entre esquema de XML y BOO0 ............................ 26
Estado del arte ......................................................................................... 29 3.1. Arquitectura de Java para Bindig XML (JAXB) ..................................... 30 3.2. Generador de código fuente CASTOR XML ........................................ 32
3 .
3 . 3 , ~ ~ ~ s ................................................................................................. 32
4 . Desarrollo de la herramienta traductora (Data binding) ............................ 34 4.1. Esquemas de XML .............................................................................. 35
4.2. Arquitectura de la herramienta .......................................................... 38 4.3. Analizador Léxico-Sintáctico .............................................................. 39
4.3.1. Javacc ...................................................................................... 40
4.1.1. Gramática de los esquemas de XML .......................................... 38
4.3.2. Funcionalidad ........................................................................... 41 4.4.Traductor .......................................................................................... 42
4.4.1. DOM ......................................................................................... 42 4.4.2. Archivo ptj ................................................................................ 43 4.4.3. Mapeo entre esquemas de XML y clases de Java ....................... 46 4.4.4. Funcionalidad ........................................................................... 50
4.5. Arquitectura de clases ....................................................................... 51 4.5.1 . La clase XMLage ....................................................................... 52 4.5.2. La clase XSDString ................................................................... 52 4.5.3. La clase xsd2java ..................................................................... 55
4.6. Implementación ................................................................................. 56 4.7. Análisis comparativo entre CASTOR XML y la herramienta desarrollada58
5 I! Casos de prueba ...................................................................................... 59 . 5.1. Objetivo de las pruebas ...................................................................... 60 5.2. Descripción de la prueba y resultado ................................................. 60
5.2.1. Prueba # 1 ................................................................................ 60 5.2.2. Prueba # 2 ................................................................................ 66 5.2.3. Prueba # 3 ................................................................................ 69 5.2.4. Prueba # 4 ................................................................................ 73 5.2.5. Prueba # 5 ................................................................................ 76
6 . Conclusiones ........................................................................................... 81
6.2. Beneficios .......................................................................................... 82 6.3. Resultados obtenidos ......................................................................... 82
6.1. Conclusiones generales ..................................................................... 82
6.4.Trabajos futuros ................................................................................. 83
7 . Anexos ..................................................................................................... 84 7.1. Listado de versiones existentes de los esquemas de XML ................... 84 7.2.Tokens de la gramática de los esquemas de XML ................................ 85 7.3. Reglas de la gramática de los esquemas de XML ................................ 86
I/
8 . Glosario ................................................................................................... 98 't 81
9 . Referencias ........................................................................................... 100
10. Bibliografía ............................................................................................ 103
I NTRODUCCI~N - ~ _--
Recientemente han surgido en internet servidores de documentos de XML cuya función es la publicación de documentos de XML así como su administración, almacenamiento y recuperación en una base de datos [6]. Esta tesis tiene como objetivo el desarrollo de una aplicación que genere el esquema para una base de datos orientada a objetos basándose en la estructura definida en los esquemas de XML. En el contenido de este documento se describe cómo tratar un esquema de XML para generar el código fuente que sirva como esquema para la base de datos.
I Introducción
1 1 .I. Antecedentes
Con la llegada de la Web (World Wide Web, www por sus siglas en inglés) se ha visto un enorme crecimiento en la cantidad de información disponible en Internet. La Web brinda la facilidad de compartir datos entre computadoras sin importar en qué parte del mundo se encuentren, sin embargo estos datos deben ser compartidos de forma rápida y eficiente. Aquí es donde entra el Lenguaje de Marcado Extensible (extensible Markup Language, XML por sus siglas en inglés) [24], que es el lenguaje propuesto por el consorcio de la web (World Wide Web Consortium, W3C por sus siglas en inglés) para estandarizar el intercambio de datos sobre la Web.
De igual forma la tecnología de bases de datos ha evolucionado desde los sistemas de archivos tradicionales hasta llegar en la actualidad a dar soporte a aplicaciones de Internet. Como resultado tenemos una fusión de información de datos estructurados que son almacenados y recuperados de una base de datos, para su posterior publicación o para su transmisión a otro sitio remoto en Internet.
Una aplicación actual de las bases de datos en el Internet, la encontramos en los servidores de documentos de XML cuya función principal es almacenar y recuperar documentos de XML y brindar facilidades para su administración.
1 .I .I. XML
El XML está surgiendo como un nuevo estándar para intercambiar información a través del Internet. Es un subconjunto del Lenguaje Estándar Generalizado de Marcado (Standard Generalized Markup Lenguaje, CGML por sus siglas en inglés) [28]. XML describe una clase de objetos que se le conoce como documento de XML. Estos documentos se almacenan en archivos de texto y están formados por:
Entidades.-Son los caracteres reservados por XML que indican una función específica dentro del documento de XML. CDATA.- Es un dato formado de caracteres y que no debe ser analizado por el procesador del documento de XML ya que es información del usuario.
o PCDATA _- Es un dato formado de caracteres que forma parte de la estructura del documento de XML y debe ser analizado por el procesador de documentos de XML.
Los documentos de XML se pueden clasificar en 2 tipos: documentos enfocados a datos (data-centric) y documentos enfocados a documentos (document-centric). Los enfocados a datos tienen una estructura regular y son homogéneos en su contenido y son empleados para aplicaciones Business to Business (B2B por sus siglas en inglés) y en transacciones comerciales, Los enfocados a documentos poseen una estructura irregular, con datos heterogéneos y se emplean en mensajes de e-mail, documentos XHTML y en documentos personalizados.
Una definición de tipo de documento (Document Type Definition, DTD por sus siglas en inglés) forma parte del estándaftde XML y su función es definir la estructura y los tipos de datos que debe tener el docume6to de XML. Esto con el fin de validar la forma de cómo se construye el documento de XML. En la actualidad los DTDs están siendo sustituidos por los esquemas de XML. Los esquemas de XML tienen la misma función que
2
I Introducción
los DTDs, sólo que ofrecen opciones adicionales como: más tipos de datos, mayor definición de restricciones para los datos y poseen la misma sintaxis de los documentos de XML.
1 .I .2. Servidores de documentos de XML
Un servidor de documentos de XML tiene como propósito almacenar, organizar y recuperar grandes cantidades de documentos de XML. Los tipos de documentos que un servidor de documentos de XML administra son los enfocados a los datos.
El almacenamiento de estos documentos de XML se puede realizar tanto en bases de datos del modelo relacional como del modelo orientado a objetos, sin embargo el modelo orientado a objetos simplifica enormemente el trabajo, ya que permite almacenar objetos directamente desde lenguajes de programación orientados a objetos. Un análisis comparativo se muestra en la sección 2.2.4. de este documento.
Esta investigación se encuentra ubicada en la línea de aplicaciones de tecnologías de XML, que se encuentran en desarrollo actualmente en el Centro Nacional de Investigación y Desarrollo Tecnológico (cenidet). Uno de los trabajos ya concluidos es la tesis que lleva por título: “Servidor de XML para aplicaciones de Web”desarrol1ada en el año 2002. En ella se detallan los elementos necesarios para construir un servidor de documentos de XML [ 6 ] . Este servidor emplea el conjunto de aplicaciones de POET (ahora Fast-Objects) para la administración de la BDOO.
1 .I .3. Bases de datos orientadas a objetos
La mayor parte de las investigaciones sobre bases de datos en los Últimos 30 años. se ha basado en el modelo relacional, el cual fue presentado por Ted Codd en 1969-1970. El modelo de datos relacional surgió con la intención de proporcionar un nivel de abstracción más alto para el usuario, de tal forma que ocultara la estructura de almacenamiento y se mostraran los datos únicamente como relaciones. Las consultas son expresadas en un lenguaje de alto nivel de abstracción que facilita el desarrollo de aplicaciones que utilizan estas bases de datos.
En la década de los 90s se generó mucho interés por las Bases de Datos Orientadas a Objetos (BDOO) las cuales resuelven algunos problemas de forma más eficiente que los sistemas de bases de datos relacionales, sobre todo los que involucran datos que deben respetar jerarquías. Estas bases de datos tienen su origen en los lenguajes de programación orientados a objetos y la idea fundamental es elevar aun más el nivel de abstracción de los problemas a resolver.
Aunque su implementación varía, dependiendo da cada área de aplicación, existen tres características que son constantes en la administración de una BDOO: El soporte para ejemplares de objetos y clases, encapsulamiento de operaciones con datos y especialización de objetos [14].
Para que una BDOO pueda almacenar información requiere que previamente exista su esquema. Dicho esquema consiste en una serie de declaraciones de clases donde se definen los objetos que se desean hacer persistentes en la BDOO. La definición
3
I Introducción
del esquema de la BDOO se realiza con un lenguaje de programación que respete el paradigma orientado a objetos como C++,'iJava o Small Talk.
1.2. Definición del problema
Antes de poder almacenar un documento de XML en una BDOO es necesario crear el esquema de la base de datos que corresponda con la estructura, restricciones y tipo de datos de los elementos del documento de XML a almacenar. Esta información está definida en la DTD o en el esquema de XML del mismo documento de XML, con esta información se podrá generar la declaración de clases que representen el esquema de la BDOO.
Considerando lo anterior se concluye que la problemática de este proyecto es el mapeo entre la definición de elementos contenida en la DTD o esquema de XML y la declaración de clases que servirá como esquema de la BDOO. Técnicamente a este tipo de mapeo se le denomina data binding [13].
Básicamente el data binding consiste en:
Representar datos y estructura en el formato natural para el lenguaje de programación elegido. Representar datos en una forma que describa exactamente su significado original. lmplementar los mecanismos Makhalling y Unmarshalling que consisten en la serialización y deserialización entre estructuras y ejemplares de objetos.
Definición de clases
Esquema de XML
Marshalling - Instancias XML de Objetos
Do cumento
Fig. l a . Data binding entre XML y el paradigma orientado a objetos
1.3. Solución propuesta
XML para tomar la definición del desarrollo de aplicaciones de Internet como el lenguaje a utilizar para la
i/ Dado que los DTDs cada vez son, menos usados se eligieron a los esquemas de Y debido a su popularidad para el
que ofrece para XML, se eligió a Java de clases para los esquemas de las
una herramienta que sirva como traductor
BDOOs.
En base a lo anterior se propone:.,crear I( del esquema del documento de XML a almacenar, mapeándolo a una declaración de
4
I Introducción
clases en Java para que posteriormente se pueda generar el esquema de la BDOO. Los objetivos que se persiguen con esta tesis se definen específicamente en dos partes: el objetivo general y los objetivos particulares.
1.3.1. Objetivo general
Desarrollar una herramienta que reciba un archivo de entrada con la descripción de un esquema de XML y sea capaz de generar como salida declaraciones de clases en lenguaje Java que sirvan como esquema de una BDOO que almacene documentos de XML.
1.3.2. Objetivos particulares
Construir un compilador de esquemas de XML. Generar código fuente en Java que contenga declaraciones de clases. Contribuir con la parte de almacenamiento de datos para la tesis "Servidor de XML para aplicaciones en W e b [ 6 ] .
1.4. Alcance y limitaciones
formal de los esquemas para XML presentada por la W3C el 2 de mayo de 2001. La herramienta acepta únicamente esquemas que cumplan con la descripción
Dada la magnitud de la gramática de los 'esquemas de XML, sólo se traduce un subconjunto representativo de dicha gramática, sin embargo el análisis sintáctico es realizado para todas las reglas de la gramática de los esquemas de XML.
El resultado de la traducción es únicamente la generación automática de clases en lenguaje Java, y no la generación física del esquema de la BDOO.
1.5. Organización del documento
Capitulo II En este capítulo se describen los temas: XML, data binding, BDOO y servidores de documentos de XML. La lectura de estos temas ayudará a comprender con mayor claridad la problemática planteada y la solución propuesta en esta tesis.
Capítulo 111 En este capítulo se analizan las herramientas existentes que realizan el data binding entre esquemas de XML y el modelo de objetos. Para este análisis sólo se consideraron tres herramientas, JAXB de SunMicrosystems [20], CASTOR de Exolab [5] y ZEUS de Hendirá (331.
Capítulo IV Este capítulo muestra detalle a detalle la manera como se construyó la herramienta de data-binding entre esquemas de XML y clases de Java. Se presenta un resumen de la descripción de los esquemas de XML de la W3C y también una breve introducción de utilería JavaCC y del modelo DOM. que fueron parte importante en el desarrollo de la herramienta.
Capítulo V Este capítulo contiene las descripciones de las pruebas realizadas con
5
I Introducción
diferentes tipos de esquemas de XML que se realizaron para comprobar la correcta creación de la declaración de clases que servirán para la obtención del esquema de la BDOO. Son cinco casos de prueba y en cada uno de ellos se explica brevemente el por qué del resultado.
Capítulo VI En este capitulo se exponen de manera resumida las funciones de la herramienta desarrollada, así como los beneficios que aporta, los resultados obtenidos y algunos trabajos futuros para continuar con la línea de XML y bases de datos.
Esta sección contiene el listado de versiones publicadas por el W3C de los esquemas de XML, los lexemas y reglas de la gramática de los esquemas de XML.
Anexos
It
6
MARCO TEÓRICO
En este capítulo se describen los temas: XML, data binding, bases de datos orientadas a objetos (BDOOs) y servidores de documentos de XML. La lectura de estos temas ayudará a comprender con mayor claridad la problemática planteada y la 'colución propuesta en esta tesis.
I1 Marco Teórico ‘I !j
2.1. Lenguaje Extensible de Marcado (XML)
XML es un subconjunto del Lenguaje Estandarizado y Generalizado para Marcado (SGML, por sus siglas en inglés), y es un lenguaje para expresar la estructura y el contenido en diferentes tipos de documentds electrónicos [ Z 41.
Pese a que XML y HTML son lenguajes de marcado existen grandes diferencias entre la función y los alcances de cada unb de ellos. Para establecer estas diferencias a continuación se analizan los dos lenguajes!
El Lenguaje de Marcado de Hipertexto (Hyper Text Markup Language, HTML por sus siglas en inglés) es el lenguaje de marcas de texto utilizado para la creación de páginas Web. Fue creado en 1986 tomanbo el concepto hipertexto y el estándar SGML
It If
II
1
[ Z ó ] : ir
El concepto hipertexto.- se refiere’ a la posibilidad de insertar en documentos elementos multimedia (gráficos, iknido, etc) además de enlaces a otros documentos.
lenguajes de marcas.
Uno de los objetivos que se alcanzolcon la creación del HTML, fue dar formato a la información existente en la Web presentándola de forma estructurada, agradable y con enlaces; esto se logra, especificando en el texto los diferentes efectos que se desea dar (especificar los lugares del documento don/le se debe poner cursiva, negrita, o un gráfico determinado). Otro objetivo alcanzado es que el código fuera entendible para las
HTML no es propiamente un lenguaje de programación y no presenta ningún compilador, en vez de ello existen programas especializados denominados navegadores (browsers) que interpretan y muestran los documentos de HTML. Los navegadores poseen la definición de HTML, gracias a ello pueden procesar documentos de HTML, interpretarlo y presentarlo en forma visual. Ii
El SGML.- es un estándar para tipos de documentos estructurados y
j
personas cuando lo leyeran. 11
1 I(
I f
XML surge como una respuesta a la necesidad de contar con un estándar para la transferencia de datos por Internet, ya que sólo existía HTML y SGML y ninguno de los dos se adaptaba a esa nueva necesidad. HTML fue creado para formatear información y no para estructurarla y tratar de agregarle esa nueva funcionalidad resultaba casi imposible además del riesgo que implicat3a modificar un estándar mundialmente usado. Por su parte, SGML padre del HTML era demasiado complejo para implementarlo en esta tarea. Por lo que en 1998 un grupo de trabajo del W3C presenta un subconjunto del SGML apoyado en una serie de tecnologías asociadas al cual denominan XML.
/I La descripción formal de XML que ;se tomó de referencia en este trabajo de tesis
se encuentra en la recomendación del 6 de octubre de 2000 elaborado por el w3c , donde se recopilan todos aquellos bocimientos necesarios sobre XML. La recomendación dice: “la especificación, junto con los estándares asociados (Unicode y IS0 10646 para caracteres, Internet RF/ 1766 para las rnarchs de identificación de lenguaje, IS0 639 para los códigos de nombre de lenguaje, IS0 3166 para los códigos de
!I
il I/
8 ’!
I1 Marco Teórico
nombre de país), proporcionan toda la información necesaria para entender XML versión 1 .O y construir programas de computadora que lo procesen” [ e ] .
La ventaja más importante de XML se refiere a su sencillez. XML es un formato que al igual que HTML y CGML está basado en caracteres y por lo tanto es comprensible para los seres humanos. Además, los documentos de XML pueden leerse fácilmente, crearse y modificarse por medio de herramientas comunes, como editores de texto. Otro ejemplo de sencillez de XML tiene que ver con su habilidad para representar datos estructurados en forma de árbol. Para muchas aplicaciones, una estructura en forma de árbol es lo suficientemente general y potente como para expresar datos con un cierto nivel de complejidad.
Es obvio que XML no sustituye a HTML ya que sus funciones son diferentes, más bien lo complementa. Mientras HTML se enfoca principalmente a dar formato al documento; por ejemplo: tipos de letra utilizados, tamaños, colores, etc. El XML se enfoca en describir el contenido de los datos, sin considerar el formato de la presentación de dichos datos.
Para ser más precisos con respecto a las capacidades de XML se listan cinco conceptos en donde es aplicada la tecnología XML:
Búsqueda de información.- Puesto que todo dato está debidamente rotulado con una etiqueta, se pueden hacer búsquedas entre un gran número de documentos sólo comparando el nombre de la etiqueta que delimita al dato, sin importar el idioma de este último.
Cambio de formato.- XML ofrece herramientas para transformar un documento de XML a diferentes formatos, como pueden ser: HTML, RTF, archivos de texto, XSL-FO, etc.
Persona1ización.- Con la ayuda de las tecnologías asociadas de XML se puede tener información filtrada y organizada de manera personalizada para cada usuario que realice consultas al documento de XML.
Información reutilizable.- Mediante el uso de hojas de estilo y sus procesadores se puede condensar, enriquecer o fusionar información de documentos de XML, para generar nuevos documentos de XML
Automatización.- XML brinda las herramientas necesarias, para automatizar procesos con la información de los documentos de XML, es decir, se desarrollan programas que trabajen con XML.
A continuación se listan ejemplos reales del uso de XML:
O
Aplicaciones de comercio electrónico.
Libros electrónicos. Dispositivos inalámbricos.
Mantenimiento de sitios Web grandes. Intercambio de información entre aplicaciones. Descargas y cargas desde una base de datos.
Aplicaciones para expresar fórmulas matemáticas científicas
9
I1 Marco Teórico
Cuando se habla de XML se hace referencia a la descripción formal emitida por la W3C así como a todas las tecnologías asociadas. AI archivo de texto con extensión . xml que contiene el código se le denomina docdmento de XML.
2.1 .I. Documentos de XML 1
Un documento de XML es muy similar a la forma de un documento de HTML O SGML. A continuación se muestra un ejemplo de un documento de XML sencillo:
1 <?XML version="l. O " ? > 2 <futbolistas> 3 <equipo nombre="cruz-azul"/> ., 4 < - ! Se escriben los nombres de los jugadores del equipo junto con s u
5 <nombre>Oscar <apodo>El cdnejo </apodo>Pérez </nombre> 6 <nombre>Sebastián <apodo>El loco </apodo>Abreu </nombre> 7 </futbolistas> /I
I1
apodo-->
Un documento de XML siempre comienza con la instrucción <?XML . . . ?> Con ella se indica que el documento de marcado es un documento de XML, también se puede indicar la versión utilizada.
Para este ejemplo no existe una definición de tipo de documento (DTD o esquema de XML), cuando exista se debe escribir la referencia en el segundo renglón del documento de XML, como se muestra a continuación:
Para esquema de XML:
Para DTD:
11 ifutbolistas schemaLocation="futbolistas.xsd">
i
<!DOCTYPE futbolistas SYSTEM "futbolistas.dtd"> II
Para utilizar elementos vacíos que no tienen contenido, en el ejemplo observamos el caso de <equipo nombre = "cruz azul"/> dónde sólo se le tiene que agregar una diagonal al final del nombre del elemento y antes de cerrar la etiqueta, para indicarle al procesador que no debe buscar la etiqueta final del elemento porque no tiene contenido.
Un documento de XML esta compuesto por marcas y contenido. Son seis las diferentes marcas que existen: elementos, referencias a entidades, comentarios, instrucciones de procesamiento, secciones marcadas y declaración de tipo de documento.
Elementos: Son las marcas más comunes y se delimitan por los signos menor que < y mayor que >, su objetivo es indicar la naturaleza del dato contenido. Algunos elementos pueden carecer de contenido, como en el ejemplo del elemento vacío arriba mencionado. Pero normalmente el dato contenido debe estar encerrado por las etiquetes de elemento: etiqueta de inicio <element> y etiqueta final </element>. Dentro de la misma etiqueta y después del nombre del elemento puede aparecer un atributo. Los atributos son pares conformados por nombre y , valor. En la línea 3 del ejemplo <equipo nombre="Cruz_azul"> se observa equipo que es el nombre del elemento, nombre es el
. n L U
I1 Marco Teórico
nombre del atributo y "Cruz - A z u l " es el valor del atributo. Todos los valores del atributo deben ir entre comillas.
Referencias a entidades: Para utilizar las marcas en un documento, algunos caracteres están reservados para identificar el comienzo de una marca. Por ejemplo: el signo menor que < indica el comienzo de una etiqueta. Para poder insertar uno de esos caracteres reservados como dato contenido se debe escribir con el carácter ampersand a su izquierda y punto y coma a la derecha sin espacio entre ellos, como se muestra: &<; .
Las entidades también son empleadas para referenciar texto de datos contenido, para usar esas referencias se utiliza la misma forma seiialada. Por ejemplo: &XML; para hacer referencia a una entidad identificada con la palabra XML.
Comentarios: Los comentarios inician con los símbolos < ! - y terminan con --> . En la línea 4 se muestra un ejemplo de comentario. Se puede escribir cualquier carácter en el comentario con excepción de la cadena "--". Un comentario puede ir en cualquier parte del documento y será ignorado por el procesador de XML.
Instrucciones de procesamiento: Se encargan de proporcionar información a la aplicación. A diferencia de los comentarios el procesador de XML si los analiza. Las instrucciones de prOCeSamient0 tienen la forma: <?nombre dato-ip?>. Donde nombre identifica la instrucción de procesamiento (IP) para que sea interpretada por la aplicación. Los otros datos de IP son opcionales y el procesador los ignorará. Los nombres de las IPS deben ser declarados como notaciones para formalizar su identificación. Los nombres de IPS que comiencen con XML están reservados.
Sección CDATA: En un documento, la sección CDATA no es analizada por el procesador pero su contenido sí es capturado como información. En una sección CDATA pueden existir caracteres como < y &. Por lo que esta sección debe escribirse de la siguiente forma:
< ! [ C D A T A [ caracteres de cualquier tipo I ] > La única cadena de caracteres que no es permitida en una sección CDATA es " I I >".
El procesador de XML tendrá 2 funciones primordiales, verificar la validez del documento de XML y su buena formación.
2.1.2. Validez de documentos de XML
El concepto de validez de un documento de XML se refiere a su conformidad o no con las restricciones de validez de la definición de tipo de documento (como se señala en los puntos 2.1.4.1. y 2.1.4.2.). Para comprobar la validez de un documento, éste debe incluir una declaración, donde se especifica el esquema de XML o la DTD al que debe adecuarse para que resulte válido. Consideremos los siguientes dos ejemplos:
con esquema de XML <SistemaMeteorologico schemaLocation="http://www.xweather.com/ReporteClima.xsd"~
con DTD <DOCTYPE SistemaMeteorologico SYSTEM http://www.xweather.com/ReporteClima.dtd>
11
0 3 - 0 2 3 0
I1 Marco Teórico
! Donde el URI corresponde a la ubicación de la definición del documento. Si no se
incluye esta declaración, el procesador de XML no realizará la comprobación de la validez. En este caso, se limitará a comprobar la buena formación del documento, que se define en el punto 2.1.3. I1
El procesador de XML es el encargado de leer el esquema de XML o la DTD del documento y de comprobar con ellos la validez del documento, de acuerdo con las restricciones de validez ahí definidas. 11
Normalmente, una aplicación necesita conocer todas las etiquetas que incluye el documento para procesarlas correctamente. Si aparece un elemento con un nombre de etiqueta desconocido, la aplicación no sabrá qué hacer con él. incluso si el nombre tiene sentido en el lenguaje humano. Por ejdmpio, cualquier persona que hable espaiiol entiende la etiqueta < f a c t u r a > , pero si ésta no es una palabra que esté declarada en el DTD o esquema de XML referenciado, el procesador de XML concluirá que ese documento de XML no es válido.
'!
Sin embargo, XML se diseño para analizar cualquier documento de XML sin tener que definir un esquema de XML o una DTD explícita. Cuando la DTD contenga entidades externas, es decir entidades definidas en una DTD específica, es obligatorio que el documento de XML contenga una declaración < ! DOCTYPE>.
2.1.3. Buena formación de documentos de XML
La buena formación de un documento de XML se refiere a su conformidad o no con las restricciones de buena formación definidas en la Recomendación 1 .O. Mientras que la validez tiene que ver con la estructura lógica de los elementos de un documento, la buena formación se centra en su estructura física, como la de correspondencia entre etiquetas. Por ejemplo, en XML cada etiqueta de inicio del tipo <tag>, debe tener su correspondiente etiqueta de fin, como < / t a g > . En caso contrario, la etiqueta se considerará una etiqueta vacía y deberá llevar una barra lateral al final como en < t a g / > .
Los documentos de XML que no estén bien formados son rechazados por el procesador de XML. Otras restricciones que determinan la buena formación de un documento se refieren a:
Los nombres de etiquetas deben ser Únicos dentro de un elemento. Los valores de etiquetas no deben contener el carácter "<".
Se debe tener en cuenta que un documento válido es siempre un documento bien formado, pero un documento bien formado no siempre es un documento válido. Por ejemplo, un documento bien formado puede contener etiquetas desconocidas y ser perfectamente comprensible, ya que no todas las etiquetas deben tener sentido en todas y cada una de las aplicaciones existentes.
2.1.4. Tecnologías asociadas
complementarias. A continuación se listan las más importantes: XML está soportado por un conjunto de tecnologías, todas relacionadas y
12
I1 Marco Teórico
Definición de Tipo de Documento (DTD, por sus siglas en inglés). Esquemas de XML (XML Schema). Lenguaje de estilo de hoja extensible (XSL por sus siglas en inglés) Modelo de Objeto de Documento (DOM por sus siglas en inglés). Lenguaje Extensible de Consultas (XQL por sus siglas en inglés). Lenguaje de Enlaces Extensible (XLINK y Xpointer). Espacio de Nombres (Name spaces). XPath.
En las siguientes secciones se describirán con más detalle cada una de estas tecnologías asociadas con XML.
2.1.4.1. Definición de tipo de documentos (DTD)
La definición de tipo de documento (DTD) [30] es un conjunto de reglas gramaticales en EBNF [ i ] , construidas a partir del vocabulario propio de las DTDs. La razón por la que las DTDs fueron creadas fue la necesidad de validar un documento de XML. La validación se realiza a través de un procesador de documentos de XML que comprueba que las definiciones expresadas en la DTD se cumplan en el documento de XML.
Una DTD define la secuencia y anidamiento que deben seguir los elementos, los tipos de los elementos, los atributos permitidos en un elemento, los valores permitidos por omisión, así como el tipo de dato para los atributos, los nombres de archivos externos que pueden ser referenciados, las entidades usadas y el elemento raíz del documento de XML.
Las definiciones antes mencionadas se logran con la combinación de cuatro declaraciones permitidas en un DTD:
Declaración de elementos.
Declaración de entidades. Declaración de notaciones.
Declaración de lista de atributos.
2.1.4.2. Esquema de XML
Es una especificación creada por el W3C para definir las reglas que deben cumplir los documentos de XML para ser considerados válidos [30]. Un esquema de XML tiene la misma función que los DTDs, con características que lo hacen más flexible y poderoso. Por ejemplo, en las DTDs el contenido del elemento está muy limitado a cadenas, mientras que en un esquema de XML se puede establecer el tipo de dato de los elementos a tipos más específicos, como enteros, fechas, etc. Los esquemas de XML también soportan características adicionales como la integración del espacio de nombres [27]. Otro aspecto importante de los esquemas es que están expresados en sintaxis de XML (evidentemente se debe conocer el vocabulario del esquema, llamado XML-Data). Un aspecto muy potente de los esquemas de XML es la forma que tienen de establecer el modelo de contenido de los elementos, más específicamente, el número de veces que se le permite a un elemento aparecer mientras está anidado. Los esquemas de XML se describen a detalle en el capítulo 4.
1 3
I1 Marco Teórico
I 1 I/
2.1.4.3. Lenguaje de Hojas de Estilo Extensible (XSL)
Las Hojas de Estilo Extensible (extensible Stylesheet Language, XCL por sus siglas en ingles) [ 2 5 ] se utilizan para dar fo'rmato a la información, es la forma de visualizar el contenido de los documentos de XML eh distintos formatos. A un mismo documento de XML se le pueden aplicar diferentes hojds de estilo e incluso se puede transformar un documento de XML en otro distinto. Se pbeden aplicar filtros a los datos para visualizar únicamente los que nos interesen. El lengdaje XSL dispone de condicionales y repetitivas.
2.1.4.4. Modelo de Objetos de Documento (DOM)
El DOM [ 2 3 ] es una plataforma y un lenguaje neutral que sirve de interfaz y permite que los programas puedan acceder y actbalizar la estructura y estilo de documentos de una manera estándar. El DOM fue disefíado en base al HTML y al XML. La interoperabilidad es necesaria para que.1 los documentos sean enviados a través de Internet
El DOM, a pesar de su nombre, np es un modelo de objetos como el Modelo de Objeto de Componentes (COM) [9] o Common Object Request Broker Architecture (CORBA) [11] que son lenguajes indepenbientes para especificar interfaces y objetos. El DOM es un conjunto de interfaces y objetos diseñados para manejar documentos en HTML y XML.
El W3C establece varios niveles de actuación, coincidiendo con el tiempo en que se presentan como recomendación: 1
Ij Nivel 1: Se refiere a la parte interna, y modelos para HTML y XML. Contiene
características para el análisis y la manipulación de documentos. Tiene dos partes: el núcleo o parte básica, referida a documentos de XML, y la parte HTML, referida precisamente a los documentos en HTML.!!
'I Nivel 2: Incluye un modelo de objetos e interfaz de acceso a las características de
estilo del documento, definiendo caractefísticas para manipular la información sobre el estilo del documento. También incluye un: modelo de eventos para soportar 10s espacios de nombres de XML y consultas enriquecidas.
Niveles posteriores se enfocan a especificar interfaces a sistemas de ventanas,
/I ii
/I
1
ii
manipulación de DTD y modelos de seguridad.
2.1.4.5. Lenguaje Extensible de Consultas (XQL)
Es un lenguaje de consultas a sistemas de bases de datos de documentos de XML [ io] . Una consulta XQL recibe uno o má! nodos de documentos de XML y devuelve un conjunto de nodos que están en un elemento raíz.
Una instrucción del XQL consta de un contexto de búsqueda, consulta y conjunto
I/
¡I I/ de resultados.
I1 14 ii
I1 Marco Teórico
El contexto de búsaueda debe ser un fragmento bien construido que contenga un nodo raíz, el cual debe contener todos los nodos en donde se va a realizar la búsqueda. La consulta es una cadena construida en función de la sintaxis del lenguaje XQL. Una cadena de consulta consta de:
calificadores/nodos de búsqueda [filtros]
El coniunto de resultados es un conjunto de nodos que se devuelven de la consulta. Aunque XQL no especifique la forma en que los nodos deben ser devueltos, la mayoría de las implementaciones los devuelven como documentos de XML bien formados. Sin embargo también podrían ser devueltos como nodeList de DOM, como un array bidimensional u otro formato.
2.1.4.6. Lenguaje de Enlaces Extensible (XLL)
El lenguaje de enlaces extensible tiene dos partes: XLink [29] y Xpointer [ 3 2 ] .
especifica recursos que pueden insertarse en un documento de XML para describir enlaces entre los distintos objetos. Con XLink, el creador de un documento de XML puede, entre otras cosas:
Definir un enlace bidireccional.
Asociar significados proporcionando un "papel" al enlace Definir un enlace que conecte más de dos recursos.
XPOINTER son enlaces bidireccionales que direccionan, no al documento completo, sino a una parte concreta dentro de éste.
XPointer permite hacer referencias a elementos concretos, cadenas de caracteres y a otras partes específicas de los documentos de XML.. tanto si soportan o no de forma explícita un atributo ID. El ejemplo siguiente es una Combinación de un URL y de un XPointer, y se refiere al séptimo hijo del tercer elemento SECTION incluido bajo el elemento raíz:
http://www.foo.com/bar.html#root().child(3,SECTION) .child(7)
2.1.4.7. Espacio de Nombres
Un espacio de nombres XML (Namespace) [ 2 7 ] es una colección de nombres, identificados por un URI, utilizada en los documentos de XML como tipos de elemento y nombres de atributo.
Los nombres de los espacios de nombres XML aparecen en los documentos de XML como nombres calificados, los cuales contienen el carácter "dos puntos", separando el nombre en un prefijo de espacio de nombres y su parte local. Con el prefijo S e selecciona un espacio de nombres, mediante el mapeo a un URI. La combinación de los URIs de espacios de nombres universalmente gestionados y el espacio de nombres propio del documento produce identificadores que garantizan la unicidad universal.
15
I1 Marco Teórico
Como los URIs pueden contener caracteres no permitidos en los nombres, no pueden ser utilizados directamente en el cuerpo de un documento de XML en lugar de los prefijos. El prefijo del espacio de nombres sirye como proxy para el URI. El software que soporte esta propuesta de espacios de nombres debe reconocer e interpretar estas declaraciones y prefijos.
2.1.4.8. XPath
XPath [31] es un lenguaje de expresión que se usa para dirigirse a partes de un documento de XML, pero que no se implementa como vocabulario de XML. Esto se debe a que las expresiones de XPath se utilizan en situaciones en las que el marcado de XML no es aplicado, como los valores de los atribhtos. XPath proporciona una forma.abstracta de dirigirse a las paries de los documentos dk XML, y forma la base del direccionamiento de documentos en XSLT. El nombre XPath se basa en la idea del uso de una notación de ruta para dirigirse a documentos de XML. ,,
AI igual que XSLT, XPath funciona bajo la suposición de que un documento ha sido analizado sintácticamente en un árbol de nodos. Define varios tipos de nodos, que se utilizan para describir los nodos que aparecen en un árbol. Siempre hay un nodo raiz único y todos los elementos de un documento tienen su coirespondiente nodo de elemento que aparece en el árbol bajo el nodo raíz. Dentro de un nodo de elementos hay otros tipos de nodos, que corresponden al contenido del elemento. Los nodos de elementos pueden tener un identificador Único asociado a ellos,,que se usa para hacer referencia al nodo con XPath. XSLT utiliza XPath como base para recorrer un documento de XML y llegar a un nodo determinado.
2.2. Bases de datos orientadas a objetos
Normalmente, el término orientado a objetos se usa para referirse colectivamente a un conjunto de mecanismos de modelado cemántico para capturar información de una aplicación. Un modelo orientado a 0bjetos"debe proveer mecanismos de abstracción para el modelado de comportamiento de objetos en aplicaciones reales.
2.2.1. Modelo orientado a objetos y el lenguaje Java
El Grupo de Administración de Bases de Datos Orientadas a Objetos (Object Database Management Group, ODMG por sus siglas en inglés) fÚe fundado en 1991. Su intención fue crear un conjunto de especificaciones que pudieian definir cómo hacer persistentes a los objetos de las aplicaciones escritas en un lenguaje orientado objetos en una base de datos. Las especificaciones ,del ODMG describen estructuras de objetos que les proporcionan a las bases de datos, el esquema, un lenguaje de consulta de objetos y un lenguaje que servirá como intermediario para los tres lenguajes de programación orientado a objetos más populares: C++,' SmallTalk y Java. De esta manera se ha logrado que en la versión ODMG 3.0, una bask de datos que respete las especificaciones de ODMG y que sea creada con cualquiera de estos tres lenguajes puede ser entendida y administrada por cualquiera de los otrosdos.
Una BDOO, a diferencia de una 'base datos relacional, es capaz de almacenar los datos en la propia estructura del objeto, una base de datos relacional lo hace en campos y renglones.
I1 Marco Teórico
El modelo de objetos del ODMG contiene conceptos que son familiares para los programadores de Java. El ODMG reconoce métodos y propiedades de los objetos, esas propiedades pueden ser primitivas u objetos. Y aunque el ODMG reconoce métodos de objeto no los puede ni almacenar ni recuperar, sólo se consideran en la definición de clases de objeto. Es decir el ODMG ve a la base de datos como un almacén de propiedades de objetos y los métodos están en el programa de aplicación.
Con respecto a la relación entre objetos, reconoce múltiples relaciones de herencia entre clases de objetos padre e hijo.
2.2.1 .I. Literales y estructuras
El componente más simple de un objeto son las literales. Lo que en Java es conocido como tipos de datos primitivos, entre los que se encuentran: integer, short, char, byfe entre otros. Mapear literales a tipos de datos en Java no es perfecto, ya que de acuerdo a las normas del ODMG existen tipos de datos que no existen en el lenguaje Java. Un ejemplo puede ser las literales numéricas sin signo definidas por el ODMG. este tipo de dato no existe en Java por lo que es mapeado a un tipo numérico con signo.
También el ODMG define tipos de datos estructurados, los cuales no existen en Java pero sí en C++, la solución para Java seria crear una clase sin métodos que sea equivalente a la literal estructurada.
La siguiente tabla muestra el mapeo entre tipos de datos especificados por el modelo de objeto del ODMG y su equivalente en Java.
OTiDos del Modelo I Tipos de Java II
Tabla 2a. Relacidn entre variables del modelo de objetos y del lenguaje Java
17
I1 Marco Teórico
2.2.1.2. Colección de objetos
Una colección de objetos fue definida ,por el ODMG como un objeto que contiene otros objetos donde todos son del mismo tipo o descienden de la misma clase base. Son utilizadas para almacenar grupos de objetos q'ue representan cosas similares. Han sido definidos cinco tipos de colección de objetos:
Set. Bag. List. Array. Dictionary.
Un obieto Set es una colección de elementos lirrepetibles y sin ningún orden. Los métodos de los objetos tipo set incluyen operaciones de conjuntos como son unión, intersección y diferencias entre grupos. Las interfaces usadas para este tipo de colección de objetos son: Dset, Dbag, DArray y Dmap. I!
Un obieto Bag es parecido a un objeto set, la única diferencia radica en que si permite elementos duplicados, es decir soporta los métodos de unión. intersección y diferencias al igual que el objeto set, pero no utiliza los métodos de validación. La interfaz usada para este tipo de colección de objetos es BagOfObject.
Un obieto List es una colección ordenada de elementos muy similar a un array que puede crecer y contraerse. Los miembros del objeto List pueden ser accesados por un indice, pero necesitan un método para atiadir elementos al principio o final de la lista. A diferencia de un array cuando se inserta un elemento no necesariamente sobre escribe al elemento en la posición indicada, mas bien se crea una nueva posición y la lista se expande, de igual forma cuando se elimina un elemento, la lista se contrae.
Un obieto Array del ODMG funciona muy parecido a un array de cualquier lenguaje de programación. Es una colección de un número definido de celdas en las cuales se pueden colocar y remover elementos. Las celdas soh referidas por sus índices El objeto Array definido por el ODMG es de una sola dimension.
1)
Un Dictionary es una colección desordenada de parejas de elementos, donde un elemento es el nombre y el otro el valor, y ambos son considerados como un mismo objeto. El nombre es considerado el identificador y no se puede repetir. Todos los nombres en un diccionario forman los índices de búsqueda.
2.2.2. Características de una BDOO
Entre las características más importantes de una BDOO se encuentran las siguientes:
Manejo de objetos complejos. Constructores de tipo.
Creación de versiones. ,I
Objetos e identidad de los objetos. Jerarquía de tipos, herencia y encapsulamiento.
Compatibilidad con lenguajes de progi;amación.
1 18
I1 Marco Teórico
2.2.2.1. Identidad de objetos
Un sistema de BDOO provee una identidad Única a cada objeto independiente almacenado en la base de datos. Esta identidad Única suele implementarse con un identificador de objeto único u OID, generado por el sistema. El valor de un OID no es visible para el usuario externo, sino que el sistema lo utiliza a nivel interno para identificar cada objeto de manera única y para crear y manejar las referencias entre objetos.
La principal propiedad que debe tener un OID es la de ser inmutable; es decir, el valor del OID para un objeto en particular nunca debe cambiar. Esto preserva la identidad del objeto del mundo real que se está presentando. También es preferible que cada OID se utilice sólo una vez; es decir aunque un objeto se elimine de la base de datos, su OID no se deberá asignar a otro objeto. Estas dos propiedades implican que el OID no debe depender del valor de ningún atributo del objeto, pues estos valores pueden cambiar. También suele considerarse inapropiado basar el OID en la dirección física del objeto en el almacenamiento, ya que una reorganización de los objetos de la base de datos podría cambiar los OIDs. Sin embargo, algunos sistemas sí usan la dirección física como OID para aumentar la eficiencia en el acceso a los objetos. Si la dirección física cambia, puede colocarse un apuntador indirecto en la dirección anterior, dando la nueva ubicación física del objeto. Un sistema de BDOO debe contar con algún mecanismo para generar los OlDs con la propiedad de inmutabilidad.
Los objetos tienen identidades únicas, independientes de los valores de sus atributos. La estructura orientada a objetos automáticamente impone: dominio, llave integridad de entidad e integridad referencial.
2.2.2.2. Jerarquía de tipos, herencia y encapsulamiento
Los esquemas de BDOO suelen necesitar un gran número de clases. Sin embargo, varias clases son parecidas entre si. Para permitir la representación directa de parecidos entre las clases, hay que ubicarlas en una jerarquía de especializaciones. El concepto de jerarquía de' clases es parecido al de especialización del modelo Entidad- Relación Extendida. Las especializaciones de las clases son denominadas subclases; lo cual especifica atributos y métodos adicionales para una clase existente. Los objetos creados por medio de una subclases heredan todos los atributos y métodos de la clase padre. Algunas de estas caracteristicas heredadas pueden ellas mismas haber sido heredadas de clases más altas en la jerarquía. Ejemplo:
Class periona 1 string nombre; string dirección;
1 ;
C l a s s cliente isa persona i int interésgrestamo;
t ;
Class empleado isa personal date fecha-de-alta; int sueldo;
) ;
19
I1 Marco Teórico
Class secretaria isa empleado i int velocidad; int horas-trabajadas
I ; 'I
Los valores asociados con objetos en una BDOO pueden ser accedidos únicamente por operaciones específicas predefinidas las cuales implementan sus caracteristicas de comportamiento (métodos). Por lo que los usuarios no se deben preocupar por la implementación de los detahes, sino mas bien por la funcionalidad. Esto incrementa el nivel de independencia de datos de las aplicaciones.
11
2.2.2.3. Manejo de objetos complejos '!
Los objetos se consideran complejos porque requieren un área de almacenamiento sustancial y no forman parte de los tipos de datos básicos que suelen ofrecer los SMBDs. Puesto que el tamario de los objetos es considerable, un SMBD podría obtener una porción del objeto y proporcionarla al programa de aplicación antes de obtener todo el objeto. El SMBD podría también usar técnicas de almacenamiento intermedio y caché para obtener por anticipado porciones del objeto, antes de que el programa de aplicación necesite tener acceso a ellas.
En un SMBDOO. esto puede lograrse definiendo un nuevo tipo de datos abstracto para los objetos no interpretados y suministrando metodos para seleccionar, comparar y exhibir tales objetos.
Como un SMBDOO permite a los usuarios crear nuevos tipos, y como un tipo incluye tanto estructura como operaciones'! podemos considerar que un SMBDOO tiene un sistema de tipos extensibles. Podemos crear bibliotecas de nuevos tipos definiendo su estructura y operaciones, incluso con tipos complejos.
Muchos SMBDOOs pueden almacenar y obtener objetos no estructurados extensos en forma de cadenas de caracteres o de bits, que se pueden pasar "tal cual" al programa de aplicación para que los interprete.
I¡
estructurados. '!
2.2.2.4. Constructores de tipo .:
En las BDOOs, los valores (o estados) de los objetos complejos se pueden construir a partir de otros objetos mediante ciertos constructores de tipos. Una forma de representar tales objetos es considerar a cada objeto como tripleta (i, c, v). donde i es un identificador de objeto único (el OID), c es'un constructor (esto es, una indicación de cómo se construye el valor del objeto) y v es el valor (o estado) del objeto. Puede haber varios constructores, según el modelo de datos y el sistema OO.
Los tres constructores básicos son: Constructores de átomos. constructores de tuplas. constructores de conjuntos.
Es posible almacenar y manipular objetos complejos tanto estructurados como no
20 .. . .. .
': , . ,y . . . . .
I1 Marco Teórico
Otros constructores de uso más común son los de listas y de arreglos. También existe un dominio D que contiene todos los valores atómicos básicos que están disponibles directamente en el sistema. Por lo regular éstos incluyen los enteros, los números reales, las cadenas de caracteres, los tipos boléanos, las fechas y cualesquiera otros tipos de datos que el sistema maneje directamente.
2.2.2.5. Compatibilidad con lenguajes de programación
El enfoque que se sigue cuando se utilizan los diagramas de Entidad-Relación, es modelar los datos y después convertirlos de manera manual en un conjunto de relaciones; en cambio en la programación orientada a objetos simplemente son diseñados y codificados para trabajar con una base de datos. Hay varios lenguajes donde es posible integrar estos conceptos. Una ejemplo es extender un lenguaje para el tratamiento de datos como el SQL añadiendo tipos complejos y la programación orientada a objetos. Los sistemas que proporcionan extensiones orientadas a objetos a los sistemas relacionales se denominan sistemas relacionales orientados a objetos.
Otra opción es tomar un lenguaje de programación orientado a objetos ya existente y extenderlo para que trabaje con las bases de datos. Estos lenguajes se denominan lenguajes de programación persistentes. Estos lenguajes permiten a los programadores trabajar directamente con los datos, desde el lenguaje de programación; sin tener que pasar por un lenguaje para el tratamiento de datos como SQL. Se denominan persistentes porque los datos siguen existiendo una vez que el programa que los creó ha concluido.
A la hora de decidir que opción utilizar se debe tener en cuenta que los Lenguajes Persistentes suelen ser potentes y resulta relativamente sencillo cometer errores de programación que dañen las bases de datos. La complejidad de los lenguajes hace que la optimización automática de alto nivel, como la reducción de E/S de disco, resulte difícil. En muchas aplicaciones, la posibilidad de las consultas declarativas es de gran importancia, pero los lenguajes persistentes no permiten actualmente las consultas declarativas sin que aparezcan problemas de algún tipo.
2.2.2.6. Creación de versiones
Por lo regular, se aplican actividades de mantenimiento a un sistema de software conforme sus requerimientos evolucionan. El mantenimiento implica modificar algunos de los módulos de diseño y de implementación. Si el sistema ya está en operación, y si es preciso modificar uno o más módulos, el diseñador deberá crear una nueva versión de cada uno de ellos para efectuar cambios.
Cabe señalar que puede haber más de dos versiones de un objeto. En caso que se requieran dos versiones, además del módulo original. Se puede actualizar concurrentemente las propias versiones del mismo módulo del software. Esto se llama ingeniería concurrente. Sin embargo, siempre llega el momento en que es preciso combinar (fusionar) estas dos versiones para que la versión híbrida incluya los cambios realizados, Es necesario que sus cambios sean compatibles.
21
CENTRO DE lNFORMAflON SEP CENIDET I
I1 Marco Teórico
I!
Un objeto complejo, como un sistema de software, puede constar de muchos módulos. Cuando se permite la creación de múltiples versiones, es posible que cada uno de esos módulos tenga varias versiones distintas y un grafo de versiones.
y controlar múltiples versiones del mismo objeto.
2.2.3. Esquemas orientados a objetos
En base de datos un esquema:
Como se deduce del análisis anterior, un SMBDOO debe ser capaz de almacenar
'1
Valida los valores introducidos. Define los objetos, sus relaciones, estructura y tipos de dato.
Restringe campos obligatorios o vacíós.
Deben contener no sólo las propiedades de la estructura de una aplicación del mundo real sino también las propiedades de su comportamiento.
la lista de los métodos y la interfaze de cada categoria. Un esquema de un SMBDOO es un esquema semántico binario, donde se definen
Métodos. En el paradigma orientado a objetos es posible predefinir una biblioteca de operaciones (procedimientos y funciones) para un esquema dado. Esas operaciones son llamadas métodos y son la base para modelar las características de comportamiento de una aplicación del mundo real. Existen métodos de objetos y métodos de categorias:
Los métodos de objetos pueden ser procedimientos o funciones que actúan directamente sobre los objetos y pertenecen a una categoría, Los métodos de categorías son un caso especial de los métodos de objetos donde éstos actúan sobre un objeto que funciona como categoría.
2.2.4 Bases de datos orientadas a objetos vs. relacionales
Las BDOOs y las relaciones son de naturaleza y caracteristicas diferentes. En la Tabla 26. se muestran los requerimientos de los documentos de XML y las caracteristicas que ofrecen las BDOOs y las BD relacionales [15].
ll
I
Bases .de Datos Orientadas a Objetos
Las bases de datos orientadas a objetos son construidas a partir de una estructura jerárquica, no normalizan los datos, éstos son almacenados en un formato nativo enriquecido.' Debido a esto es posible la herencia, polimorfismo Y otras capacidades propias orientadas a objetos. Las bases de datos orientadas a obietos almacenan los
Requerimientos Bases de datos Relacionales
Las bases de datos relacionales no tienen soporte para nombramiento jerárquico, requieren de una normalización o uniformización de los datos. Este proceso limita la funcionalidad de los datos. Cualquier mecanismo de nombramiento jerárquico debe ser construido sobre la base de datos relacional. Las bases de datos relacionales por su
XML utiliza nombramiento jerárquico de elementos. I Manejo complejo de vinculos.
I1 Marco Teórico
SU format0 nativo, incluyendo todos SUS vínculos. Cuando se realiza la recuperación de un objeto, se recuperan todos los vínculos asociados a ese Dbjeto, haciendo que el manejo 3e estos vínculos sea muy simple. Las bases de datos orientadas 3 objetos almacenan los Dbjetos en un formato nativo unto con todos sus vinculos. 2omo resultado de esto, las >ases de datos orientadas a 3bjetos mantienen una ?structura jerárquica en árbol, )or lo que al recorrer estos iínculos mejora el rendimiento I la escalabilidad. -as bases de datos orientadas 3 objetos pueden almacenar xalquier tipo de dato, formato, ongitud, etc., y esto no xesenta ningún problema Jorque la base de datos no .rata de encajar el dato a algún 'ormato fijo, simplemente almacena el objeto o elemento de XML en su formato nativo.
Las bases de datos orientadas a objetos son capaces de almacenar metadatos en su formato nativo, a pesar de la estructura y manteniendo los vínculos a 10s datos originales.
Ya que las bases de datos orientadas a objetos almacenan 10s datos en su formato nativo, pueden manipular los datos a través de funciones como
:ML introduce una vinculación de manejar estos enlaces dentro de la base de datos poi si misma, y para poder realizar este manejo se tendría que implementar en una capa superior de la B.D. relacional.
Aunque el soporte para el nombramiento jerhrquico puede ser implementado sobre la base de datos relacional, realizar esto requiere de mucho trabajo. Sólo se puede recorrer por profundidad, y esto se realiza a través de reuniones, por esta razón es una solución lenta y no escalable. Una base de datos relacional almacena datos en campos fijos, esto requiere una longitud y formato fijo. y si lo hace en un campo BLOB, incrementa la flexibilidad a manejar varios tipos de datos, pero reduce la utilidad de los datos porque no puede ser consultada o procesada sin un gran gasto de memoria y procesamiento. Una base de datos relacional fue diseñada sólo para mantener una cantidad muy limitada de datos acerca del archivo (como el autor, fecha de creación y tipo de archivo). Esto no es suficientemente flexible para manejar 10s metadatos complejos utilizados con XML.
Una base de datos relaciona! almacena todo COmO un BLOB, por lo que es incapaz de realizar consultas, indexar o realizar búsquedas dentro de
ompleja (XLL), que incluye inculos bidireccionales y inculos uno a muchos.
favegación jerárquica del rbol.
a navegación rápida de los odos o vínculos del árbol es pltica para el almacenamiento scalable de documentos de ML.
oporte para una longitud viable de datos y formato.
os datos almacenados deben er capaces de manejar los atos de muy diversas laneras.
fetadatos
os metadatos son datos que on asociados al archivo. Esto s importante para ED1 Electronic Data Interchange) 'orque los metadatos ontienen información eferente al archivo, el nombre le la compañía que lo envía, !tC. 3úsquedas completas sobre exto/ consultas.
lebe ser posible realizar iúsquedas y consultas sobre os datos EDI.
Soporte para abstracción de
oojetos o elemenroc de XML en I arquitectura no son caoacesi
consultas, búsquedas sobre el los archivos. texto completo, indexado, ordenación, etc. Esta flexibilidad es critica cuando se
2 3
ii Marco Teórico
La capacidad para abstraer los datos es imperativa al implementar reglas globales a través de los datos.
Integración con lenguajes orientados a objetos
Los lenguajes orientados a objetos están ganando popularidad. Java en particular está especialmente diseñado para Internet. La integración con estos leguajes es muy necesaria.
Control de Versiones
ED1 toma datos XML y adiciona y manipula los datos en su progreso a través del flujo de trabajo de la compañia. Mantener el control de versiones de la información es critico para implementar sistemas que rastrean y reportan lo referente a la ruta y el proceso de la información.
>emite el desarrollo de aplicaciones que permiten aplicar reglas a conjuntos diversos de datos en una manera genérica. Estas reglas se pueden aplicar globalmente o dependiendo de los niveles de granularidad, permitidos por
3bsrracción de: dalos. Esto I sopone para a atisrracción de datos. Esto representa un2 seria deficiencia al usar ED1 con datos XML.
a objetos manejan el control de versiones de una manera muy eficiente. Las bases de datos orientadas a objetos mantienen punteros independientes del nombre o versión de los objetos. Como resultado de esto, la base de datos puede almacenar diferentes versiones de los datos de una manera inteligente, sin corromper los datos o vinculos entre los diferentes elementos de un
el objeto. I Las bases de datos orientadas I Los lenguajes orientados é
relacionales no fueroi diseñadas para mantene control de versiones, y pari implementar el control di versiones se tiene que realiza sobre la base de datos, en li lógica de la aplicación.
a objetos proveen una integración superior con los lenguajes orientados a objetos. Debido a que una base de datos orientada a objetos almacena ,,los objetos nativamente, no hay necesidad de crear un puente entre los objetos y el mundo relacional como se requiere con las bases
objetos son utilizados par¿ crear objetos complejos, lo: cuales deben se uniformizados o normalizado: y mapeados dentro de la! bases de datos relacionales.
de datos relacionales. I Las bases de datos orientadas 1 Las bases de dato!
Tabla 26. Requerimientos de XML y características ofrecidas por una 61300 y una base de datos relacional.
2.3. Data binding
"Data Binding" es una tecnología que automatiza el mapeo entre un modelo de datos y un modelo específico para un programa de computadora, es decir realiza la conversión de estructuras generales a específicas.
2.3.1. Definición de data binding
Data Bindinq es el proceso de analizar los datos que se encuentran en un formato dado y representarlos con un lenguaje de programación específico que sea capaz de describir el formato original de esos datos, permitiendo:
,
24
I1 Marco Teórico
datos Y estructura en el formato natural para el lenguaje de Programación que se haya elegido. Representar datos en una forma que describa exactamente SU significado original, Hacer transparente al programador la manera de cómo se almacenan 10s datos,
2.3.2. Data binding de XML
XML está siendo usado para describir modelos de datos, los cuales posteriormente tendrán que ser accedidos mediante modelos específicos de objetos; a través de las técnicas de data binding se puede realizar esta conversión, permitiendo a los programadores manipular la información en un lenguaje de programación conservando el sentido del modelo original.
Data Binding de XML consiste en analizar la estructura de un documento de XML y generar una estructura de datos que represente dicha estructura en un lenguaje de programación orientado a objetos.
Empleando las técnicas de data binding de XML se simplifica el desarrollo de aplicaciones que requieran interactuar con documentos de XML, ya que el programador no tendrá la necesidad de aprender los mecanismos para el manejo de las estructuras de XML (como lo son las APIs de SAX y DOM).
Otra ventaja de usar técnicas de data binding de XML es que ofrece una manera de acceder al significado de los datos, mientras que las APIs SAX y DOM sólo ofrecen la manipulación de la estructura de los documentos de XML.
lnteractuar con un modelo de datos que representa el contenido de XML como objetos, estructuras de datos y tipos primitivos nativos para el lenguaje de programación, hace que programar con XML sea más natural y menos tedioso, con código más legible Y mantenible.
LOS mecanismos que se emplean en la técnica de data binding de XML son
Marshalling.- consiste en convertir un objeto a un flujo de datos. Unmarshallinq.- consiste en convertir un flujo de datos a un objeto.
Marshalling y Unmarshalling: . . <?xml version="l .O?> <invoice>
<item> <name> coca cola lata
</item> ...
... </invoice>
Unmarshalling Items : lternn
petltemí) : itemll
Marshalling name="coca cola
Ejemplar de XML Ejemplar del modelo de objetos
Fig. 2a. Mecanismos marshalling y onmarshalling
2 5
.
11 Marco Teórico
Como se aprecia en la fig. 2a. el mecanismo "marshalling" Permite crear documentos de XML a partir de uno de 10s ejemplares de una estructura de datos Y el mecanismo de "unmarshalling" generará ejemplares de nuevas estructuras de EmNXdo a la estructura del documento de XML
2.3.3. Data binding entre esquemas de XML y BDOO
El modelo de objetos de datos contiene la estructura y los tipos de datos de un documento de XML y es representado por medio de Java Beans [7]. Una de las aplicaciones de este modelo de objetos de datos es para la definición del esquema de una BDOO.
Las definiciones de los esquemas de XML son traducidas a clases de Java, estas clases no necesariamente deben tener funcionalidad, sólo la definición de la clase con sus propiedades miembro.
Una ventaja de hacer data binding a partir de un esquema de XML es que cuando se requieran cambiar politicas de restricciones de datos, sólo se deberán realizar en el esquema y automáticamente se generará el código para validar el contenido de los datos.
Recientemente se han desarrollado una gran cantidad de herramientas que llevan a cabo el data binding entre esquemas de XML y BDOO. En este documento sólo se listarán tres de los más representativos y mejor fundamentados:
t
1)
JAXB de Sun Microsytems li
CASTOR de Exolab ZEUS de Enhydra
Las tres herramientas se describirán a detalle en el capitulo 3.
2.4. Servidores de XML
Los servidores de XML son plataformas para almacenar, recuperar y administrar datos en forma de documentos de XML ?ara y desde aplicaciones distribuidas, como el comercio electrónico y aplicaciones empresa-empresa. Generalmente contienen ambientes de desarrollo de aplicaciones y proveen acceso a los datos y gran variedad de bases de datos, incluyendo bases de datos legadas, mensajes de correo electrónico y sistemas de archivos.
Los servidores de XML proveeo plataformas para construir aplicaciones de comercio electrónico y otros tipos de aplicaciones distribuidas, y no son estrictamente bases de datos, aunque obviamente !pueden ser utilizados para el desarrollo de aplicaciones. Los servidores de Web habilitados para XML generalmente pueden publicar datos en el Web como XML, pero éstos no pueden recibir datos desde el Web como XML. Usualmente pueden acceder a gran variedad de bases de datos y conectarlas al Web. Algunos de los productos más representativos de este grupo se describen a continuación:
Datachannel Server 141 Es un ambiente de trabajo para publicar eficientemente. manejar y recuperar información. Este producto incluye:
2 6
I1 Marco Teórico
Búsquedas sobre metacontenidos.
nativo de XML Para almacenar datos como etiquetas de XML. Arquitectura Jerárquica Para trabajar con XML de forma más efectiva que los sistemas de bases de datos relacionales. Soporte nativo en Web Para acceder a datos a través de protocolos estándares de Web. Habilidad para almacenar metadatos, contenidos y consultas como objetos de XML.
Un intérprete de consultas de XQL y una interfaz HTTP.
Rhvihmyx 1121 Un servidor basado en Windows para proveer documentos de XML y HTML a servidores de Web y otras aplicaciones. El servidor Rhytmyx es un servidor de datos XML que traduce fácilmente a documentos de Web, disponibles como documentos en HTML o documentos nativos en XML. El servidor soporta operaciones de consulta y actualizaciones entre documentos de Web y datos back-end. Estos documentos de Web dinámicos son generados por el servidor Rhytmyx en tiempo real, de acuerdo a un mapeo especificado externamente en la herramienta Rhytmyx Workbench.
El Rhytmyx Workbench es una'interfaz gráfica para diseno. Ésta se usa para definir documentos de Web dinámicos para ser utilizados por el servidor Rhytmyx. Cada colección de estos documentos de Web dinámicos y su mapeo constituye una aplicación Rhythmyx. El servidor tiene una herramienta de administración por medio de apliquetes. Tiene la habilidad de iniciar o detener una gran variedad de funciones en el servidor.
Tamino 1171 Este software está basado en un núcleo extremadamente rápido y pequeño que permite procesar nativamente XML; esta tecnología se llama X-machine. Tamino es la primera base de datos que permite almacenar directamente, integrar e intercambiar datos XML. Esto garantiza un alto rendimiento y escalabilidad sin tener capas extras de comunicación para los datos y los documentos de XML.
Tamin0 acepta objetos de XML como entrada y Ofrece objetos de XML como salida. Provee también la administración interactiva de múltiples bases de datos ocal les Y remotas a través de un visualizador de Web.
XML Portal Server (XPS) 1161 La funcionalidad del XPS puede dividirse en dos servicios: El servidor de Aplicaciones XML (XAS) y el Servidor de Entrega de Contenidos (CDS). El XAS provee una arquitectura para desarrollar portales interactivos de comercio electrónico. El XAS utiliza una capa de XML para enviar y recibir mensajes además de tareas para y desde otras aplicaciones. Los mensajes son delegados a agentes especializados y agentes que trabajan con el ambiente del Servidor de Transacciones de Microsoft (MTS). Trabajando con el MTS, el XPS garantiza el éxito de una transacción o el proceso de deshacer la operación realizada
El CDS es el responsable de la interacción y proceso del usuario final en el servidor portal. Maneja el acceso a todas las fuentes de contenidos de datos, como el envio (basado en el agente de envío de contenidos), operando junto con el XAS o comunicándose directamente con una aplicación de producción, el Web, o ambientes de
27
~~_ ~ _ _ _ _ _
I1 Marco Teórico
publicación/autoría (Office, Staroffice, etc.). Los datos son enviados a traves del CDS.XPS, que permite agregar contenido desde cualquier aplicación o sitio de Web.
XPS colecciona y agrega contenidos por medio de dos mecanismos: arañas inteligentes (spiders) y agentes de envío de contenidos. Las arañas navegan por los sistemas de archivos locales y de red, sitios de FTP, sistemas de correo, y una gran cantidad de aplicaciones indexando metadatos, contenikios o ambos. El XPS reconoce e indexa inteligentemente más de 40 formatos de archivos. Los agentes de envio de contenido proveen una interfaz de Web integrada para"las aplicaciones de negocios más populares, manejadores de contenidos, group ware, teniendo las ventajas de los servidores basados en Web y proveedores de contenido,
28
ESTADO DEL ARTE
En este capítulo se analizan las herramientas existentes que realizan data binding entre esquemas de XML y el modelo de objetos. Para este análisis sólo se consideraron tres herramientas, JAXB de SunMicrosyctems, CASTOR de Exolab y ZEUS de Enhydra. La razón por la que se eligieron estas tres herramientas fue por sus conceptos bien fundamentados, porque son las más representativas y porque son de código abierto. Aquí podremos observar que las tres herramientas trabajan de manera muy parecida y que sus diferencias son minimas.
111 Estado del arte
3.1. Arquitectura de Java para binding de XML (JAXB)
(Java Architecture for XML Binding, JAXB por SUS Siglas en inglés) Provee una API Y una herramienta que automatiza el mapeo entre documentos de XML Y objetos de Java [zi].
JAXB proporciona a los desarrolladores de Java un estándar y una manera eficiente para realizar el mapeo entre XML y código en Java. Una de las ventajas de usar JAXB es que no se requiere ser experto ,en XML para desarrollar aplicaciones que involucren esta tecnología, además permite el ahorro de código.
La mayor ventaja de trabajar con JAXB es el alto nivel de abstracción para manipular un documento de XML. Otras características de JAXB son listadas a continuación [ig]:
Validación de datos: Una aplicación de JAXB respeta la definición de las DTDs y esquemas de XML, los cuales no permiten la creación de objetos de Java inválidos. Velocidad: Gracias a la velocidad del modelo por eventos de SAX (Simple API for XML). los mecanismos de binding de las aplicaciones de JAXB son suficientemente rápidos. Facilidad de uso: El compilador de JAXB, libera al desarrollador de escribir y revisar manualmente la conversión de código, también le permite escribir aplicaciones que accedan a los datos de un documento de XML a través de interfaces de Java sin tener que preocuparse por la estructura de los datos en XML. Conversión de datos: Los datos de los documentos de XML son convertidos a tipos de datos de Java. Personalizar: El esquema de binding puede ser personalizado dependiendo de las necesidades de la aplicación.
Gracias a estas características JAXB es considerada una poderosa herramienta para desarrollar aplicaciones con diversas funcionalidades en Java. Concretamente JAXB se puede usar en:
Manipulación de datos en memoria. Manipulación de datos válidos de acuerdo a una DTD. Generación de código basado en una OTO. Manipulación de objetos de Java que representan datos de XML. Acceso a los datos de múltiples documentos de XML. Manipulación de un fragmento de un extenso documento de XML con ayuda de la API de SAX. Manipulación de datos de un documento de XML no muy grande con la ayuda de la API de DOM. Transformación de un documento de XML a otro. Edición de código generado a partir de DTDs mal definidas y documentos de XML inválidos. I/
Reutilización de código para documentos de XML con diferentes DTDs.
30
I11 Estado del arte
A partir de diciembre de 2002 Se encuentra disponible la versión 0.75 de JMB, la cual soporta parcialmente et binding de tos esquemas de XML del w3c , para definir la estructura de los documentos de XML, tal como lo realizan 10s productos CASTOR y ZEUS.
Hacer binding a un esquema significa generar un conjunto de clases de Java que al esquema. J M B provee una herramienta llamada cornpilador binding, el
Toda aplicación de JAXB debe proporcionar un conjunto de herramientas para el
El paquete javax.xml.bind, que contiene clases e interfaces para realizar
cual vincula al esquema y puede ser invocado desde un javascript [ 2 0 ] .
binding. Este conjunto de herramientas está compuesto por tres paquetes:
operaciones como unmarshalling, marshalling y validaciones. El paquete javax.xml.bind.uti1, que contiene clases con utilerias. El paquete javax.xml.bind.helper, diseñado para proveer implementaciones de JAXB.
Hacer unrnarshalling a un documento de XML significa crear un árbol de objetos que representen el contenido y la organización del documento de XML. Hay que estar concientes que este árbol de contenidos no es un árbol basado en DOM, incluso los árboles generados por JAXB son más eficientes en el uso de la memoria que los basados en DOM. Estos objetos son ejemplares de las clases producidas por el compilador binding. Para realizar unmarshalling de un documento de XML se debe crear un objeto JAXBContext, que es una lista de uno o más nombres de paquetes que contienen interfaces generadas por el compilador binding. JAXB permite unmarshall una combinación de elementos XML que corresponden a diferentes esquemas. El objeto Unmarshaller controla los procesos de unmarshalling mediante métodos propios.
Marshalling es lo contrario de unmarshalling, significa crear un documento de XML a partir de un árbol de objetos. Para hacer marshalling a un árbol también se debe crear Un objeto JAXBContext y especificar el paquete que contiene las clases e interfaces para el esquema vinculado. También se permiten múltiples paquetes para construir un documento de XML a partir de múltiples elementos de datos. El objeto Marshailer controla los procesos de marshalling mediante métodos propios. Para el caso de marshalling la validación del árbol no es parte del proceso marshalling, Por 10 que se debe empleando una clase del conjunto de herramientas de binding.
En resumen, las características que se incluyen en esta versión reciente son:
Soporte para un subconjunto de los esquemas de XML del W3C y Namespaces XML. Mayor flexibilidad en las funciones de unmarshalling y marshalling. Acceder, actualizar y validar los datos de los objetos en Java considerando las restricciones de los esquemas.
Sin embargo estas características han sido duramente criticadas [22] ya que es un primer intento y existen varias "limitaciones", por ejemplo: Se asume por default que el documento de XML posee un esquema, se asume que el esquema cumple con la
31
I11 Estado del arte
recomendación del W3C y se asume que el documento de XML es válido en base a SU esquema.
3.2. Generador de código fuente CASTOR XML
Castor es un proyecto patrocinado por Exolab.org [5] y es una herramienta que realiza Data binding de XML; está programado en el lenguaje Java y utiliza las APlS de SAX para realizar el marshallinglunmarsalling
Para representar el modelo de datos.de un documento de XML en memoria, los programadores necesitan escribir mucho código para lograr la descripción de la estructura y los datos de los documentos de XML, todo esto proporcionado por el esquema de XML.
I1
Este proceso es fácil cuando sólo hay que mapear un dato tipo string o boolean, ya que existe un tipo exactamente igual en el lenguaje orientado a objetos, pero cuando hay que describir una estructura más compleja por ejemplo un tipo interno del esquema de XML, puede ser un trabajo tedioso y complejo el proceso de mapeo. CASTOR emplea un archivo extra que se denomina Class Descriptor, el cual es usado por el marshalling para obtener información de las clases generadas.
El generador de código fuente CASTOR XML provee el código necesario para describir ejemplares de XML, incluyendo propiedades y métodos de acceso.
//
Un objeto es un ejemplar de su clase, de la misma manera que un documento de XML es un ejemplar de su esquema. Por ello el resultado de la generación de código es una declaración de clases porque se parte de un esquema de XML. Castor en su versión 0.9.3.21 de septiembre de 2002, ya sopoha la descripción formal de los esquemas de XML emitida por el W3C.
Castor tiene diferentes metodologías de data binding: Data binding automático usando intbospección.
Data binding basado en esquemas de XML con generación completa de código fuente.
Castor obtiene información de los ,métodos de una clase dada a través de la API Java Reflection por lo que el orden en que los métodos son obtenidos por Castor, dependen de esta API.
Data binding personalizado.
3.3. Zeus
Zeus [33] es una herramienta de data binding de XML de código abierto, creada por Hendira, que provee la posibilidad de tomar cualquier documento de XML y convertirlo en objetos de Java que representen los datos y la estructura del documento de XML.
Estos objetos de Java pueden ser usados y manipulados como cualquier otro objeto de Java por la máquina virtual, después de esto Zeus puede convertir nuevamente los objetos de Java en documentos de XML.
. .. .
32
I11 Estado del arte
Zeus basa SU utilidad en el bajo nivel en el que trabajan las Apls existentes de XML como SAX, DOM Y JDOM, Y ofrece este alto nivel ocultando la complejidad del manejo de XML.
El núcleo del proceso de conversión entre XML y Java es un grupo de restricciones. Estas restricciones especifican cómo se debe formar un documento de XML así como su contenido semántico y deben poder ser representadas en cualquiera de los dos estándares permitidos para documentos de XML. DTDs o esquemas de XML. Zeus puede generar clases de Java que representen cualquier documento de XML que cumpla con las restricciones presentadas. Esto quiere decir que se pueden generar clases y escribir código antes de tiempo, y estar seguro que trabajará perfectamente con cualquier documento de XML que cumpla con las restricciones de los archivos de definición.
Zeus crea un grupo de bindings genéricos de las definiciones, tales como DTDs, esquemas o algún otro mecanismo de definiciones. Esto lo hace diferente de las demás herramientas de su tipo, ya que éstas hacen el binding a las clases, directamente del archivo de definición.
El primer paso para usar la herramienta de data-binding Zeus es construir el archivo de definición para el documento de XML.
Actualmente Zeus sólo soporta las definiciones DTDs, las cuales son tomadas Por la herramienta de generación de código fuente de Zeus y obtener como resultado un conjunto de archivos de código fuente en Java que después de ser compilados resultan en archivos de clases de Java. Esas clases son la representación de las estructuras de datos de 10s documentos de XML y son usadas en programas en Java Para su manipulación.
33
Desarrollo de la herramienta traductora (Data binding)
Este capitulo muestra detalle a detalle la manera como se construyó la herramienta de data binding entre esquemas de XML y clases de Java. Se presenta un resumen de la descripción de los esquemas de XML de la W3C y también una breve introducción de la utileria Javacc y del modelo DOM, que fueron parte importante en el desarrollo de la herramienta.
I V Desarrollo de l a herramienta traductora
4.1. Esquemas de XML
En el pasado existieron muchos fabricantes que tenían SU propio lenguaje de esquemas de XML, pero paulatinamente fueron abandonándolos y cambiando hacia el estándar del w3c . Sin embargo, a la fecha aún sobreviven dos de esos lenguajes de
de XML: Relax Y Schematron. El primero es un estándar de is0 y es menos complejo que el lenguaje propuesto por la W3C, aunque también menos popular; el segundo está basado en XPath y permite construir estructuras más complejas que las que pueden construirse con el lenguaje del W3c.
El lenguaje de esquema de XML del W3C fue desarrollado por un grupo de trabajo del W3C, es un estándar de código abierto. La especificación de los esquemas es más compleja y más grande que la misma especificación de XML 1 .O.
Antes que existieran los esquemas de XML, los documentos de XML eran validados usando una DTD, el documento de XML debía indicar en la declaración del tipo de documento, qué DTD iba a usar para su validación. Debido a lo limitado de las DTDs, éstas fueron remplazados por los esquemas de XML.
Mejoras de los esquemas de XML respecto a los DTDs:
Más tipos de Datos.- 44 contralo, además de poder crear tipos de datos propios. Cumplen con la sintaxis de los documentos de XML.- No se requiere aprender otra nueva sintaxis. Es orientado a objetos.- Se puede extender un tipo o restringirlo (derivando nuevos tipos basado en uno existente). Pueden expresar grupos de elementos- Un elemento puede tener elementos hijos sin que tengan que cumplir una secuencia. . pueden especificar elementos contenedores- Con un nombre repetible 0 irrepetible se podrá acceder al grupo de elementos. Pueden definir elementos con contenido nulo.
Un esquema tiene un vocabulario propio, que se puede Personalizar Para definir otro, a estos vocabularios se les da un nombre que 10s identifique (namespace).
elementFormDefaUlt="qu
. . . </xsd:schema>
I I
Fig. 4a. Atributos del elemento schema.
3 5
IV Desarrollo de la herramienta traductora
Los esquemas de XML clasifican sus elementos en complexType y simpleType. Los complexType contienen atributos y poseen elementos hijos. Los simpleType no tienen atributos y contienen un elemento simple de tipo integer, date, decimal, etc. con opción a delimitar el rango de valores permitidos.
I1
complexTvpe Con el complexType se define un nuevo tipo de elemento formado por un grupo de elementos. esto Dermite a los esauemas de XML definir elementos de tipo complejo. Existen tres tipos diferentes de grupos de elementos:
all.- Requiere que de todos los elementos que pertenecen al grupo, al menos uno debe estar presente en el documento de XML y no importa el orden en que se escriban los elementos. !I choice.- Indica que sólo uno de los elementos del grupo debe aparecer en el documento de XML. sequence.- Requiere que cada uno de los elementos aparezca en el documento de XML y que conserven el mismo orden especificado en el grupo.
Los complexType pueden ser anónimos (sin nombre) o pueden tener un nombre, esto se consigue asignándole un valor al atributo name, la ventaja de usar complexType con nombre es que pueden ser usados por más de un elemento.
En el siguiente ejemplo se muestran dos fragmentos de esquemas de XML equivalentes con complexType, uno con nombre y el otro sin nombre.
li
<xsd: element name="A"> <xsd:cornplexType>
<xsd:element liname="B'r /> <xsd:element name="C" />
</xsd:sequence> </xsd:complexType>
Fig. 4b. CornpiexType sin atributo name
<xsd : element name="Ai" type=" f 00" / \ <xsd: complexType name="foo"> 4
<xsd:sequence> <xsd:element name="B" ... /> <xsd: element name="C" ... />
</xsd:sequence> !i </xsd:complexType>
Fig. 4c. CornpiexType con atributo name. I1
36
I .. . - .. ,% .-
IV Desarrollo de la herramienta traductora
<xsd:complerType>
</xsd:complexType </xsd:element>
Fig. 4d. Elemento con ComplexType y atributo type a la vez.
simDleTvpe Con el simpleType también se define un nuevo tipo de elemento el cual tendrá como base un tipo ya definido por los esquemas de XML. El simpleType redefinirá esa base mediante uno o más de los modificadores existentes denominados facets.
Los tipos definidos en los esquemas de XML son los siguientes: . O . . . O . . .
string boolean de c i m a I float double duration dateTime time date gYearMonth
gYear gMonthDay
gMonth hexBinary base64Binary anyURl QName NOTATION
gDay
Los facets (atributos o aspectos) disponibles para una base tipo "string" son seis:
length minLength
0 maxLength pattern enumeration whitespace (legal values: preserve, replace, collapse)
A continuación se explica un ejemplo de un simpleType con base "string":
<xsd : simpl.eType name="TelephoneNumber"> <xsd: restriction base="xsd: string">
<xsd: length value="ü"/> <xsd:pattern value="\dí 3 I -\dí 4 I " / >
</xsd:restriction> </xsd:simpleType>
Fig. 4e. Declamción de un elemento simpleType.
37
IV Desarrollo de la herramienta traductora
~
<rsd:simpleType name= "Ear thSUTfaceEleva t ion" , <xsd: restriction base="xsd: integer">
<xsd:minInclusive value="-1290"/> <xsd:maxInclusive value-"290351/>
</xsd:restriction> </xsd:simpleType>
J
-
Los facets disponibles para una base tipo "integer" son ocho:
totalDigits pattern whitespace enumeration maxlnclusive maxExclusive minlnclusive minExclusive
A continuación se explica un ejemplo de un 'simpleType con base "integer":
4.1 .I. Gramática de los esquemas de XML
Uno de los objetivos particulares de esta tesis es construir un analizador Iéxico- sintáctico. Para el desarrollo de esta hekamienta se dedujeron las reglas gramaticales que definen un esquema de XML. Estas reglas no se encontraban explícitamente en los tres documentos del W3C antes mencionados. Por lo que fue necesario deducirlas y escribirlas en alguna notación existente, esa notación fue EBNF en la cual se escribieron todas las reglas gramaticales de los esquemas de XML del W3C.
En total la gramática de los esquemas de XML del W3C quedó representada por 93 lexemas y 81 reglas gramaticales. La mayoría de los lexemas se obtuvieron de otras dos recomendaciones del W3C una es Extensible Markup Language (XML) 1.0 (Second Edition) W3C Recommendation 6 October 2000 y la otra es Namespaces in XML REC- xml-names-I 99901 14. Dichas recomendaciones también están referenciadas desde la recomendación de los esquemas de XML. Los Anexos B y C muestran la gramática de los esquemas de XML en EBNF.
?
38
IV Desarrollo de la herramienta traductora
4.2. Arquitectura de la herramienta
El desarrollo de la herramienta estuvo dividido en dos fases: Un analizador léxico-sintáctico que se encarga de verificar que el archivo del esquema de XML cumple con la sintaxis propuesta por la W3C.
Y un traductor que toma cada elemento del esquema de XML y genera una declaración de clase en Java equivalente a la estructura del esquema de XML; además genera un archivo de configuración requerido por las bases de datos orientadas a objetos. En este archivo de configuración se definen las clases que serán persistentes y la relación entre clases.
Fig. 49. Arquitectura del generador de esquemas de BDOO
4.3. Analizador léxico-sintáctico
Para obtener un esquema de BDOO válido, es necesario asegurarse que el esquema de XML cumple con las reglas gramaticales propuestas por la W3C, ya que un esquema mal construido generaría errores al momento de traducirlo a la declaración de clases en Java. Por esta razón es importante tener la certeza que el esquema de XML no ~~
tenga errores léxico-sintácticos,
La construcción de este analizador se realizó con la ayuda de la herramienta JavaCC de WebGain [13]. En primer lugar se creó un archivo de texto donde se escribieron todas las reglas gramaticales de los esquemas de XML, pero con la sintaxis propia de JavaCC
39
IV Desarrollo de la herramienta traductora
4.3.1. Javacc 'I
Javacc (java compiler compiler) es un generador de analizadores IéxiCO-SintáCtiCOS 'para Java, equivalente a lex & yacc para lenguaje C. Javacc genera un parser top-down (recursivo descendente) lo contrario al parse\ bottom-up generado por yacc [3] .
Javacc es un compilador que procesa archivos de código fuente especial para obtener el código fuente en Java. Los archivos que compila llevan la extensión .jj y cuentan con 3 secciones: I/
Definición de lexemas terminales: Q ~ e son palabras esperadas como entradas, Reglas: Indican la combinación permitida de lexemas para formar instrucciones legales (producciones) en el lenguaje. Código en Java: Para realizar acciones cuando ocurra alguna producción.
Los archivos de entrada en su parte inicial tienen una sección de opciones para configurar el tipo de analizador a generar. Una de esas opciones puede ser no distinguir entre letras minúsculas y mayúsculas. En la segunda parte se pueden agregar subrutinas en Java y escribir el método main del analizador a generar. La Última parte del archivo contiene las definiciones de lexemas y producciones.
Javacc trabaja con la versión 1.1 de Java o superior y la versión que fue utilizada para este trabajo fue la versión 2.0, donde las especificaciones Iéxicas tales como expresiones regulares, cadenas, etc. y la: especificaciones de la gramática (el BNF) se escriben juntas en el mismo archivo
Javacc cuenta con una herramienta denominada jjtree el cual acepta un archivo de entrada con una lista de lexemas y las reglas gramaticales del lenguaje a analizar. Esta herramienta arroja como resultado un archivo .jj con la sintaxis de javacc listo para ser compilado por javacc. '1
I
xsd.jjt Node.java TokenMgrErrorj ava Simp1eNode.java ParseException.java JJTegl Stakjava. Token.java xsdtreeconstantsjava xsd.jj xsdConstants.java
ASCI1CharStream.java
xsdTokenManager.java rsd.java
Fig. 4h. Diagrama de flujo y generación de archivos de Javacc
11
Cuando se compilan tanto el archivo jjt por el jjtree y el archivo .jj por javacc, se generan unos archivos extras. Ellos no dependen de la gramática sólo contienen clases que ayudarán al funcionamiento de analizador.
40
.l
- 1
I ...
IV Desarrollo de la herramienta traductora
Con los comandos propios de jjTree y Javacc se procesó la gramática obtenida de la especificación del W3C y se obtuvo una serie de archivos fuente en lenguaje Java agrupados en un paquete (package). Como siguiente paso se compilaron estos archivos con Java y se obtuvo el analizador léxico-sintáctico,
Fig. 4i. Diseno del módulo analizador léxico-sintáctico
4.3.2. Funcionalidad
El analizador léxico-sintáctico recibe como parámetro el archivo que contiene el esquema de XML. Como se mencionó anteriormente Javacc genera analizadores bottom- up por lo que el analizador léxico-sintáctico construirá un árbol para realizar el análisis. Una vez concluido el análisis, si no existen errores, continuará el Traductor, tomará el esquema de XML para procesarlo y obtener el código en Java, de lo contrario enviará a pantalla un mensaje de error de sintaxis, indicando dónde fue detectado y detendrá la ejecución del proceso.
Fig. 4j. Diagrama de flujo del módulo analizador léxico-sintáctico.
41
IV Desarrollo de la herramienta traductora
4.4. Traductor
Una vez que el esquema de XML 'fue analizado y se comprobó que no tiene errores de sintaxis podrá ser analizado por el traductor para obtener la declaración de clases en Java.
El traductor utiliza la API de DOM para acceder a los nodos del árbol que representa el esquema de XML. Cuando localiza un elemento que es de tipo complejo genera un archivo de texto con el nombre del elemento y la extensión .java y cada uno de los elementos de ese tipo complejo van a ser las variables miembro de la clase.
4.4.1. Modelo de Objetos de Documento (DOM) 11
El DOM es un lenguaje independiente para especificar interfaces y objetos. Se encuentra organizado en clases y su función principal es ayudarle a las aplicaciones a acceder y manipular la estructura de documentos de XML [ 2 3 ] .
DOM genera una estructura en memoria de tipo árbol, la cual es una representación de la estructura del documento de XML. Cada etiqueta del documento de XML es un nodo en el árbol . La manipulación del árbol, así como el acceso a los nodos, el añadirlos y eliminarlos está dado por las clases de la API.
corder> <hook>
</book> ... I ,
..
</order>
Fig. 4k. Generación de estnicturas de árbol usando el método document builder de la API DOM.
Las aplicaciones que usan DOM crean un documento modelo de objetos de sólo- lectura ya que no posee mecanismos de escritura, sin embargo una vez que está construido el árbol DOM se pueden realizar las siguientes acciones mediante un simple comando:
Adicionar elementos. Eliminar elementos. Cambiarlos de posición. Cambiar su contenido.
En el proyecto Apache XML existe un tópico llamado Xerces [ z ] , el cual provee clases para analizar y generar documentbs de XML. Estas clases están disponibles para Java y C++ e implementan el estándar DOM (nivel 1 y 2) de la W3C, y el estándar de facto SAX (version 2).
4 2
IV Desarrollo de la herramienta traductora
4.4.2. Archivo ptj
Para confirmar la validez de la declaración de clases generadas por la herramienta, se utilizó SMBDOO llamado FastObjects. El SMBDOO FastObjects requiere de un archivo de opciones de configuración, el cual también es generado por la herramienta. El archivo de opciones de configuración del indicador de FastObjects provee información que es aplicable a todas las aplicaciones que contengan clases que serán persistentes, para la generación de base de datos, diccionario de nombres e índices.
Al archivo de opciones se le puede dar el nombre por defecto (ptj.opt). o también se le puede asignar un nombre diferente. El archivo de opciones del indicador mantiene una sintaxis muy parecida a la de los archivos de inicialización de Windows (.in¡). A continuación se describirán las secciones de este archivo de configuración.
Secciones El nombre de una sección está encerrado entre paréntesis cuadrados [ I y se le denomina cabecera, el resto de la sección se escribe debajo de este nombre en líneas separadas. Las cabeceras de las secciones también se pueden nombrar a los componentes como lo son: las clases que se desean hacer persistentes, la base de datos o índices. La sintaxis para escribir la cabecera quedaría de la siguiente forma: el nombre de uno de estos componentes seguido de una diagonal invertida y a continuación el nombre de la sección. Ejemplo: [classes\MyClassl
Palabras reservadas A las palabras reservadas se les asignan valores por medio del operador = si el valor es un s t r i n q y utiliza caracteres especiales, éstos deben ser antecedidos por la diagonal - _ invertida \ como se hace en el lenguaje Java. Cada palabra reservada en una sección es única y se puede asignar más de un valor separándolos por comas.
Comentarios Para escribir comentarios en el archivo de opciones del indicador de FastObjects, se debe usar ; la cual le dice al indicador que ignore el texto siguiente hasta el final de la línea. También se pueden utilizar los delimitadores de comentarios del estándar de Java.
Lasección Global [ 1 La sección global comienza con una cabecera de sección vacía y es usada para configurar el comportamiento global del sistema.
La sección de clases [classe\ClassNamel La sección de clases es usada para denominar las clases que se desean hacer persistentes, es decir para que sean persistentes cada una de estas clases deben tener su Propia sección. La siguiente es una lista de consideraciones importantes a considerarse en la sección de clases:
Si se desea hacer una clase persistentes se debe declarar explícitamente la clase como persistente. I Si no se desea hacer una clase persistente que extienda a otra se debe declarar explícitamente el valor de hasExten t = fa l se .
4 3
IV Desarrolla de la herramienta traductora
La sección classes\members En el lenguaje Java los elementos de una colección siempre son de tipo object. Cuando se recupera un elemento de una colección, se requiere cambiar el tipo object al tipo actual
[Clases \className\members \memberName I
de objeto. Este problema puede presentarselai hacer una consulta que está basado en 10s miembros de una colección. Esto se puede corregir usando la palabra reservada itemType con la que se especifica el tipo de clase actual que se intenta almacenar como miembro de otra clase. Ejemplo [classes\Toolkit\members\engineers-1,. itemType=Engineer
interfaces La sección de interfaces es usada para nombrar las interfaces en las aplicaciones FastObjects. Cada interfaz que se quiera hacer persistente debe tener su propia sección incluso interfaces que no serán persistentes pero que estén mapeadas a clases persistentes deberán tener su propia sección.
Si se desea hacer una interfaz persistente se tiene que declarar explícitamente como persistente. Si se desea que una interfaz persistente no tenga un extent, debe indicarse explícitamente el Valor de hasExtent = false.
Se requiere incluir el diccionario para la interfaz schema,
Databases [database\logicalDatabaseName] La sección database provee los nombres para las bases de datos creadas por el remarcador del Fastobject. Si hay mas de un diccionario definido en el archivo de opciones del remarcador de FatsObject, se necesita usar la palabra reservada schema para definir el diccionario de esa base de datos. El siguiente es un ejemplo de la sección Databases: 1
[databases\applicationBase] schema = application
La sección Dackaqe (paquetes específicos) La sección package tiene las configuraciones que son comunes para todas las clases e interfaces en la especificación package de lenguaje Java. Ejemplo: Ipackage\com.company.general] i,
[package\PackageName]
schema = general
$ La sección Dackaqe (default) [package] La sección package default es usada por cualquier sección de clases que no especifique un nombre de paquete. Es decir cualquier clase que no esté en la sección de paquetes específicos será colocada en el diccionario declarado en schema. Ejemplo: [package] il
schema = application
La sección schemata La sección schemata es usada para nombrar el diccionario que se usa para las clases. El diccionario almacena la descripción de las clases y la base de datos almacena los objetos persistentes que son creados. En el siguiente ejemplo se muestra cómo nombrar a un diccionario.
[schemata\ 1 o g l ca 1 CchemaName]
[schemata\general]
4 4
I V Desarrollo de l a herramienta traductora
'; Fast Objects ; Comentarios a : albertogeesd-cen1det.com.m
. _+_*_*_*_/_t_t_~_*_/_/_*_1_*_*_/_*_1_1_*-~-~-+-~-*-~-*-~-*-*-~-*
[schemata\xml-dictl name = xml-dict onefile = false
. ________________________________________------------------
Idatabases\xmlbasel name = xmlbase onefile = false
. ________________________________________------------------
[classes\in.Invoicel persistent=true
[classes\in.ShipTol persistent=true
[classes\ShipTo\members\~customer~ itemType = Customer
[ciasses\invoice\members\~itemListl itemType = Item
Ese nombre es el nombre lógico con el cual se hará referencia al diccionario en cualquier otra sección del archivo de opciones del remarcador de FastObjects. También es el nombre físico de archivo a menos que se le cambie de nombre con la palabra reservada name.
La sección Indexes [indexes\indexName] Las secciones de índices son usadas para definir índices para las clases persistentes. Cada índice tiene su propia sección. El indexName es el nombre designado para el índice. El índice está asociado con una clase en particular por medio de la palabra reservada class como se muestra el ejemplo:
Un índice está asociado con uno o más datos miembro de una clase. El siguiente es un ejemplo de un índice de un dato miembro de una clase: [index\ProductTitleIndexl c l a s s = Product rnemebers = title-
La sección deindexes\members [indexes\indexName\members\indexMemberNamel Esta sección especifica parámetios adicionales para los miembros indexados. El indexMemberName es el nombre de la clase dato-miembro que está indexada. Se puede especificar el ordenamiento para los índices. Haciendo descending = true
para ordenamiento descendente, por omisión es ascendente.
[index\myIndex] class = <nombre del paquete>.<nombre de la clase>
A continuación se muestra un archivo ptj generado por la herramienta para ejemplificar lo anterior:
; Archivo ptj.opt generado automáticamente con j a r 8 ver 1.0 ; para ser utilizado en la generación del esquema be la BDOO
IV Desarrollo de la herramienta traductora
[ciasses\invoice\members\~shippingMethodl itemType = ShippingMethod
[classes\Invoice\members\~shippinpDatel itemiype = ShippingDate
I/
[classes\in.Customerl 11.. ?ersistent=true
[classes\Customer\members\~addressl itemiype = Address
[classes\in.itern] persistent=true
Iclasses\in.ShippingMethod] persistent=true
[ciasses\org. exolab. castor. types'. Duration] persistent=true
~classes\ShippingMethod\membersi~estimatedDelivery] itemiype = org.exo1ab.castor.types.Duration
[classes\in.ShippingDatel persistent=true
I1
[classes\org.exolab.castor. types.Date1 persistent=true
Lclasses\ShippingDate\members\-date] iternType = org.exoiab.castor.types.Date
[classes\org.exo;ab.castor.types.Time] persistent=true
[ciasses\ShippingDate\members\~tirne] itemType = 0rg.exolab.castor.types.Time
[classes\in.Address] persistent=true
I1
Fig. 41 Archivo ptj.opt generado por /a herramienta.
4.4.3. Mapeo entre esquemas de XML y clases de Java
El mapeo entre esquemas de XML y clases de Java se da en dos niveles: En los tipo de datos y en las estructuras.
Como no todos los tipos de datos que existen en los esquemas de XML existen en Java, el traductor tiene una tabla donde estos tipos se relacionan con otros tipos básicos de Java para sustituir a los inexistentes. La tabla de correspondencias entre los tipos de datos de los esquemas de XML y los tipos de Java se muestra continuación:
4 6
. . - - . . ~ _- .. ~ - ---- . ~_ ~
I V Desarrollo de l a herramienta traductora
normalizedCtring NMTOKEN NCName ID integer nonPosistiveInteger negatlveInteger long int short byte nonNegativeInteger , pcsitiveInteger
boolean java.math.BigDecima1 float double 0rg.odmg.Darray org.exo1ab.castcr.types.Duration java.util.Date org.exolab.castor.types.Time crg.exo1ab.castor.types.Date org.exo1ab.castor.types.GYearMonth crg.exo1ab.castcr.types.GYear crg.exc1ab.castor.types.GMcnthDay crg.exo1ab.castor.types.GDay crg.exo1ab.castor.types.GMonth byte i 1 byte I I java.lang.String Java.lang.String Java.lang.String java.lang.String java.lang.String java.lang.String int int int long int shor t byte int int
Tabla 4a. Relación entre los tipo de dato de los esquemas de XML y del lenguaje Java
El mapeo de estructuras y elementos de los esquemas de XML se realiza siguiendo algunas condiciones. Por ejemplo:
AI generarse el código fuente en Java, los nombres de variables y tipo de dato mapeados deben ser normalizados antes de escribirse. Las reglas de normalización son las siguientes:
Hacer la primera letra de la variable
I Tabla 46. Reglas de normalización para las variables y tipos de dato
4 7
IV Desarrollo de la herramienta traductora
I contiene a otros elementos I pertenece a otro elemento
I! Cada tipo de elemento se mapea de manera diferente, incluso para el mismo
elemento el mapeo puede ser diferente dependiendo del contexto y localización dentro del esquema de XML, a continuación se muestian elementos en distintos entornos dentro de los esquemas de XML y la manera como son mapeados a declaraciones de clases en Java. ,I
Dará origen a una nueva clase Será una variable miembro de la clase generada por el element( que lo contiene El nombre de la variable será el valor de atributo name, y el tipo será el valor del atributo type
I/
Debe pertenecer a un elemento
ublic class address(/
Será una variable miembro de la clase generada por el elemento que lo contiene El nombre de la variable será el valor del atributo nade, y el tipo será el valor del atributo type
pr iva te string address: private string city; private java.lang.String -id;
i contiene el atributo ref Iconfirma que exista el element O complexType al que se hacen referencia, y se convierte en una variable miembro de la clase que lo contiene. El nombre y el tipo de dato de la variable tendrán el mismo nombre pero normalizados.
s e e m e n i name= i n d cxsa COmD exTioe>
I.
cxsd:sequence> <xsd:elemeni ref="nsl:customer" I> <xsd:element ref="nsí :item" I> !I
'xsd'elemenP ií
</xsd:sequence> c/xsd:complexType>
Ublic class Invoice( l
'I private Customer _customer; private Item -item;
IV Desarrollo de la herramienta traductora
Si no pertenece a ningún otro elemento
Cxsd: element name="address'.' type="string" /> <xsd:element name="city" type="string"/>
</zsd:sequence> <rsd: attribute nñme="id" type="xsd:etring" use="reguired" />
c/xsd: coinplezType> c/xsd: elemciit,
/public class address(1
Dará origen a una nueva clase abstracta y será extendida por I clase que represente al elemento cuyo tipo sea el nombre di complexType
private s t r i n g address; private string city; private java.ia"g.String _Id;
1
contenido del complexType serán su variables miembro. Si f elemento que contiene al cornplexType a su vez est; contenido por otro elemento, el tipo de dato del elemento será f nombre de la clase generada.
private Customer -customer;
I
b u b l i c class customer()
private string address; private s t r i n g at?:
1
4 9
IV Desarrollo de l a herramienta traductora
El resultado del traductor es un conjunto de clases en Java agrupadas en un paquete de Java (package) el cual contiene todos los elementos del esquema de XML para que pueda ser creado el esquema de BDOO.
Fig. 4m. Diagrama de flujo del m6dulo Traductor
Por último como parte de ese análisis de los elementos del esquema de XML, el traductor genera un archivo con extensión .opt el cual contiene información sobre herencia de los elementos del esquema de XML, para su correcta creación en la BDOO
4.5. Arquitectura de clases
Como ya se mencionó en este capitulo, la herramienta desarrollada consta de dos paquetes de clases llamados analizador-Is y traductor.
El paquete analizador-Is está formado por las clases generadas mediante Javacc. por lo que no requieren ser editadas o analizadas. Las clases del paquete analizador-Is son listadas a continuación:
. . . . . .
. .
. . .
ASCllCharStream JJTschemaXMLState Node NodeAttribute NodePCDATA Nodeprefix ParseException schemaXML schemaXMLConstants SchemaXMLTokenManager schemaXMLTreeConstants SimpleNode Token TokenMgrError
51
IV Desarrollo de la herramienta traductora
II Público
Público
Público estático
Público estático
El paquete Traductor contiene las ~ clases que tomarán a los elementos del esquema de XML y los traducirán a código en Java, y a diferencia del Analizador-Is éste si fue diseñado y desarrollado paso a paso. Las clases del paquete Traductor son tres: XMLage, xsd2java y XSDString, las cuales se describen a continuación.
4.5.1. La clase XMLage
Esta clase realiza operaciones que tienen que ver con el documento de XML, que para nuestro caso en un esquema de XML. Por ejemplo: en qué ruta de directorios se encuentra, cuál es su nodo raiz, etc.
It
. parámetro para inicializar la variable11 miembro uri.
Node nodoDocumento I/ Toma la variable miembro uri ) devuelve el documento de XML er una variable del tipo Node.
NodeList nodosRaiz Invoca al método nodoDocumento ) de ah1 obtiene una lista de los nodos hijos de la raiz del documento de XML.
Boolean validarElement (Nodenodo) Si el nodo que recibe comc parámetro es un ELEMENT-NODE devuelve verdadero, de lo contraric devuelve valor falso.
Node getPrimerHijoElement '(Node nodo) Toma el nodo que recibe comc parámetro y devuelve el primer nodc hijo de tipo ELEMENT NODE.
métodos de esta clase.
IV' Desarrollo de l a herramienta traductora
MBtod6s-miembrc 'Ambito.';' ,'":?:Ti Público
Público
Privado String
Privado String
Privado String
Privado String
Público String
Público String
Público Strinc
Público Strin!
XSDString
quitaGuion
Pon-
capitalMax
capitalMin
normalizar
en este caso, la variable miembro s se inicializa con el valor n u l l . Es el constructor con parámetros, en este caso, la variable miembro s se inicializa con el valor del parámetro.
(String sAux) Devuelve la cadena de caracteres resultante de la eliminación de todos los caracteres "-" y la siguiente letra en mayúscula, en la cadena sAux. Devuelve la cadena sAux con el caracter "-" insertado al inicio de la misma. Devuelve la cadena sAux con el caracter inicial en mayúscula. Devuelve la cadena sAux Con el caracter inicial en minúscula. Normaliza de acuerdo al valor del parámetro: "o" para tipos, "1" para nombre. Si existen prefijo O guiones 10s quita y la primera letra la cambia dependiendo del
(String s)
(String sAux)
(String sAux)
(String sAux)
(int patron)
I parámetro.
xsdTipo y devuelve el localizado en el
mapear Elimina prefijo si lo tiene, y busca la cadena de caracteres en el
parámetro, un elemento simpiel 'ype cuyo nombre coincida con el de la cadena de caracteres, y devuelve el tipo de dato localizado en el atributo
1 vector javaTipo. getSimpleType (XMLage docXML)
parámetro, un elemento complexType cuyo nombre coincida con el de la cadena de caracteres, y devuelve dicho nombre.
Busca en los nodos hijos del nodo raíz correspondiente al
5 3
base .
nodo raiz correspondiente al
IV Desarrollo de la herramienta traductora
parámetro, un elementc element cuyo nombre coincidi con el de la cadena de caracteres, y devuelve el valoi del atributo type. Si no tien€
- - Júblico
~
Público
~
Publico
__ Público
~
Público
- Público 3stático Público 3StátiCO Público
Público
~
~
~
Público
Público __ Público
- -
I1
(XbhLage docXML)
!
11
(String paquete)
"(FileWritefw) (String s)
'(Filewriter fw)
String
String
String
Filewrite
Filewrite
void
devuelve falso, ejecuta el método getcomplexType y Si éste devuelve falso ejecuta el método getsimplelype, todoestocon la finalidad de obtener la traducción de la cadena de caracteres a código en Java.
Ejecuta el método getTipo; si devuelve falso, ejecuta el método getcomplexType, todo est0 con la finalidad de obtener la traducción de la cadena de caracteres a código en Java. Crea el archivo con extensión java donde se almacenará el código fuente, en una carpeta con el nombre del parámetro y devuelve un ejemplar de la clase Filewrite. Crea el archivo que servirá como archivo de configuración para el indicador de FastObjects. Escribe en el archivo fw la cadena S. Cierra el archivo fw. void
String
boolean
String .
(String SI) void
contrario devuelve falso. Devuelve la cadena de caracteres. Asigna el valor del parámetro a la
boolean cadena de caracteres. Si la cadena de caracteres es nula, devuelve verdadero, de lo
getTipo
dataBinding
getRef
crear
crear
escribir
cerrar
quitaprefijo
-qualslgnoreCas8
set
esNulo
íXMLaoe docXML) I Busca en los nodos hijos del
II I nombre. 'I
(XMLage docXML) I Ejecuta el método mapear; si
(String s1)
parámetro sin importar si son mayúsculas y minúsculas, si son iguales devuelve verdadero de Io
54
IV Desarrollo de la herramienta traductora
- . .
4.5.3. La clase xsd2java
Esta clase es la encargada de dirigir la traducción de los elementos del esquema de XML a código en Java. declara variables miembro de tipo de las clases XMLage y XSDString.
~
Protegida
Pública
Protegida
Variables miembro. Ambito 1 Tipo I Nombre ,I Descripción Privada 1 String I paquete I Contiene el nombre del paquete (packaqe) que contendrá a
- una variable tipo vector. Es la cadena de caracteres donde se va añadiendo el código en Java generado por la traducción.
Filewriter fwOpt Es utilizada para escribir y generar los archivos que contendrán el código en Java, resultado de la traducción.
XSDString elem-name Cuando en un esquema de XML el atributo name tiene valor, se guarda en esta variable, la cual es de tipo XSDString para
String
-
Protegida
- se guarda en esta.variable, la cual es de tipo XSDString para poder usar los métodos de dicha clase. Cuando en un esquema de XML el atributo ref tiene valor, se guarda en esta variable, la cual es de tipo XSDString para
XSDString elem-ref
1 poder usar los métodos de dicha clase. 11 Protegida 1 XSDString I elem type I Cuando en un esquema de XML el atributo t y p e tiene valor,
Ambito Tipo Nombre Parámetros Público - xsd2java (XMLage xmlage) (String
paquete) (Filewriter fwOpt)
Privado void getAtributos (Node nodo)
Descripción Es el constructor y los parámetros que recibe los. almacena en SU respectiva variable miembro. Examina el nodo que recibe como parámetro y busca sus atributos (si los tiene), y llena las variables
oder usar los métodos de dicha clase. 11 Pública 1 XMLage 1 xmlage I Es del tipo XMLage para poder usar los métodos de dichi
1 eiem name, &em type y elem ref. ~ ~~~~
( String indent) (Filewriter fw) (String
namefile)
un recorrido por la lista de nodos que recibe como parámetro. identifica qué tipo de elemento es el nodo y decide cómo tratarlo. Como utiliza variables de tipo XSDString, utiliza sus mktodos
[ para realizar la traducción. I1
55
IV Desarrollo de l a herramienta traductora
se desarrolló un nuevo programa cuyas instrucciones son ejecutar el package del analizador léxico-sintáctico y si no hubo ningún error ejecutar el package del traductor. A este tercer programa se le nombró: jar&
Para ejecutar la herramienta se debe usar como parámetro de la máquina virtual de Java el nombre de este tercer programa como se muestra en el ejemplo:
donde: java jar8 <esquema de XML> <package>
jar8 es el nombre del programa <esquema de XML> se refiere ai esquema de XML a traducir <package> se refiere al nombre del package donde se generarán las
declaraciones de clases
Sin embargo para realizar las pruebas y verificar que efectivamente se genera un esquema para la base de datos orientada a objetos se desarrolló un archivo de procesamiento por lotes, que a continuación se describe:
@echo off echo Proyecto Jar8: Generando código en java . . . java jar8 %1 %2 echo Proyecto Jar8: Compilando código generado . . . javac %2\*.java echo Proyecto Jara: Creando esquema en Fast Objects call c:\betas\jarS\fast
En este archivo batch se realizan 3 procesos:
1, Generación de Códiqo en Java.- Que se logra con la ejecución del Programa lar8
Léx Ño-Si ntáctico
t Fig. 4o.üiagrama de Sujo del programa jar8
2. Compilación del códiqo qenerado.- Que se logra compilando con javac todos 10s archivos .java generados.
Fig. 4p.Cornp~lacion de código fuente en Java
57
IV Desarrollo de l a herramienta traductora
, ,, , 4;. :, ,, .: ,): . , ' . , , ,
Características k Acepta archivos DTD como entrada para la traducción Acepta archivos de esquemas de XML como entrada para la traducción Soporta la descripción formal del W3C del '2 de mayo de 2001
3. Creación del esauema.- Que se logr;a ejecutando el archivo batch llamado f a s t . El archivo batch fast ejecuta únicamente el siguiente commando:
p t j -enhance - inplace - c rea te -odmg
con el cual se crea el esquema de la base de datos orientada a objetos, usando el archivo ptj.opt y las clases compiladas generadas por la herramienta jar8.
, , < _ ,,, . Castor XML jar6
No No
si Si
Si si
Soporta todas las reglas sintácticas de los esquemas de XML
Genera código fuente en Java dentro de un package
Genera métodos set y get para cada variable de la clase
Genera métodos de validación de valores permitidos
Genera archivo de configuración para el esquema de la BDOO
Es posible manipular el código de la herramienta Permite la traducción de declaraciones de clases a esquemas de XML
No No
si sí
si si
si No
No si
No Si
Si No
CASOS DE PRUEBA I I -"" "I-- l"."""llx
Este capítulo contiene las descripciones de las pruebas realizadas con diferentes tipos de esquemas de XML que comprueban la correcta creación de la declaración de clases que sirven para la obtención del esquema de la base de datos orientada a objetos (BDOO). Se han seleccionado cinco casos de prueba más representativos y en cada uno de ellos se explica brevemente el por qué del resultado.
V Casos de Prueba
5.1. Objetivo de las pruebas
El objetivo principal de estas pruebas es confirmar dos aspectos importantes: la correcta generación de declaraciones de clases en el lenguaje Java a partir de la traducción de los esquemas de XML y la creación del esquema de la base de datos orientada a objetos a partir de estas declaraciones de clases.
Aunque el objetivo de la tesis sólo es la creación del esquema, se realizará una prueba extra donde se escribirá el contenido de un documento de XML en la base de datos orientada a objetos de la cual se haya generado su esquema, para comprobar que efectivamente el esquema obtenido corresponde al esquema del documento de XML.
5.2. Descripción de la prueba y resultado
análisis de resultados. Cada prueba detalla los siguientes puntos: objetivo de la prueba, entradas, salidas
5.2.1. PRUEBA #I
OBJETIVO: Comprobar la correcta creación de código fuente en Java para los siguientes casos: 1. element sin atributo type, sólo con atributo name y con compiexType definido de
forma interna. 2. element sin atributo name, en cambio tiene el atributo ref. 3. element donde el atributo type no es un tipo de dato básico, en cambio es el tipo
“zip-codeType” definido en un simpleType .
ENTRADAS:
Carpeta: org (contiene clases para manejar algunos tipos de dato) Archivo: invoice.xsd (archivo de entrada)
Nota : El archivo invoice.xml no se utiliza en este ejemplo.
I1
Fig. 5a. Archivos de la carpeta Ejl antes de ejecutar el traductoi
60
V Casos de Prueba
01 <?xml version="l.03*?> O 2 <xsd:schema tar9etNamespace="http://castor.exolab.org/~e~t/~nvoice~~ 03 ~~~~s:xsd="http://www.w3.org/200l/XMLschem~~~ 04 xmlns:nsl="http://castor.exolab.org/~e~t/~n"~i~~,,> 05 <xsd: element name="invoice"> 06 <xsd:complexType> 07 <xsd:sequence> 08 <xsd : element name="ship-to"> 39 <xsd:complexType> l o <xsd: all> 11 <xsd:element
12 </xsd:all> 13 </xsd:complexType> 14 </xsd:element> 15 <xsd:element ref="nsl:item"
16 <xsd:element ref="nsl:shipping-method"/> 17 <xsd: element ref="nsl : shipping-date"/> 18 </xsd:sequence> 19 <xsd: attribute name="id" type="xsd: string"
20 </xsd:complexType> 21 </xsd:element> 22 <!-- Description of a customer --> 23 <xsd:element name="customer"> 2 4 <xsd:complexType> 25 <xsd:sequence> 26 <xsd:element name="name" type="xsd:string"/> 27 <xsd: element ref="nsl : address"/> 28 <xsd: element name="phone" type="nsl :Xxx"/> 29 </xsd:sequence> 30 </xsd:complexType> 31 </xsd:element> 32 < ! - - Description of an item --> 33 <xsd : element name= " i t em"> 34 <xsd:complexType> 35 <xsd:sequence> 36 <xsd: element name="Quanti ty"
37 <xsd:element name="Price"
38 </xsd:sequence> 39 <xsd: attribute name="Id" type="xsd: ID"
40
41
42 </xsd:complexType> 43 </xsd:element> 44 <! - - Shipping Method --> 45 <xsd:element name="shipping-method"> 46 <xsd:complexType> 41 <xsd:sequence> 48 49 50 <xsd:element name="estimated-delivery',
51 </xsd:sequence> 52 </xsd:complexType> 53 </xsd:element>
ref="nsl:customer"/>
maxOccurs="unbounded" />
use="required"/>
type="xsd: integer"/>
type="nsl : PriceType"/>
use="required"/>
default="false"/>
use="required"/>
cxsd: attribute name="InStock" type="xsd: boolean"
<xsd: attribute name="Category" type="xsd: string"
<xsd:element name="carrier" type="xsd:string"/: <xsd:element name="option" type="xsd: string"/>
type="xsd: duration"/>
61
V Casos de Prueba
- 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
74 75
76
77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 O0 o1 o 2 03 04 05 0 6 o 7 O8 o9 10 11 12 13 -
<!- - Shipping date --> <xsd:element narne="shippinq-date"> .~ ~
<xsd:complexType> 'I <xsd:sequence>
<xsd: element name="date" type="xsd:date"/> <xsd:elernent name="time" type="xsd: time"/>
</xsd:sequence> </xsd:complexType>
</xsd:element> < ! - - A simple U.S. based Addkess structure --> <xsd:element name="address">
<xsd:annotation> <xsd:documentation>
Represents a U.S . Address </xsd:documentation>
</xsd:annotation> : <xsd:complexType>
<xsd:sequence> <xsd:element name="streetl" type="xsd:string"/: <xsd:element name="streetZ" type="xsd:string"
<xsd:element name="city" type="xsd: string"/> <xsd: element name="state"
<xsd:element name="zipcode" type="nsl: zip-
< ! - - str,eet address 1 --> < ! - - optional street address 2 --> < ! - - city--> < ! - - state code --> < ! - - zip-code -->
minOccurs="O"/>
type="nsl: stateCodeType"/>
codeType"/>
</xsd:sequence> </xsd:complexType> ,
</xsd:element> < ! - - A U.S. Zip Code - -> <xsd : simpleType name="zip-codeType">
<xsd: restriction base="xsd: string">
</xsd:restriction> <xsd:pattern value="[0-91 5 1 ( - [O-91 1 4 1 ) ? " />
</xsd:simpleType> < ! - - State Code obviously not a valid state code . . . . but this is just an example and I don't feel like creating all the valid ones.
--> <xsd : simpleType name='*s tateCodeType">
<xsd: restriction base="xsd: string">
</xsd:restriction> </xsd:sirnpleType> < ! - - Telephone Number - -> <xsd: simpleType name="Xxx">
<xsd:pattern value="[A-Zl 2 1 " / >
<xsd:restriction base="xsd:string"> <xsd: length v?lue="l2"/> <xsd:pattern value="[0-91 131- [O-91 (31- [O-91 1 4 I " / >
</xsd:restriction> </xsd:simpleType> < ! - - Cool price type --> <xsd: sirnpleType name="PriceType">
<xsd: restriction base="xsd: float"> <xsd: fractionDigits value="Z"/> <xsd: totalDigits value="5"/> <xsd:minInclusive value="l"/>
62
V Casos de Prueba
114 <xsd:maxInclusive value="100"/> 115 .</xsd:restriction> 116 </xsd:simpleType> 117 </xsd:schema>
SALIDAS: Fig. 56. Esquema de XML de entrada (invoice.xsd)
Carpeta: invoice (es el package que contiene la declaración de clases que fue generada). LOS archivos que contiene son: Address. java, Customer. java,
ShipTo. java; estos archivos representan elementos del esquema de XML
Carpeta: xml-base (es donde están los datos de la base de datos) Carpeta: xmldict (es donde está el esquema de la base de datos) Archivo: ptj.opt (es el archivo de configuración requerido por la base de datos)
Invoice.jav.3, Item.java, ShippingDate.java, ShippingMethod.java,
invoice.xsd.
Fig. 5c. Archivos de la carpeta Ejl después de ejecutar el traductor
ANALISIS DE RESULTADOS:
1. element sin atributo type, sólo con atributo name y con complexType definido de forma interna
. . . . _.. ,: . * . . ' * . " .. ~
xsd:element na ip: to" > pis ,:: *u i ..Ixsd: compie .. <
<xsd:ali> . . . . <xsd: element ref="nsl:customer"/>
</xsd:ai+> - </Xsd:complexType> :element
</xsd:ai+> - </Xsd:complexType> :element
Este elemento tiene el nombre "ship-to" pero no tiene un tipo de dato básico. en cambio posee una declaración de tipo complejo; esto se traduce a una declaración de clase con el nombre del elemento y como variables miembro de la clase se escriben los elementos contenidos en el tipo complejo:
6 3
v casos de Prueba
il ,! ;
2. element sin atributo name, en cambio tiene el atributo ref:
<xsd:element name=,"ship-to"> 11 <xsd:complexType>
<xsd:all>
,' ~. .,: ',
i t . : </xsd:element>,,. .,, s.,. . ,
'11
Este elemento no posee ningún nombre pero hace referencia al elemento "customer". posteriormente se define este elemento "customer"; esto se traduce a una declaración de clase con el nombre del elemento y a una definición de variables miembro donde su tipo de dato será el nombre del elemento:
I
bi/ aya. lang.,Ctring ddress :'a'ddtess; -
private ]ava.lang.Strrng -phone; 71
64
V Casos de Prueba
.. "
j.<j_ ~.,. "?>, ) < / < , , ,,. ,I... .. - >, name;-^ 4. - _ - ' 1 - =
. . public Adpess :getAddress O .-I ,. i ;,e> "
return this.-address; 1 public void SetAddressiAddr . ; . . this .-address ='-address;
I
:. r
.lang.String getphone0 'i [ ~ 2 % ~ * "'return this. phone:
this.-phbne - 'i ?
:
mer, -customer;
. .
3. element donde el atributo type no es un tipo de dato básico, en cambio es el tipo "zip-codeType" definido en un simplelype.
,., - t ' I".' " '
::I <xsd: complexType> <xsd:sequence>
<xsd:element kame=v*streeti'* type="xsd:string"/>" -. ":: <xsd:element name="streetZ" type="xsd:string"
_i 6..
ccurs="O"/> ame=" ci t y : t ype=,;xs ame="state" t,ype="
ixsd: element 'hame="zip&de" type="nsl : zip-codeType"/> ,.,. <:<o . .
.i,,, , . , ,: , L ,.., </xsd:sequence> </xsd:'&omplexType> ""
i ,, ,
-:,<!-- A:U.S. Zip,Code? --> + .;,: .. xgd: simpleType name="zip-codeTy
<xsd: restriction 'base="xsd: string"> <xsd:pattern val , . =" [0 -91 151 (-,í0-91
: .,, <:,, >', ,. 4 /xid: restticti&ñ> '' , I . . .,. .< </xsd:simpleType>
, .. . . " .. . " ,.,. ~ ..... ~.,. -". , , *.
6 5
V Casos de Prueba
El elemento "zipcode" no posee un tipo de dato básico y tiene un tipo de dato definido por el usuario en el tipo simple "zip-codeType", esto se traduce a una declaración de variable miembro con el tipo de dato definido en el atributo base del simplelype: / /
, ,,., .,, . I . . . .. .. ,,
" !''I:' public class Address( 51
re'turn .this .-st..reetl: ,,I_> " .,:., -< , ,', ,
oid 'setCitii(java.lang.String -city) (
,iiil ,$! ,+,
!I/: java.lang.String getSta
,/j ,<ili , :>' ,return;thi.s._state: ~. ,~
,. , , , , : , , ,,,, , , *i :;, . .:, ,!<' 2" ,,. , .,
5.2.2. PRUEBA #2 I1
OBJETIVO: Comprobar la correcta creación de código fuente en Java para el siguiente caso: 1. element con atributo maxOcurrs="unbounded"
6 6 I
V Casos de P r u e b a
ENTRADAS:
Carpeta: org (contiene clases para manejar algunos tipos de dato) Archivo: referencia.xsd (archivo de entrada).
Nota: Archivo: referencia.xml (no se utiliza en este ejemplo).
Fig. 5d. Archivos de la carpeta Ej2 antes de ejecutar el traductor
31 <?xml version="l.O"?> 32 < ! - - edited with XML Spy v4.4 U (http://www.xmlspy.com) by iscage 33 (cenidet) --> 34 <xsd:schema targe~Namespace="http://cenidet.edu.mx/iscage/tesis/refs" 35 xmlns="http://cenidet.edu.mx/iscage/tesis/refs" 36 xmlns:xsd="http://www.w3.org/2OOl/XMLSchema" 07 elementFormDefault=*'qualified" a t t r ibu teFormUefau l t="unqua l i f i ed"> O8 <xsd:element name="Referencia"> o9 <xsd:annotation> 10 <xsd:documentation>Comment describing your root
element</xsd:documentation> 11 </xsd:annotation> 12 <xsd:complexType> 13 <xsd:sequence> 14 <xsd: element name="Ref" maxOccurs="unbounded"> 1 5 <xsd:complexType> 16 <xsd:sequence> 17 <xsd: element name="Autor"
18 <xsd:element name="Fecha"
<xsd:element name="Esquema- 19
20 <xsd:element narne="Fuente"> 21 <xsd:complexType> 22 <xsd:choice> 23
24
25 26 </xsd:complexType>
tyDe="xsd: string" maxOccurs="unbounded"/>
type="xsd: date"/>
Acopio" type="xsd: string"/>
<xsd: element ref="libro" minUccurs="O"/>
<xsd: element ref="web," minOccurs="O" /> </xsd:choice>
67
v casos de Prueba
- 27 28
29 30
3 1 32 33 34 35 36 37 38 39
40 4 1
42 43
4 4
45
46
47 48 4 9 50 5 1 52
53 54
55
5 6 5 1 58
</xsd:element> <xsd: element name="ReSUmen"
type="xsd: string"/> </xsd:sequence>
I! <xsd:attribute name="Tema" type="xsd:string" use="required"/>
</xsd:complexType> </xsd:element>
</xsd:sequence> ,I </xsd:complexType>
</xsd:element> <xsd:element name="libro">
<xsd:complexType> <xsd:sequence>
<xsd: element name="Capitulo"
<xsd: element name="Paginas" type="xsd: string"/> <xsd: element name="Biblioteca"
type="xsd : string" />
type="xsd: string"/> </xsd:sequence>' <xsd:attribute name="Titulo" type="xsd:string"
<xsd: attribute name="Editorial" type="xsd: string"
<xsd:attribute name="Anno" type="xsd:gYear"
<xsd: attribute ,name="Edicion" type="xsd: string"
use="required"/>
use="required"/>
use="required"/>
use="optional"/> ' </xsd:complexType>
</xsd:element> <xsd: element name="web"> ,
<xsd:complexType> <xsd:sequence>
<xsd:element name="Respaldo" type="xsd: string"/> 11
</xsd:sequence> <xsd:attribute name="URI" type="xsd:anyURI"
<xsd:attribute 'name="Sitio" type="xsd: string" use="required"/>
use="optional"/> </xsd:complexType>
</xsd:element> </xsd:schema>
1 Fig. 5e. Esquema de XML de entrada (referencia.xsd)
SALIDAS:
Carpeta: referencia (es el package que contiene la declaración de clases que fue generada). LOS archivos que contiene son: Fuente. java, L i b r o . java, Ref. java, Referencia. java, Web. java; &OS archivos representan eiementos del esquema de XML referencia.xsd. Carpeta: xml-base (es donde están los datos de la base de datos). Carpeta: xmldict (es donde está el esquema de la base dé datos). Archivo: ptj.opt (es el archivo de configuración requerido pÓr la base de datos).
6 8
V Casos de Prueba
Fig. 5f. Archivos de la carpeta Ej2 después de ejecutar el traductor
ANÁLISIS DE RESULTADOS:
1. element con atributo maxOcurrs="unbounded": .. . ...
El element "Ref" tiene el atributo maxocurrc con valor de "unbounded", esto significa que representa a una estructura de array o lista, esto se traduce a la declaración siguiente:
,,, .. ; ciass Referencia1 ''
rivate java.util.Vector -refList: 2;;. :
«*< . ." A
5.2.3. PRUEBA #3
OBJETIVO: Comprobar la correcta creación de código fuente en Java para el siguiente caso: 1. El element "author" tiene un tipo de dato "authorv" que es un complexType
definido de forma externa.
ENTRADAS:
Carpeta: org (contiene clases para manejar algunos tipos de dato) Archivo: text.xsd (archivo de entrada).
Nota: Archivo text.xml (no se utiliza en este ejemplo).
69
Fig. 5g. Archivos de la carpeta Ej3 antes de ejecutar el traductor
o1 0 2
03 o 4 05 06 07 O8 o 9
<?xml version="l . O" encoding="UTF-8"?> <!- - SHeader: /horne/cvsroot/w3c-xrn1- schema/user/examples/documentation/text.xsd,v 1.1 2002/02/04 16:55:14 vdv Exp $ --> <xs:schema xmlns:xs="http://www.w3.org/2OOl/XMLSchema~~>
<xs:element name="name" type="xs:string"/> <xs: element name="qualification" type="xs: string"/> <xs: element name="born" type="xs:date"/> <xs : element name="dead" type="xs : date"/> <xs : element name="isbn" tvpe="xs : inteqer"/> ..
10 11 11 <xs:attribute name="id" type="xs: ID"/> 12 <xs : attribute name="available" type="xs: boolean"/: 1 3 <xs:attribute name="lang" type="xs:string"/> 14 15 <xs:element name="title"> 1 6 <xs:complexType> 1 7 <xs: all> 1 8 <xs : element name="content" type="xs: string"/> 19 </xs:all> 20 <xs :attribute ref="lang"/> 21 </xs:complexType> 22 </xs:element> 23 24 <xs : element name="library"> 25 <xs:complexType> 26 <xs:sequence> 21 28 </xs:sequence> 29 </xi:complexType> 30 </xs:element> 31 32 <xs : complexType name="authorv"> 3 3 <xs:sequence> 34 <xs:eiement ref="name"/> 35 <xs : element ref="born"/> 36
37 <xs: attribute ref="id"/>
11
<xs : eleyent ref="book" maxOccurs="unbounded"/>
<xs : element ref="dead" minOccurs="O"/> </xs:sequence>
</xs:complexType> ,I
7 0
I fig. 5h. Esquema de XML de entrada (text.xsd)
38 39 <xs:annotation> 40 <xs:documentation xml: lang="en"> 41 42 </xs:documentation> 43 <xs:documentation xml:lang="fr"> 44 Designe l'auteur d'un livre. 45 </xs:documentation> 46 </xs:annotation> 47 </xs:element> 48 49 <xs: element name="book"> 50 <xs:complexType> 51 <xs:sequence> 52 <xs: element ref="isbn"/> 53 <xs:element ref="title"/> 54 <xs :element ref="author" minOccurs="O"
55 <xs :element ref="character" minOccurs="O"
56 </xs:sequence> 57 <xs:attribute ref="id"/> 58 <xs:attribute ref="available"/> 59 </xs:complexType> 6 0 </xs:element> 61 62 <xs:element name="character"> 63 <xs:complexType> 64 <xs:sequence> 65 <xs : element ref="name"/> 66 <xs : element ref="born"/> 61 <ks:element ref="quaiification"/> 68 </xs:sequence> 69 <xs:attribute ref="id"/> 70 </xs:complexType> 71 </xs:element>
73 </xs:schema; l2
<xs : element name="author" type='fauthorvv>
The author of a book.
maxOccurs="unbounded"/>
maxOccurs="unbounded"/>
SALIDAS:
Carpeta: text (es el package que contiene la declaración de clases que fue generada). Los archivos que contiene son: Author. java, Authorv. java, Book.java, Character.java, Library.java, Title.java; &OS archivos representan elementos del esquema de XML text .xsd. Carpeta: xml-base (es donde están los datos de la base de datos). Carpeta: xmldict (es donde está el esquema de la base de datos). Archivo: ptj.opt (es el archivo de configuración requerido por la base de datos).
71
V Casos de Prueba
..... .."
Fig. 5i. Archivos de la carpeta Ej3 después de ejecutar el traductor
ANÁLISIS DE RESULTADOS:
1. El element "author" tiene un tipo de dato "authorv" que es un complexType definido de forma externa
~. : .'" 1b .,__. ..<_,_ *_.>"> _(*>, ,,~, ,?. ,c. ,. . . " i l ,
<xs :element name="author" tvpes"authorv">: .. . . . . , ,1,' , ,
<xs: annotat$on>, .i >..> <xs :'docum ml!iang='.enT'>
. , , , i::~ The auth$r of a book.
Designe :l'abteÜr d'un 'livre.
documentaeion> <xs :documentation,:.xml: lang="fr"> ,.ii ., . ,i 2 2 . j
,<'. j/
</xs:documenta$ion> </xs:annotation> !
< > ' . a , ,. ' 'I :,> </xs:element>, ' ' J
rp <xc : complexType name="authorv">
,,,, .. ,,. .<xs: sequence> , , ,2; . , , , , . <xs:eiement ref="name"/>" ." '
,'. . </xs:sequence>, ',._, *
</?L5:complexType>
I1
declaración siguiente: !I
El element "author" tiene el atributo maxocurrs con valo; de "unbounded", esto significa que representa a una estructura de array o lista, esto se traduce a la
.& * . ,,, , . . , , ,,, .:> -.v .=> .<>. .. <>,>
, . public abstract class Authtrv( qj ,private jaya.lang.Strin private org.exolab.cast
# I - private org.exolab.cast es.Dato -deid; .. . . c, ,private java.lang.String,-id;
72
V Casos de Prueba
., . ,. ... .. __ . .
public ciass, A
i -..> . ,,,.,,
5.2.4. PRUEBA #4
OBJETIVO: Comprobar la correcta reacción ante un elemento de los esquemas de XML que no es soportado por la herramienta
ENTRADAS:
Carpeta: org (contiene clases para manejar algunos tipos de dato). Archivo: invoiceX.xcd (archivo de entrada).
Nota: Archivo invoice-X.xrni (no se utiliza en este ejemplo).
Fig. 5j Archivos de la carpeta Ej4 antes de ejecutar el traductor
O1 <?xml version="l.O"?> O2 < ! - - edited with XML spy v 4 . 4 U (http://www.xmlspy.com) by iscage
03 <xsd:schema targetNamespace="http://castor.exolab.org/Test/Invoice" 04 xmlns:nsl="http://castor.exolab.org/Test/lnvoice'~ 05 xmlns:xsd="http://www.w3.org/2OOl/XMLSchema"~ 06 <xsd:element name="invoice"> 07 <xsd:annotation> O8 <xsd:documentation> o 9 A simple repreaentation of an invoice 10 </xsd:documentation> 11 </xsd:annotation> 12 <xsd:complexType> 13 <xsd:sequence> 14 <xsd:element narne="ship-to"> 15 <xsd:complexType>
(cenidet) -->
7 3
~~
V Casos de Prueba
<xsd:group name="customer"> 1 6 17
<xsd:element 18
1 9 <xsd:element
i1 <xsd:secuence>
name=''name" type="xsd: string"/> ..
ref="nsl: address"/> 1 i n <xsd:element -.
name="phone" type="nsl:TelephoneNumberTYPe"/> </xsd:secuence> 21
22 !! </xsd:group> 23 </xsd:complexType> 24 </xsd:element> 25
26 <xsd: element ref="nsl : shipping-method"/> 21 <xsd:element ref="nsl :shipping-date"/> 28 </xsd:sequence? 29 <xsd: attribute 'name="id" type="xsd: string"
30 </xsd:complexType> 31 </xsd:element> 32 < ! - - Description of an item --> 33 <xsd:element name="item"> 34 <xsd:complexType> 3 s <xsd:sequence>' 36 <xsd:element name="Quantity"
37 <xsd: element name="Price"
38 </xsd:sequence> 39 <xsd:attributeGroup ref="nsl:ItemAttributes"/> 40 </xsd:complexType> 41 </xsd:element> 42 < ! - - Shipping Method --> 43 <xsd : element name="shipping-method"> 44 <xsd:complexType> 4s <xsd:sequence>: 46 <xsd: element name="carrier" type="xsd: string"/> 47 <xsd:element name="option" type="xsd:string"/> 4 8 <xsd:element name="estimated-delivery"
49 </xsd:sequence> 50 </xsd:complexType> 51 </xsd:element> 52 < ! - - Shipping date --> 53 <xsd: element name="shipping-date"> 54 <xsd:complexType> 5s <xsd:sequence> 56 <xsd:element name="date" type="xsd:date"/> 51 <xsd: element name="time" type="xsd: time"/> 58 </xsd:sequence> 59 </xsd:complexType> I, 60 </xsd:element> 61 < ! - - A simple U.C. based Address structure --> 62 <xsd:element name="address"> 63 <xsd:annotation> .. ,64 <xsd:documentation> 65 Represents a U.S. Address 66 </xsd:documentation> 67 </xsd:annotation> 68 <xsd:complexType> 69 <xsd:sequence> 70 <xsd:element name="streetl" type="xsd:string"/>
' <xsd:element ref="nsl:item" 11 maxOccurs="unbounded" />
use="required"/>
11
type="xsd: integer"/>
type="nsl : PriceType"/> 'I
type="xsd:duration"/> II
7 4
'I
V Casos de Prueba
7 1 <xsd:element name="street2" type="xsd:string" minOccurs="O"/>
1 2 <xsd:element name="city" type="xsd:string"/> 1 3 <xsd: element name="state"
type="nsl: stateCodeType"/> 74 75 1 6 7 1 1 6 79 6 0 81 62 83 84 85 86 87 6 6 89 90 91 92 93 94 95 96 9 1 98 99
.o0
.o1
.o2
.o3
.o4 105 LO6 107 106 109 110 111 112 113 114 115 116 117 116 119 120
~. <xsd: element ref="nsl : zip-code"/> <!-- street address 1 --> < ! - - optional street address 2 --> < ! - - city--> < ! - - State code --> < ! - - zip-code -->
</xsd:sequence> </xSd:complexType>
</xsd:element> < ! - - A U.S. Zip Code --> <xsd: element name="zip-code">
<xsd:simpleType> <xsd:restriction base="xsd: string">
</xsd:restriction> <xsd:pattern value="i0-91 ( 5 1 ( - [ 0 - 9 1 ( O ) ? " / >
</xsd: simpleT.ype> </xsd:element> < ! - - State Code obviously not a valid state code . . . . but this is just an example and I don't feel like creating all the valid ones.
--> <xsd: simpleType name="stateCodeType">
<xsd: restriction base="xsd: string">
</xsd:restriction> </xsd:simpleType> < ! - - Telephone Number --> <xsd : simpleType name="TelephoneNumberType">
<xsd:pattern value=" [A-21 1 2 1 " / >
<xsd: restriction base="xsd: string"> <xsd:length value="12"/> <xsd:pattern value=" LO-91 131- rO-91 (3)- rO-91 4 1 "I>
</xsd:restriction> </xsd:simpleType> < ! - - Cool price type - -> <xsd: simpleType narne="PriceType">
<xsd:restriction base="xsd:decimal"> <xsd: fractionDigits value="2"/> <xsd: totalDigits value="5"/> <xsd:mifiInclusive value="l"/> <xsd:maxInclusive value="100"/>
</xsd:restriction> </xsd:simpleType> < ! - - The attributes for an Item --> <xsd:attributeGroup name="itemAttributes*'>
<xsd: attribute name="Id" type="xsd: ID" use="required"/> <xsd: attribute name="InStock" type="xsd: boolean"
default="false"/>
use=" required" /> 121 <xsd: attribute name="Category" type="xsd:string"
122 </xsd:attributeGroup> 123 </xsd:schema>
Fig. 5k. Esquema de XML de entrada (invoice-X.xsd)
1 5
v Casos de Prueba
SALIDAS:
En esta prueba no se genera ningún prchivo, ya que existe un error al momento de
Fig. 51. Error generado al ejecutar el traductor
ANÁLISIS DE RESULTADOS:
1. group con atributo name:
elephoneNumberT
La definición de grupos no está soportada por la herramienta de ahí que se genere un error.
5.2.5. PRUEBA # 5 10
OBETIVO:
la base de datos. Comprobar el correcto almacenamiento de los datos de un documento de XML en
ENTRADAS:
7 6
..
V Casos de Prueba
Nota: Archivo invoice.xml (archivo que se almacenará en la BDOO).
Carpeta: org (contiene clases para manejar algunos tipos de dato). Archivo: invoice.xsd (archivo de entrada).
"_^__ -.-- L 1 _ _ I " _ _ - _ _ _ _ _ _ ~ . " _ - _ _ _ _ < _ _ _ _ _ _
7 r & c c i 6 n ; ~ m % : c c - = . ~ * m ~ (-3f-J "*ws%%*7-ib.r- .sLl 's7 _"i_i_i._"-"~l__l__-~"~ ...,....--I
x l 3 o r g hinvoice.wsd @invoice.xmi
Fig. 5m. Archivos de la carpeta Ej5 antes de ejecutar el traductor
13 14 15 16 17 18 19 20 2 1 22 23 24 25 2 6 27 2 8 29 30
31 use=
11 <?xml version="l.O"?> 12 < ! - - edited with XML Spy "4.4 U (http://www.xmlspy.com) by iscage
14 <xsd:schema targetNamespace="http://castor.exolab.org/Test/Invoice" (cenidetl -->
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:nsl="http://castor.exolab.org/Test/Invoice"~
15 <xsd:element name="invoice"> 16 <xsd:complexType> I7 <xsd:sequence> I8 <xsd:element ref="nsl:customer"/> I9 <xsd:element ref="nsl:item"/> 10 </xsd:sequence> 11 <xsd: attribute name="id" type="xsd: string"
12 </xsd:complexType> </xsd:element> < ! - - Description of a customer --> <xsd:element name="cuStomer">
<xsd:complexType>
use="required"/>
<xsd:sequence> <xsd: element name="name" type="xsd: string"/> <xsd: element name="phone" type="xsd: string"/>
</xsd:sequence> </xsd:complexType>
</xsd:element> < ! - - Description of an item --> <xsd: element name="item">
<xsd:complexType> <xsd:sequence>
<xsd: element name="Q>uantity" type="xsd: float"/> <xsd: element name="Price" type="xsd: float"/>
</xsd:sequence> <xsd:attribute name="Id" type="xsd: string''
squired"/> <xsd: attribute name="Category" type="xsd: string"
use="required" /> 32 </xsd:complexType>
17
V Casos de Prueba
;I
33 </xsd:element> 34 </xsd:schema>
Fig. 5n. Esquema de XML de entrada (invoice.xsd)
,I SALIDAS:
Carpeta: invoice (es el package que contiene la declaración de clases que fue generada). Los archivos que contiene son: Customer. java, i n v o i c e . java, item. j ava; estos archivos representan elementos del esquema de XML.Tarnbien Contiene los archivos: invo ice .x , sd y Main. java, ODMG. java; que Son las clases necesarias para poder realizar el almacenamiento en la base de datos. Carpeta: xml-base (es donde están los datos de la base de datos). Carpeta: xmldict (es donde está el esquema de la base de datos). Archivo: ptj.opt (es el archivo de configuración requerido por la base de datos).
7 '
.- L,.I inyoice
Fig. 50. Archivos de la carpet& Ej5 después de ejecutar el traductor
i, ANÁLISIS DE RESULTADOS:
A continuación se muestra la base de datos vacía sólo con'su esquema:
l i . .. i .,.
7 8
'I
V Casos de Prueba
Fig. 5p. Objetos sin datos vistos con la herramienta Fastobjects Developer
A continuación se muestra el documento de XML invoice.xmi y la base de datos después de haber ejecutado la clase para almacenar los elementos del documento de XML:
O1 <?xrnl version="l . O " ? > 0 2 < ! - - edited with XML Spy "4.4 U (http://www.xmlspy.com) by iscage
(cenidetl --> 04 <invoice id="1234"> 05 <customer> 06 <narne>Ryan Madden</name> 07 <~hone>650-345-2777</~hone~ O8 </customer> o9 <itern Id="O. 9.3" Cateqory="Open Source Project"> 10 <Quantity>l</Quantjty> 11 <Price>lOO.OO</Price> 12 </ i tern> 13 </invoice>
Fig 59 Documento de XML de entrada (invoice xml)
7 9
V Casos de Prueba
Fig. 5r. Objetos con datos vistos con la herramienta Fastobjects Developer
CONCLUSIONES I
En este capítulo se exponen de manera resumida las funciones de la herramienta desarrollada, así como los beneficios que aporia, los resultados obtenidos y algunos trabajos futuros para continuar con la línea de XML y bases de datos.
VI Conlusiones
6.1. Conclusiones generales
El proyecto de tesis consistió en el"desarrollo de una herramienta que realiza la creación automática de un esquema de base de datos orientada a objetos para el almacenamiento de documentos de XML. Esta herramienta colabora para que un servidor de documentos de XML pueda almacenar los documentos de XML en una BDOO. Como parte del esquema para la base de datos orientada a objetos, se crea un conjunto de declaraciones de clase en Java y un archivo de configuración que requieren las aplicaciones generadoras de la base de datos orientada a objetos.
6.2. Beneficios
La herramienta está programada en lenguaje Java, obteniendo por ello beneficios como: ser utilizada por cualquier aplicac/ón programada en Java (la mayoria de las herramientas para el manejo de documentos de XML están programadas en Java), el lenguaje Java es el más popular para aplicaciones sobre internet y es multiplataforma.
La definición de clases generada es empleada por una base de datos orientada a objetos cuya definición de esquema es mediante clases en Java.
Se puede realizar la traducción de los esquemas que cumplan con la última
La herramienta contribuye al proceso de almacenamiento de documentos de XML en una base de datos. Y puede ser implementada dentro de alguna aplicación que lleve a cabo todo el proceso. Y en especifico para el "Servidor de XML para aplicaciones W e b desarrollado como tema de tesis en el Cenidet.
versión de la descripción formal que el W3C ha publicado a la fecha.
La documentación y manuales estan escritos en espaiiol, y aportan una base y un antecedente sobre XML y bases de datos para que estudiantes del Cenidet continúen investigando sobre esta linea, ya que empresas líderes fabricantes de bases de datos y de desarrollo como Borland-lnprise. Sun Micosystems, Microsoft, Oracle, entre otras muchas, están dando soporte en sus productos y utilizando la tecnología XML, además de ser el estándar empleado para el comercio electrónico, lo que nos hace pensar que en un corto plazo los documentos de XML serán, más populares de lo que lo son ahora.
6.3. Resultados obtenidos
A continuación se listan los resultados obtenidos con el desarrollo de esta tesis:
Se obtuvo la gramática de los esquemas de XML en EBNF.
Se obtuvo un analizador Iéxico;sintactico que forma parte de la herramienta generadora de esquema de BDOO. Este analizador verifibará que los esquemas de XML que trate de traducir la herramienta cumplan con las reglas Iéxico- sintáticas propuestas por el W3C.[
Se obtuvo un traductor de esquemas de XML que forma parte de la herramienta generadora de esquemas de BDOO. Este traductor mediante la API de DOM
8 2
VI Conlusiones
analizara el esquema de XML y realizará el proceso de unmarshalling para obtener las declaraciones de clases en Java y un archivo de configuración para la BDOO
6.4. Trabajos futuros
Continuar con el desarrollo de la herramienta para que realice las traducciones de los elementos de los esquemas de XML que en esta primera versión fueron omitidos.
Desarrollar una interfaz gráfica que permita seleccionar el esquema de XML a traducir, realizar el proceso de generación del esquema de la BDOO e insertar un documento de XML a la BDOO
Agregar módulos a la herramienta que permitan realizar la operación contraria es decir, la traducción del esquema de la BDOO a un esquema de XML (Marshalling).
8 3
Listado de versiones publicadas de esquemas de XML
1) Recomendac.on ael W3C ael2 oe Mayo de 2001 nit0 //w w3 or~/TR/2001/REC-xm schema-1 -20010502/
2) Recomendacion propdesia de W3C de, 30 Marzo oe 2001 -p lNvww w3 orq/TR/2001/PR-xrnlschema-1-20010330/
3) Recomendacon propLesta oel W3C ael 16 de Marzo de 2001 htlD //w w3 ora/TR/2001/PR-xmlschema-1-20010316/
Anexo A: Listado de versiones publicadas de esquemas de XML
4) Recomendación candidata del W3C del 24 de Octubre de 2000 htt~://w.w3.or~lTR/2000/CR-xmlschema-1-20001024/
5) Borrador de trabajo del W3C del 22 de Septiembre de.2000 htt~://w.w3.orqlTR/2000/WD-xmIscherna-1-20000922/
6) Borrador de trabajo del W3C del 7 de Abril de 2000 htt~://w.w3.orqlTR/2000/WD-xmlschema-1-200004071
7) Borrador de trabajo del W3C del 25 de Febrero de 2000 http://w.w3.orq/TR/2000/WD-xrnIschema-l-20000225/
8) Borrador de trabajo del W3C del 17 de Diciembre del999 http://w.w3.orqlTR/1999/WD-xmlscherna-l-l999l217/
9) Borrador de trabajo del W3C del 5 de Noviembre de 1999 http://w.w3.orq/TR/1999NVD-xrnlscherna-l-19991105/
10) Borrador de trabajo del W3C del 6 de Mayo de 1999 http://www.w3.orq/l999/05/06-xmlschema-1/
8 5
Lexemas de la gramática de los esquemas de XML
> I, < 11 <STAGO: <ETAGO: "< / " > <PCDATA : ( - [ " < " I ) + >
<ALL: (<?REFIX>) ? "all"' > <ANNOTATION: (<PREFIX>) ? "annotation" > <ANY: (<PREFIX>) ? "any" > <ANYATTRIBUTE: (<PREFIX>) ? "anyattribute" > <AP?INFO: (<PREFIX>) ? "appinfo" > <ATTRIBUTE: (<PREFIX>) ? "attribute" > <ATTRIBUTEGROUP: (<PREFIX>) ? "attributegroup" >
Anexo B: Lexemas de la gramática de los esquemas de XML,
<COMPLEXCONTENT: (COMPLEXTYPE: <CHOICE: <DOCUMENTATION: <ELEMENT : <ENUMERATION: <EXTENSION: <FIELD: <FRACTIONDIGITS: <GROUP: <INCLUDE: <IMPORT : <KEY: <KEYREF: <LENGTH : <LIST: <MAXLENGTH: <MAXEXCLUSIVE: <MAXINCLUSIVE: <MINLENGTH: cMINEXCLUSIVE: <MININCLUSIVE: <NOTATION: s <PATTERN: <REDEFINE : <RESTRICTION: CSCHEMAXML: <SELECTOR: <SEQUENCE: <SIMPLECONTENT <SIMPLETYPE: <TOTALDIGITS: <UNION: <UNIQUE : <WHITESPACE:
<TAGC: <TAGC-: <EQ: <DOS-P: <PUNTO: <GUIONB: <GUIONA: <XMLNS-: <XMLNS :
<DIGIT: <LETTER: CNCNAMECHAR: <PREFIX:
CABSTRACT :
(<PREFIX>) ? (<PREFIX>) ? (<PREFIX>) :? (<PREFIX>) ? (<PREFIX>) ? (<PREFIX>) ? (<PREFIX>) ? (<PREFIX>)? (<PREFIX>) ?
(<PREFIX>) ? [<PREFIX>) ? (<PREFIX>) ? (<PREFIX>) ? (<PREFIX>) ? (<PREFIX>) ? (<PREFIX>) ? [<PREFIX>) ? (<PREFIX>) ?
(<PREFIX>) ? (<PREFIX>) ? (<PREFIX>) ? (<PREFIX>)? [<PREFIX>)? (<PREFIX>) ? (<PREFIX>)? (<PREFIX>) ? (<PREFIX>),? (<PREFIX>) ? (<PREFIX>) ? (<PREFIX>) ? (<PREFIX>) ? (<PREFIX>) ? [<PREFIX>) ?
">" " /> "
[ : I' I
(<PREFIX> ) ' ?
(<PREFIX>)'?
71- 11 -
I, e1
1, !, 1, t1 -
"xmlns : '' " xmlns ''
, " ~ " - " 9"1
"complexcontent" > >
"choice" > "documentation" > '"element " z "enumeration" > "extension" > "field" > " f ract iondiqits" >
" compl ext ype f 1
"group" "include" "import" "key" "keyref" "length" "list " "rnaxlength" "maxexclusive" "maxinclusive" "minlength" "minexclusive" "mininclusive" "notation" "pat tern" "redefine" ',restriction" "s cherna '' f 1 select or '' "sequence" "simplecontent" "simplet ype " "totaldigits" "union" "unique " "whitespace"
> > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > 1 "a" - " " I "A" - "
" I > <LETTER> 1 <DIGIT> " . " 1 " " I "-"
(<LETTER> I <GUIONB> ) (<NCNAMECHAR>)* <DOS - P> >
> "abstract " <ATTRIBUTEFORMDEFAULT: "attributeformdefault" >
"base" > <BASE: <BLOCK: "block " > <BLOCKDEFAULT: "blockdefault" >
8 7
Anexo B: Lexemas de la gramática de los esquemas de XML
<DEFAUL : <ELEMENTFORMDEFAULT <SCHEMALOCATION: <FINAL : <FINALDEFAULT: <FIXED: <FORM: <ID: <ITEMTYPE: <PROCESSCONTENTS: <PUBLIC : <MAXOCCURS: <MEMBERTYPES: <MINOCCURS: <MIXED: <NAME: <NAMESPACE: CNILLABLE: <REF: <SOURCE : <SUBSTITUTIONGROUP: <SYSTEM: CTARGETNAMESPACE: <TYPE: <VERSION: <XMLLANG : <XPATH: <USE: <VALUE:
"default" "element forrndefaul t " "esquemalocation" " fina 1 " " f inaldef aulp" "fixed" f orrn f 1
"id" "iterntype" "processcontents" "public" "rnaxoccurs" ,) "membert ypes '' "minoccurs" "mixed" "name "namespace" "nillable" "ref " "sorce" "substitutionGroup" " system" "targetnamespace" 'It ype ', "version" "xrnl: lang" 11 " xp a t h " "us e e t
'*va 1 u e 'I
11
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
8 8
Reglas de la gramática de los esquemas de XML
NOTA: Sólo se implementaron para la traducción de esquemas las reglas gramaticales que se encuentran con letra negra, las reglas con letra cursiva fueron omitidas. Sin embargo todas las reglas fueron consideradas para el análisis léxico-sintáctico.
ncName : : =
Anexo C : Reglas de l a gramática de esquemas de XML
* 2 . Schema Declaration
ittListSchema::= ! (nsAttName ( ) <EQ> attValue [ ) ) I [ ( < I D > 1 <ATTRIBUTEFORMDEFAULT> I <BLOCKDEFAULT> I <ELEMENTFORMDEFAULT> I <FINALDEFAULT> I <TARGETNAMESPACE> I <VERSION> 1 <XMLLANG>) <EQ> attValue ( 1 )
) + .chxml : : = [ <STAGO> ISCHEMAXML> [ attLLstSchema0 1
<TAGC>] [annotation [ ) ) * ( include0
1 redefine0 I annotation ( ) ) * ! í í sifpletype [ )
I import0
I complextype [ ) 1 group ( ) I attributegroup () 1
I elemento I attribute [ ) 1 not,ation 0 1 [ annotation ( ) ]
) * [ <ETAGO> <SCHEMAXML> <TAGC>]
ittListInclude::= ( ( < I D > I <SCIfEMALOCATION> I <En> attvaiue 0
~
httListRedefine::= ( ( C I D ? 1 <SCHEMALOCATION> I <EQ> at tVal ue (I 1 ,
edefine::= <STAGO> <REDEFINE> [ attlist0 I <TAGC>
90
Anexo C: Reglas de l a gramática de esquemas de XML
3 . Simple Data Type Declaration
( annotation i ) ) ? ( restriction i ) I l l S t 0 1 union0
~ ~~ ) + ~. restriction::= <3TAGO> <RESTRICTION> [ attlist0 I <TAGC>
[ annotation0 1 ( [ simpletype í ) I
, ( minexclusive() I mininclusiveo I maxexclusive0 I maxinclusiveo
length0 I minlength0 1 totaldigitso 1 fractiondigitso I
I maxlenqth ( ) I enumeration ( ) I whitespace í 1 1 pattern0 I ) *
[ annotation O I [ slmpletype O I
* 4 . Complex Data Type Declaration * _II
AttListComplexType: := ( ( C I D > I <ABSTRACT> 1 <BLOCK> 1 <FINAL> I <MIXED> I <NAME> ) <EQ> attValU-20
, I complexcontento
91
Anexo C: Reglas de la gramática de esquemas de XML
I attributegroupCDT0
IanyattributeCDTO I
<ETAGO>,,<COMPLEXTYPE> <TAGC>
* * * * * * 'Complexcontent ******
LttListComplexContent::= ( (<IO> I <MIXED> ) CEQ> at t Val ue O ) +
( annotation()) ? ( restrictionC0 I extensionCO J
omplexcontent::= CSTAGOl <COMPLEXCONTENT> [ a ttlist 0 I <TAGC> 'I
<ETAGO> <COMPLEXCONTENT> <TAGC> I
ittListReStrictionC: := ((<ID> I <BASE> ) <Ea> attValue0 ) +
( annotation () ) ? i f group0 I a 1 1 0 I choice0 I sequence0
( I a'ktributeO
estrictionC::= <STAGO> <RESTRICTION> i attlist 0 I CTAGCZ
I attributegroupCDT0 ) * (anypttributeCDT()) ?
) ) <ETAGO> <RESTRICTION> <TAGC>
1 ttListExtensionC::= ((<ID> I <BASE> ) <EQ> attValue0
l + <TAGC I> I (
xtensionCp::= -
<TAGC> I an'notation() ) ?
í I i:groupO I a l l 0 1 choice0 I sequence0
( at tribute () I attributegroupCDT0
lanyattributeCDT0) ?
I 'I
I * I!
Anexo C: Reglas de la gramática de esquemas de X M L
* * * * * * Simplecontent * * * * * * .~
t t L i s t S i m p l e C o n t e n t : : = (<ID> <EQ> a t t V a l u e O I + .p .. .. . . . . . . , ,
i m p l e c o n t e n t : : = <STAGO> <SIMPLECONTENT> I a t t l i s t O I <TAGC> ( a n n o t a t i o n ( ) ) ? ( restr ic t ions ( I I ex t ens ions 0
I <ETAGO> <SIMPLECONTENT> < T A G 0
t t L i s t R e s t r i c t i o n S : : = ((<ID> I <BASE> I <En> a t t V a i u e O
e s t r i c t i o n S : : = <STAGO> < R E S T R I C T I O N > [ a t t l i s t O I < T A G 0 ( a n n o t a t i o n ( I I ? ( s i m p l e t y p e 0
, ) + . . . . . . , _ . . ~~ .
( m i n e x c l u s i v e ( I I m i n i n c l u s i v e ( I I m a x e x c l u s i v e O 1 m a x i n c l u c i v e í ) 1 t o t a l d i g i t s ( I I f r a c t i o n d i g i t s O I l e n g t h 0 I m i n l e n g t h O 1 m a x l e n g t h í ) I e n u m e r a t i o n ( ) I w h i t e s p a c e 0 I
I * p a t tern O
I ? ( ( a t t r i b u t e 0
I a t t r i b u t e g r o u p C D T O I * ( a n y a t t r i b u t e C D T 0 ) ?
1
,) + <STAGO> <EXTENSION> [ a t t l l s t ( ) I <TAGC> ( a n n o t a t i o n 0 I ? ( ( a t t r i b u t e 0
. x t e n s i o n S : :=
I a t t r i b u t e g r o u p C D T 0 I * ( a n y a t t r i b u t e C D T O I ?
I <ETAGO> <EXTENSION> <TAGC>
ittListAttributeGroupCDT: := ((<ID> I <REF> I <EQ> a t t V a l L J e 0 I +
i t t r i b u t e a r o u D C D T : : = <STAGO> <ATTRIBUTEGROUP> I a t t l l s t f ) I <TAGC> ( a n n o t a t i o n 0 I ? <ETAGO> <ATTRIBUTEGROUP> CTAGC>
X t L i s t A n y A t t r i b u t e C D T : : = ((<ID> I <NAMESPACE> I <PROCESSCONSENTS>i <En> a t t V a l u e 0
93
Anexo C: Reglas de la gramática de e,squemas de XML
5. Model Group Definition *
[ annotation0 I ( all0 1 choice0 1 sequence0
<ETAGO> <GROUP> <TAGC>
( annolation ( ) ) ? ( element ( ) ) * <ETAGO> <ALL> <TAGC>
* 6. Attribute Group Definition * *
]AttListAttibuteGroup::= 1
i annytation () 1 '
I ( attributef) 1 attributegroup0
I * [anyattributeCDT () I
) I <ETAGO> <ATTRIBUTEGROUP> <SAGC>
* 7. Element Declaratxon
AttLlstElement::= ( ( < I D > I <ABSTRACT> I <BLOCK> 1 C D E F A U D I <FINAL> I <FIXED> I <FORM> I <MAXOCCURS> I <MINOCCURC> I , <NAME> I <NILLABLE> I <REF> 1 <SUBSTITUTIONGROUP> 1 <TYPE>) <EQ> attValue0 ) + <TAGC > I 1, I
- element : : = -
<TAGC>( annotation0 ) ? ( ( simpletype ( )
I Complextype ( ) ) ? I unique 0
94 I!
Anexo C: Reglas de l a gramática de esquemas de XML
)<ETAGO> <ELEMENT> <TAGC>
8 . Model Group (content model) *
AttListChoice::= ((<IO> I <MAXOCCURS> I <MINOCCURS>) <EQ> attValue ( ) ) +
Choice : : = <STAGO> <CHOICE> [ attlist0 1 <TAGC> ( annotation0 I ? ( element0 I group0 I choice0 I sequence0 I a n y 0 ) * <ETAGO> <CHOICE> <TAGC>
AttListSequence::= ((<ID> I <MAXOCCURS> I <MINOCCURS>) <EQ> attValue ( )
' 3 I i
Seouence::= <STAGO> <SEQUENCE> [ attlisto 1 <TAGC> ( annotation ( ) ) ? ( element O I group0 I choice0 I sequence0 I a n y 0 i * <ETAGO> <SEQUENCE> <TAGC>
AttListAnv: := ((<ID> 1 <MAXOCCURS> 1 <MINOCCURS> I <NAMESPACE> I <PROCESSCONTENTS> ) <Ea> a t t Val ue f ) ,) +
Any::= <STAGO> <ANY> [ a t t l l s t f ) I < T A G 0 ( a n n o t a t i o n f ) ) <ETAGO> <ANY> < T A G 0
* 9. Attribute Declaratlon *
) + <TAGC > I (<TAGC> (annotation ( 1 )
attribute_::= -
~ (simpletypeO)? <ETAGO> <ATTRIBUTE> <TAGC>
1
attribute O Attribute::= <STAGO> <ATTRIBUTE> [ attiisto 1
h e x o c : Reglas de l a gramática de esquemas de XML
1 0 , ~ N o t a t i o n Declaration *
* * 11. h o t a t i o n Component
documentat ion
a I S
lpcda ta O i *
* * 12. Identity-constriant de f in i t ion *
+
( selector0 I I f i e l d i ) ) +
<STAGO> <KEYREF> [ attlist0 I < T A G 0 ( a n n o t a t i o n ( ) ) ? ( selector0 i í f i e l d í ) ) +
96
Anexo C: Reglas de la gramática de esquemas de X M L
[ annota t ion O I
97
- .~..* !.
..
DOM Modelo de Objeto de Documento (Document Object Model). Una interfaz neutral al lenguaje y a'la plataforma originariamente creada por Microsoft, que proporciona un acceso dinámico a la estructura interna de los documentos de Web. Definición de Tipo de Documentos (Data Definition Type). La solución tradicional a la estructuración de documentos de XML heredada de SGML. Las DTDs se suelen usar para crear un modelo de datos para los documentos de XML, lo que permite validar estos documentos. Intercambio de Datos Electrónico (Electronic Data Interchange). Conjunto complejo de estándares y tecnologiac para automatizar el intercambio de documentos de negocios de datos estructurados entre dos aplicaciones.
DTD
E D 1
98
HTML
SAX
SGML
URI
URL
w3c
www
XLL
XML
XCL
Lenguaje de Marcado de Hipertexto (HyperText Markup Language). El lenguaje de marcado que sirve como estándar de publicación en la Web. En su forma actual (versión 4.0), HTML es una aplicación de SGML. pero la recomendación XHTML del W3C altera HTML para que sea una aplicación de XML. API Simple para XML (Simple API for XML). Una interfaz de programación estándar diseñada para analizar sintácticamente documentos de XML a través de una arquitectura basada en eventos. Lenguaje de Marcado Generalizado Estándar (Standar Generalized Markup Language). La primera tecnologia importante sobre información estructurada normalizada, que fue creada como resultado de un trabajo hecho por IBM para ofrecer una forma de formatear y mantener documentos estructurados, como documentos legales. XML es un subconjunto simplificado de SGML, que está orientado a la Web. ldentificador Universal de Recursos (Uniform Resource Identifier). Conjunto de nombres y direcciones genéricas para referirse a recursos. Localizador Universal de Recursos (Universal Resource Locator). Un estándar para escribir una Única referencia de texto para una pieza de datos en el WWW. Consorcio de Internet (World Wide Web Consortium). Es un consorcio internacional de compañias encargado de desarrollar estándares abiertos con el fin de que la Web se encamine en una única dirección. Web (World Wide Web). La Web es una red de recursos de información. Se basa en tres mecanismos para hacer los recursos disponibles a la audiencia:
Un esquema uniforme de localización de recursos de información (ej. URls). Protocolos, para el acceso a los nombres de los recursos a través de la red (ej. HTTP). Hipertexto para la fácil navegación a través de los recursos (ej. HTML).
Lenguaje de Vínculos Extensibles (extended Link Language). El nombre anterior de la tecnología XLink, que proporciona un mecanismo avanzado para vincular documentos de XML. Lenguaje de Marcado Extensible (extensible Markup Language). Un subconjunto simplificado de SGML que incorpora muchas opciones de SGML, incluyendo la extensibilidad, la estructura y la validación. XML representa una nueva era en la Web, estableciendo un modo de transmitir datos estructurados. Lenguaje de Hoja de Estilo Extensible (extensible Stylesheet Language). Una tecnologia de hojas de estilo que soporta la transformación de documentos de XML de un tipo a otro, as¡ como los estilos de los documentos de XML en base a las reglas de formato estructurado. XSL ejecuta estos dos aspectos de la presentación de documentos de XML a través de dos tecnologias distintas: XSLT y Objetos de Formato XSL.
Glosario: Términos y abreviaturas
9 9
[I1 A. V. Aho, R. Sethi, J. D. Ullman, compiladores: Principios, técnicas y herramientas, Addison-Wesley, 1998.
http://xml.apache.orq/-andvc/xerces2/architecture. html, Dic. 2002.
Compiler Tools, "The Lex & Yacc Page", http://dinosaur.compilertools.net/, Mar. 2003,
[21 Apache, "Project Apache, Xerces2 Architecture, 2001",
[31
[ 4 1 Datachannel, "Datachannel Server 2001", http://www.datachannel.com/products/dcs4.htmI il
Dic. 2002.
100
Referencias
[ 51 Exolab.org, "The Castor Project, 2000, http://castor.exolab.orq/index.html Dic. 2002.
[ 6 1 R. L. González Urbieta, Servidor de Documentos XML para aplicaciones web, tesis de maestria. Depto. de Ciencias Computacionales. CENIDET, Cuernavaca. Mor., Ago. 2001.
171 J. Jaworski, Java 1.2. Aldescubierto, la edición, Prentice Hall 1999, pp. 547-638.
[ 8 1 O. L. Lechuga Gomez, "Tutorial sobre XML", http://Face.el.uma.es/imasd/xml.xml.html, Mar. 2003.
[ 91 Microsoft, "Component Object Model: Technical Overview, 2001", http://www.microsofi.com/com/wpaper/com modl.asp, Dic. 2002.
[ l o 1 M. Morrison et al., XMi a l descubieflo, ed. Prentice Hall 2000 pp. 456
[ 11 1 Object Management Group (OMG) , "CORBNIIOP 2.2 Specification,l998". http://www.omq.orq/corba/corbaiiop.html, Dic. 2002.
[ I 2 1 Percusión Software, "Tech Specs - XML Integration ~ Rhythmyx - Percussion, 2001", httP://www.Percussion.com/Products/Rhvtmvx/ rhythmyxover. htm, Dic. 2002.
[ I 3 1 J. Pinnock et al. ProfessionalXML2a ed. WROX2001, pp. 812
I 1 4 1 N. Rishe, Database Desing, Ed. Mc-Graw Hill 1992. pp. 339-354
[151 J. Robie, D. Bartels, A comparison between relational and object oriented databases for object oriented application development, POET Software GMBH.
I 1 6 1 Sequoia Software Corp., "XPS Portal Software Features and Benefits - Sequoia Software, 2001", http://www.sequoiaw.com/xps/index.asp, Dic. 2002.
[ 17 I Software AG, "Tamino XML DataBase, 2001", http://www.softwareaq.com/tamino/. Dic. 2002.
[181 Sun Microsystem, "Code Fast, Run Fast with XML Data Binding by Erick Armstrong". http://iava.sun.com/xml/iaxp/dicVl .O.l/docs/bindinq/DataBindinq. html, Dic. 2002.
I
I 1 9 1 Sun Microsystems, "Java Architecture for XML Binding User's Guide", http://Java.sun.com/xml/iaxb/iaxb-docs.pdf, Mar. 2003.
1201 Sun Microsystems, "Java Architecture for XML Binding (JMB) Ed Ort and Bhakti Mehta", http://developer.iava.sun.com/developer/technicalArticlesNVebServices/iaxb/, Mar. 2003.
[ 2 1 I Sun Microsystems, "XML Technologies, JavaTM Architecture for XML Binding (JAXB)", http://iava.sun.com/xml/iaxb/. Mar..2003.
[221 E. van der Vlist, "JAXB or W3C XML Schema 'a la Carte'?" , http://www.xmlhack.com/read.php?item=l784, Dic. 2002.
[ 2 3 1 W3C, "Document Object Model (DOM) Level 3 Core Specification Version 1.0, W3C Working Draft 26 February 2003, http://www.w3.ora~R/2003NVD-DOM-Level-3-Core-20030226/, Mar. 2003.
[ 2 4 I W3C. "Extensible Markup Language 1.0., W3C Recommendation 6 October 2000,
[ 251 W3C, "Extensible Stylesheet Language (XSL) Version 1 .O recommendation",
http://www.w3c,orq/TR/200O/REC-xml-20001006, Dic. 2002.
http://www.w3c,orq/TR/1998/WD-xsl-19980818, Dic. 2002.
1 0 1
Referencias
I,
[ 2 6 1 W3C, "HyperText Markup Language Version 4 O (HTML) Recommendation 1998, http //w w3.orqírR/1998/REC-htin140-19980424/, Dic 2002
[ 27 1 W3C. "Namespaces in XML 14-January-1999, http //w w3 orqTTR/REC-xml-names, Dic 2002
11
128 1 W3C, "Overview of SGML Resources", http://w.w3.0rq/MarkUp/SGML/, Dic. 2002.
í 2 9 1 W3C. "XML Linking Language (XLink) Version 1 .O W3C Recommendation 27 June 2001", http://www.w3.orq¡TR/xIink/, Dic. 2002.
[301 W3C, "XML Schema", h~p://w.w3.orq/;rR/xmlschema-1/. Dic. 2002.
[ 3 1 1 W3C, "XPath XML Path Lenguage W3C Recommendation 16 November 1999, http://w.w3.0rqírR/xpath/, Mar. 2003. ,,
'!
[ 32 1 W3C, "XPointer xmins() Scheme W3C Recommendation 25 March 2003, http://www.w3,orq¡TR/xptr-xmlnsl, Mar. 2003.
[ 331 Zeus, "Open source Java/XML Data binding", http://zeus.enhvdra.org, Dic. 2002 '1
1
102
'I I.. ,
A. V. Aho, R. Sethi, J. D. Ullman, Compiladores: Principios, técnicas y herramientas, Addison-Wesley, 1998.
D. Ayers et.al., Profesional Java Data, WROX 2002, cap. I O . ' -:
E , Bertino & B. Catania, "lntegrating XML and Databases", IEEE Internet computing Magazine, July-August 2001, pag 84
' - . / - ,
103
Biblioarafia
R. Bourret, "Mapping W3C Schemas to Object Schemas to Relational Schemas. March 2001". http://w.rpbourret.com/, Jun. 2002.
R. Bourret, "XML and Databases, 2001", http://www.rpbourret.com/xml/XMLDatabaseProds.htm, Jun. 2002.
B. McLaughlin, Java y XMi , O'Reilly, 2001
M. Morrison, XML A/ Descubierto, la edición. SAMs Prentice Hall, 2000, cap. 5.
J. Pinnock et al., ProfessionalXML, 2a edición, hROX, 2001, cap. 15.
N. Rishe. Database Desing, Ed. Mc-Graw Hill, 1992, Cap, 10
104
.. .. - - ~~
- .. . . . . . . . .. . . . . . . . . . . . -.
