vdocxml: Un Modelo de Versionado Ramificado para Documentos XML Tesis Doctoral Luis Jesús Arévalo Rosado

Transcripción

1 vdocxml: Un Modelo de Versionado Ramificado para Documentos XML Tesis Doctoral Luis Jesús Arévalo Rosado Presentada para optar al título de grado de Doctor por la Universidad de Extremadura Dirigida por el Dr. D. Antonio Polo Márquez Titular de Universidad del Área de Lenguajes y Sistemas Informáticos Departamento de Ingeniería de Sistemas Informáticos y Telemáticos Universidad de Extremadura Mérida, a 15 de septiembre de 2009

2 Edita: Universidad de Extremadura Servicio de Publicaciones Caldereros 2. Planta 3ª Cáceres Correo e.:

3 Resumen La realidad de los sistemas de información actuales es que la mayoría no están provistos de herramientas automáticas capaces de gestionar la evolución de su información, pues cuando se producen los cambios estos sistemas sobrescriben los antiguos valores de los datos con los nuevos. Esta situación impide que puedan realizarse consultas por valores antiguos, obtener la información válida para una versión dada o monitorizar los cambios. Sin embargo, la vida actual demanda sistemas que contemplen en modo nativo la capacidad de detectar, representar y almacenar el ciclo de vida de los datos, es decir, sus distintos estados o versiones, a n de gestionarlos ecientemente de forma cómoda y transparente para el usuario. Entre los distintos tipos de documentos existentes, en este trabajo hemos decidido abordar la gestión de cambios en documentos XML, pues se ha convertido en el medio predominante para el intercambio de información en la web y cada vez son más las aplicaciones que lo utilizan para almacenar su información. En la actualidad la gestión de versiones de documentos XML se puede llevar a cabo principalmente mediante dos soluciones: las técnicas tradicionales adaptadas para documentos XML que se encargan de obtener las diferencias entre dos documentos XML, o añadiendo información temporal a cada uno de los elementos XML. Sin embargo, la primera de ellas no permite las consultas históricas sobre los documentos versionados y la segunda, debido a la naturaleza lineal del tiempo, no tiene soporte para versionado ramicado. En esta tesis se propone un modelo de datos, denominado vdocxml, junto con una implementación, que solventa ambos problemas: la gestión de versiones ramicadas de documentos XML y las consultas históricas. El desarrollo de este modelo comienza con un modelo de datos genérico para documentos, denominado vdoc, donde se utiliza un grafo de tipo árbol para establecer la relación entre las versiones del documento. Sobre él hemos denido las operaciones básicas de todo sistema de versionado: crear un documento de versionado, añadir una versión, borrar una versión y obtener la información de una determinada versión; estas operaciones constituyen el álgebra operacional de un documento versionado. El modelo vdocxml es una aplicación de este modelo vdoc para documentos XML y su implementación se ha realizado en base a documentos vxml. Un documento vxml integra en un único chero un conjunto de versiones de un documento XML. Para conseguir este objetivo es necesario representar las versiones denidas en él, así como establecer la validez de cada uno de los componentes XML incluidos en el documento. Así, un documento vxml se encuentra constituido por dos partes: la primera representa dentro del propio documento información de cómo éste ha ido evolucionando a lo largo del tiempo (árbol de versionado), y se corresponde con el grafo de derivación del modelo vdoc; la segunda consiste en denir para cada elemento XML las versiones en la cuales dicho elemento es válido con respecto al árbol III

4 de versionado (validez de versionado). Este último proceso de marcado permite identicar fácilmente cada una de las versiones del documento XML. De este modo el modelo vxml constituye el núcleo del modelo vdocxml, pues es el encargado real de representar, gestionar y consultar las versiones de un documento XML. La principal ventaja de un documento vxml es la facilidad para representar versionado ramicado de documentos XML, pues almacenamos en el propio documento el grafo de derivación y se meta-etiqueta cada componente XML susceptible de cambio en base a este árbol de versionado. Además, el modelo propuesto no necesita ningún requerimiento adicional pues su denición se ha realizado ajustándose a la especicación W3C, lo que garantiza de este modo su uso en cualquier procesador XML (XQuery/XSLT). El hecho de mantener todas las versiones en un único chero, no es sólo por razones de almacenamiento o para evitar la replicación, sino que también nos permitirá optimizar el procesamiento de consultas sobre cada elemento respecto de las versiones en las que aparece. Por este motivo, nuestros documentos XML versionados pueden ser consultados mediante distintos estándares XML de consulta; concretamente mediante XPath, XQuery y XSLT. La implementación de estas operaciones de recuperación se ha realizado en base a funciones de usuario XQuery, extendiendo este lenguaje para operar sobre vdocumentos. Basándonos en el modelo vdocxml hemos desarrollado un sistema de versionado a partir de dos librerías de versionado codicadas en XQuery y XSLT respectivamente, cuya principal virtud es su portabilidad. Esta característica se debe a que hemos centrado nuestro esfuerzos en el uso exclusivo de tecnología XML para su implementación siguiendo las recomendaciones del W3C. Con el objetivo de vericar su funcionamiento se ha integrado la librería de versionado XQuery en una base de datos nativa XML (exist), es decir, se ha extendido una base de datos nativa XML con soporte nativo para el versionado de documentos XML. Además se ha probado la API de versionado denida mediante el desarrollo de distintas interfaces para la gestión de versiones. Finalmente sobre esta implementación se han realizado distintos experimentos para vericar el rendimiento del modelo de versionado. Los resultados obtenidos con el algoritmo optimizado se encuentran muy próximos a los obtenidos para representaciones XML temporales, por lo que nuestro modelo permite extender de forma eciente el versionado lineal a un versionado ramicado de documentos XML. IV

5 Índice general I El Problema de la Gestión de Versiones 1 1. Introducción Introducción Motivaciones Ejemplo de Necesidades en un Dominio de Gestión de Versiones Funcionalidades de un Sistema de Gestión de Versiones Limitaciones de las Soluciones Actuales Objetivos de esta Tesis Guía de Lectura Estado del Arte Gestión de Cambios y Gestión de Versiones Conceptos Previos: Versión Versionado Lineal Versionado Ramicado Conclusiones Gestión de Cambios en Sistemas de Ficheros Gestión de Cambios en Bases de Datos Bases de Datos Relacionales Bases de Datos Orientadas a Objetos Gestión de Cambios en Documentos Semi-Estructurados Gestión de Cambios en Documentos XML Tecnología XML Documentos XML Otros Estándares XML Delta XML Documentos XML Temporales Versionado Ramicado en Documentos XML Versionado de Esquemas Conclusiones II Modelo de Versionado de Documentos XML: vdocxml Modelo de Documentos Versionados vdoc Modelo de Datos de Documentos Versionados vdoc V

6 3.2. Operaciones Básicas sobre Documentos Versionados vdoc Creación de un Documento Versionado vdoc Inserción de una Versión como Derivada de Otra Borrado de una Versión sin Versiones Hijas Revisión de las Operaciones sobre Documentos de Versionado Creación de un Documento Versionado vdoc Creación de un Documento Versionado vdoc a partir de un Documento Creación de un Documento Versionado vdoc a partir de un Conjunto de Documentos Obtención del Documento Asociado a una Versión Inserción de Versiones Inserción de una Versión entre dos Existentes Cambio del Padre de una Versión Borrado de Versiones Borrado de una Versión con Versiones Hijas Extensión de Operaciones sobre Documentos de Versionado Sustitución de Versiones Poda de Versiones Poda de los Descendientes de una Versión Poda a partir de una Versión Fusión de Versiones Fusión de Versiones Hojas Hermanas Fusión de Versiones Hojas no Hermanas Fusión General de Versiones Operaciones Primitivas Operaciones Primitivas Operaciones Adicionales para la Gestión de Documentos Versionados Conclusiones Modelo de Datos para Documentos XML Modelo de Datos para Documentos XML: Grafo XML Observaciones al Modelo de Datos Propuesto Cambios en un Grafo XML CrearGrafoXML AñadirNodo BorrarNodoDato BorrarNodoElemento ActualizarNodoDato Representación de un Grafo XML en un Documento XML Conversión de un grafo XML en un Documento XML Conversión de un Documento XML en un Grafo XML Modelización de Documentos XML mediante Grafos XML Identicación de Grafos XML y Documentos XML Cambios en Documentos XML Conclusiones VI

7 5. Grafos vxml y Documentos vxml Introducción a la Integración de Versiones Grafos vxml Árbol de Versionado Marcado de Versión: VersionStamp Grafo vxml Representación de un Grafo vxml en un Documento XML: Documentos vxml Árbol de versionado Marcado con Región de Versionado Recuperación de Versiones Recuperación de Versiones (Grafos XML) a partir de un Grafo vxml Optimización en la Recuperación de Versiones (Grafos XML) a partir de un Grafo vxml Recuperación de Versiones (Documentos XML) a partir de un Documento vxml Conclusiones Modelo de Documentos XML Versionados: vdocxml Modelo de Datos de Documentos XML Versionados: vdocxml Crear un Documento vxml Obtener una Versión Borrar una Versión Añadir Versión Obtener Diferencias Primitivas para la Actualización de un Grafo vxml Primitivas para la Actualización de un Documento vxml Composición de Primitivas Inserción de una Versión Consultas sobre Documentos vdocxml Conclusiones III Prototipos y Experimentación Diseño de un Sistema de Versionado basado en vdocxml Diseño del Sistema Diseño Funcional del Sistema Diseño para la Gestión de Transacciones Documento de Trabajo Sigmod.XML Documento XML Transaccional Integración de una Herramienta de Diferencias XML Diseño del Sistema Gestor Módulos XSLT Módulos XQuery Uso con Procesadores XQuery Extensión de una Base de Datos Nativa XML con Versionado Conclusiones VII

8 8. Construcción del Sistema Gestor y de Consultas Representación de Tipos Básicos para las Consultas de Versionado Predicados de Versionado: vstamp Predicados de Versionado Predicados de Versionado en XQuery Consultas sobre vdocumentos: vxquery Proyección de Versionado Instantánea de Versionado Instantánea de Elemento en XQuery Instantánea de Elemento en XPath Instantánea de Documento en XQuery Instantánea Optimizada de Documento en XQuery Instantánea de Documento en XSLT Regiones de Versionado Consultas por Rangos Consultas Continuas Actualización de un vdocumento: vupdate Validez en el Proceso de Actualización Inserción de Elementos Borrado de Elementos Actualización de Atributos Consultas de Diferencias: vdi Consultas de Diferencias en XQuery Consultas de diferencias en XSLT Conclusiones Experimentación del Sistema Pruebas de rendimiento Experimentos Resultados Resultados en exist Resultados en Saxon Optimización en las Consultas de Validez de Versionado Optimización basada en el Camino de Antecesores Optimización basada en el Almacenamiento de los Descendientes Resultados con otros Estándares Conclusiones a los Resultados Experimentales Interfaces de Versionado Servicio Web Interfaz Web-XQuery para la Gestión de Versiones (Extensión a exist) Interfaz AJAX para la Gestión de Versiones Conclusiones VIII

9 IV Aportaciones y Conclusiones Aportaciones y Conclusiones Aportaciones de esta Tesis Modelo para un Sistema de Versionado de Documentos XML Validación Práctica del Modelo Trabajos Futuros Publicaciones Conclusiones Cronología de la Investigación Reexiones Finales. Versionado de esta Tesis A. Otras Aportaciones 227 A.1. Integración del Eje Temporal en Documentos vxml A.2. Versionado de Documentos Concurrentes Publicaciones Referenciadas 232 IX

10 X

11 Índice de guras 1.1. Ejemplo de Funcionalidades de un Sistema de Versionado Estructura de la Tesis Ejemplo de Gestión de Versiones con Tiempo Ejemplo de Gestión de Versiones con Grafo de Derivación Ejemplo de un documento OEM Ejemplo de un documento DOEM Documento XML de Restaurantes y Cocineros Comparación de dos versiones usando DeltaXML Marcado Temporal mediante Atributos Temporales Marcado Temporal mediante Elementos Hijos Temporales Documento versionado vdoc=(g, D, ρ) Creación de un documento versionado vdoc Inserción de una versión como derivada de otra Borrado de una versión sin versiones hijas Creación de un documento versionado vdoc a partir de un documento Creación de un documento versionado vdoc a partir de un conjunto de documentos Obtención del documento asociado a una versión Inserción de una versión entre dos existentes Cambio del padre de una versión Borrado de una versión con versiones hijas (1/2) Borrado de una versión con versiones hijas (2/2) Sustitución de versiones (1/2) Sustitución de versiones (2/2) Poda de los descendientes de una versión Poda a partir de una versión Fusión de versiones hojas hermanas Fusión de versiones hojas no hermanas Fusión general de versiones Representación gráca de un Grafo XML Insertar un Nodo en un Grafo XML Borrado de un Nodo Data en un Grafo XML Borrado de un Nodo en un Grafo XML Actualización de un Vértice en un Grafo XML XI

12 4.6. Grafo XML y su Representación en formato XML Identicación de las clases y Γ(G) Composición de Primitivas en un Documento XML Cambios Ramicados en un Grafo XML a. Grafo de Derivación de la gura 5.1 b. Validez de Versionado en un grafo XML Representación de un Grafo de Derivación mediante un Grafo XML Representación Positiva y Negativa para la Validez de Versionado Ejemplos de Región de Versionado Representación de un Grafo vxml vacío Ejemplo de Cierre de Versionado Grafo vxml con múltiples Versiones Estructura básica de un documento vxml. Documento vacío vxml Árbol de Versionado en XML Grafo vxml y su representación en grafo XML equivalente Conversión de un grafo vxml a un documento vxml Documento vxml de Restaurante y Cocineros Ejemplos de Validez de Versionado Ejemplos de Validez de Versionado en el proceso Optimizado Documento XML versionado vdocxml=(g, D, ρ) Creación de un documento XML versionado vdocxml Insertar Versión en un documento vdocxml Ejemplo de Actualización de un Grafo vxml Cambios Ramicados en un Documento XML Arquitectura Genérica del Sistema de Versionado Documento acm.xml y Esquema de documentos ACM Documento acm.xml con Versiones. acm.vxml o sigmod.vxml Esquema de un Documento XML Transaccional Documento XML Transaccional Ejemplo de Documento jxydi Esquema de Funcionamiento del Sistema de Versionado con Herramienta de Diferencia Sistema de Versionado Arquitectura del Sistema XQuery y la interrelación entre los Módulos XQuery con respecto a la API pública de la tabla Resultado de la operación de proyección sobre el author 'd1e13' Resultado de la consulta 8.7: Instantánea de un elemento XML Salida del Algoritmo de Diferencias en XQuery Salida HTML de Diferencias entre dos Versiones a. Características de acm.xml y acm.vxml. b. Tamaño de los documentos vxml resultantes Tiempo de Recuperación en exist de Q Tiempo de Recuperación en exist de Q Tiempo de Recuperación en exist de Q XII

13 9.5. Tiempo de Recuperación de Q1 y Q2 en Saxon Tiempo de Recuperación Optimizado en consulta de Q1 en exist Tiempo de Recuperación Optimizado en consulta de Q2 en exist Documento acm.vxml Optimizado Tiempo de Recuperación Optimizada basada en Índices (Q2) en exist Tiempo de Recuperación en XSLT Capas del Sistema de Versionado e Interfaces Administrador Web para la Gestión de versiones a) Esquema de Funcionamiento b) Aplicación Ajax para la Gestión de versiones Cronología de la investigación A.1. Documento tvxml A.2. Validez Temporal en un Documento vxml A.3. Problemas de Anidamiento A.4. Documento vxml metamarcado XIII

14 XIV

15 Índice de tablas 1.1. Comparativa de Soluciones Marcado Temporal en una BDR Modelo de Datos y Lenguajes Temporales Relacionales Resumen de modelos de Datos Temporales OO Ejes del lenguaje XPath Comparativa de Algoritmos de Diferencias XML Modelos de Datos XML Temporales Soluciones actuales para la Gestión de Versiones Operaciones Primitivas para vdoc Operaciones adicionales para vdoc Representación en formato tabla del grafo XML de la gura Primitivas de Cambio en un Grafo XML Operaciones Elementales sobre un Grafo XML Primitivas de Cambio de un Documento XML y su correspondencia con Grafo XML Primitivas de Cambio en un Grafo XML y en Documento XML Actualización de un V-Edge a partir de un cambio Actualización de un Documento vxml Correspondencia entre las etiquetas jxydi y nuestras primitivas de cambio API del módulo Version Conversión de Tipos de Conjuntos de Versionado Notación usada en las consultas XQuery Predicados de Comparación entre dos versiones Predicados de Comparación entre una Versión y una Región de Versionado Predicados de Comparación de Regiones de Versionado Predicados de Comparación entre dos versiones y su representación en XPath Funciones XQuery del módulo vstamp Funciones XQuery del módulo vquery Funciones XQuery del módulo vupdate Servicios Web de Versionado XV

16 XVI

17 Índice de consultas 2.1. Ejemplo de Expresión XPath Ejemplo de Consulta XQuery Ejemplo de Consulta Temporal en XQuery Llamada a la función vdoc2doc en XQuery Llamada a la función vgetdi en XQuery (exist) Predicado vstamp:before ( ) en XQuery Operator vstamp:vbelongto (ɛ) en XQuery Operator vstamp:vbelongto (ɛ) en XQuery sobre velemento Predicado vstamp:vrcontains en XQuery Predicado vstamp:vrcontainslist en XQuery Funcion vquery:vhistory. Proyección de Versionado en XQuery Función vquery:vsnapshot. Instantánea de Elemento en XQuery para V Instantánea de Elemento en XPath para V Función vquery:vdocsnapshot. Instantánea de Documento en XQuery para V Función vquery:vdoc2docopt. Instantánea de Documento Optimizada Instantánea de Documento en XSLT Función vquery:vrcontains. Recuperación por Rangos en XQuery Función vquery:vrcontainslist. Recuperación por Rangos en XQuery Función vquery:continuous. Recuperación por Duración en XQuery Función vquery:insertelement. Inserción de Elemento en XQuery Función vquery:deleteelement. Borrado de Elemento en XQuery Función vquery:updateattribute. Actualización de un Atributo en XQuery Función vdi:changes. Diferencias en XQuery Función vdi:changesafter. Diferencias en "n"versiones posteriores en XQuery Consulta de Diferencias en XSLT Consulta vdoc2doc optimizada XVII

18 XVIII

19 Módulo I El Problema de la Gestión de Versiones

20

21 Capítulo 1 Introducción Contenidos 1.1. Introducción Motivaciones Ejemplo de Necesidades en un Dominio de Gestión de Versiones Funcionalidades de un Sistema de Gestión de Versiones Limitaciones de las Soluciones Actuales Objetivos de esta Tesis Guía de Lectura Este capítulo sirve de introducción a esta tesis y en él se abordan tres aspectos que consideramos esenciales: las motivaciones que han conducido a este trabajo, los objetivos que se han perseguido y la estructuración de contenidos como guía de lectura de los capítulos de este documento. En la sección 1.1 se introduce brevemente por qué es importante el versionado como técnica de representación de la realidad y por qué se ha decidido estudiarlo para los documentos XML. En la sección 1.2 se describen las motivaciones que han guiado el desarrollo de este trabajo. En primer lugar se presentan, a modo de ejemplo, algunas situaciones en las que es necesario tratar con problemas de versionado. A partir de ellas se denen las principales funcionalidades que debe cumplir un sistema de gestión de versionado y que constituyen una primera especicación de requisitos de este tipo de sistemas. Y posteriormente, se comparan estas características con los modelos y sistemas de gestión de versionado actuales, deduciéndose un conjunto de aspectos que deben ser resueltos o mejorados. Los objetivos de la tesis se presentan en la sección 1.3 y, naturalmente, van encaminados a resolver las deciencias detectadas en el apartado anterior. Finalmente, la sección 1.4 presenta el desarrollo de contenidos en los diferentes capítulos de la tesis Introducción Como introducción al lector en este trabajo, vamos a reexionar sobre las siguientes preguntas: ¾Por qué nos resulta de interés el versionado? ¾Por qué nos hemos planteado el versionado de documentos XML?

22 4 Capítulo 1. Introducción Hoy en día la información es de vital importancia para la toma de decisiones y por este motivo cada día se requiere que los sistemas de información incorporen un mayor número de funcionalidades como recuperación eciente de la información textual, tratamiento de datos multimedia o conocimiento semántico de los datos. Entre todas estas nuevas funcionalidades destacamos las que se encargan de mantener una historia de los distintos estados o versiones que ha tenido la información, pues ésta se encuentra en un continuo cambio, lo que se conoce como evolución de los datos. Su necesidad puede observarse en los siguientes ejemplos: Conocer la evolución nanciera de una empresa facilitará a sus directivos el recticar o modicar sus políticas. Sin embargo, son muchos los parámetros que pueden denir la empresa, y por tanto, conducir a diferentes versiones que expliquen la evolución de la misma. La información que se publica (periódicos, publicidad, etc.) suele estar en constante evolución. Y en muchos casos no sólo importa la información en sí, sino también su adaptación al público que va a utilizarla, de forma que podemos tener diferentes versiones de una información para que se adecúe al tipo de audiencia que vaya a accederla. Realizar el diseño de un producto es un proceso evolutivo hasta conseguir un producto comercializable. Puede que se necesiten diferentes versiones del mismo producto para que se ajuste a diferentes situaciones de uso o simplemente para analizar su proceso de desarrollo y mejora. Centrándonos en un caso real, en [Sjoberg 93] se presenta el estudio realizado sobre los cambios producidos en el diseño de una base de datos a lo largo 19 meses. Durante dicho periodo de tiempo el número de relaciones aumentó en un 139 % y el número de atributos en un 274 %. Analizando estos resultados, y sin necesidad de mencionar el número de actualizaciones que hubo sobre los datos, a nadie sorprende la armación de que nos encontramos en un momento caracterizado por un incremento vertiginoso de la información lo que unido a su comportamiento dinámico conlleva una laboriosa gestión. Sin embargo, la representación del mundo real mediante datos ha estado basada, durante mucho tiempo, en la representación del estado de una perspectiva de los objetos (un esquema) y un estado concreto (el valor para ese objeto en ese esquema), como si fuera una fotografía. Normalmente, este valor suele referirse al estado actual del objeto, de modo que cualquier modicación en el mismo se resuelve sobrescribiendo sus datos, perdiéndose los valores (estados) anteriores. Las consultas en esta representación están dirigidas a los estados actuales de los objetos que se almacenen en el sistema. Sin embargo, hoy en día se demandan sistemas que sean capaces de detectar, representar y almacenar el ciclo de vida de los datos de forma nativa, es decir, sus distintos estados o versiones, a n de gestionarlos ecientemente de forma cómoda y transparente para el usuario. El hecho de disponer de un sistema con estas funcionalidades puede ser útil para: Recuperación de información pretérita: Debido a que se representa y almacena la evolución de la información a lo largo de todo su ciclo de vida se pueden recuperar sus valores antiguos en un momento dado. Esta funcionalidad puede considerarse también como un mecanismo de copia de seguridad pues mantiene un histórico de todos los estados de la unidad de información, permitiendo su recuperación en caso de algún problema. Reutilización de la información: La información mantenida en el sistema gestor de versiones permite que éstas puedan ser reutilizadas posteriormente.

23 Motivaciones 5 Adaptación de la información: Adecuándola a las necesidades u objetivos del usuario. Interpretación de la evolución: Las consultas sobre esta evolución nos permiten realizar análisis causales de la misma para obtener cuál ha sido su comportamiento y así también poder predecir pautas o conductas futuras. Entre los distintos tipos de documentos existentes, se ha decidido abordar en esta tesis la gestión de versiones no lineales en documentos XML [Bray 98] 1. XML es un lenguaje semiestructurado desarrollado por el World Wide Web Consortium (W3C)[W3C 94] que se ha convertido en el medio predominante para el intercambio de información en la Web, pero además, se utiliza para almacenar información de conguración, documentos omáticos y también como mecanismo de almacenamiento de información semi-estructurada mediante las bases de datos nativas XML (XNDB). La versatilidad y exibilidad de XML permiten que prácticamente la información de cualquier documento se pueda expresar en este formato. Un documento XML puede tener un documento esquema asociado (DTD, XML-Schema, etc.) que dene su estructura y reglas de codicación. De este modo se puede representar cualquier lenguaje habitual mediante una representación equivalente en XML. Las secciones que veremos en lo que resta del capítulo nos servirán para presentar los problemas del versionado de documentos XML y que han motivado los objetivos de esta tesis. Así, en la sección 1.2 se analizan los problemas que pueden surgir si no se realiza la gestión de cambios en una fuente de información y se introducen, mediante un ejemplo, las necesidades de un sistema de versionado. A partir de estas necesidades, se denen las principales funcionalidades que debe cumplir un sistema de este tipo. Y, nalmente, se pondrá de maniesto la insuciencia de las propuestas actuales para lograr estas funcionalidades. Con ello quedan detalladas las principales motivaciones de esta tesis, que determinan sus principales objetivos tal y como se exponen en la sección Motivaciones La información y la estructura de las fuentes de información evoluciona debido básicamente a dos tipos de cambios [Zaniolo 97]: los que afectan a los datos y los que sufre el esquema que los dene. Las causas o motivos que producen estos cambios son innumerables pero mencionaremos los casos más frecuentes para ir introduciéndonos en la raíz de este trabajo. El primer tipo de cambio puede deberse a la incorporación de nuevos datos o a la actualización de la información almacenada actualmente en la fuente, mientras que el segundo cambio puede estar provocado por un mal entendimiento entre los distintos agentes que han realizado el análisis del sistema, un diseño incorrecto o la necesidad de nuevos requerimientos o funcionalidades que aparecen con el uso del sistema. Cuando algunos de estos cambios tiene lugar en nuestro sistema de información es necesario gestionarlos para evitar los problemas que pueden provocar. El primer problema surge debido a que los sistemas actuales sobrescriben los antiguos valores de los datos generando un nuevo estado o versión del mismo. De este modo, este proceso impide que puedan realizarse consultas por valores antiguos, es decir, no se permite acceder a la información anterior. Con el objetivo de resolver este problema es necesario mantener una historia de los cambios realizados y denir un conjunto de operaciones sobre 1 En el año 2008 se ha realizado la quinta recomendación de este estándar[maler 08]

24 6 Capítulo 1. Introducción ellos. Otro problema que podemos encontrarnos, relacionado con el historial de cambios, se produce cuando se añaden nuevos datos a la fuente de información sin dejar constancia o rastro de cuándo se produjo esta operación de adición. Respecto a los problemas que pueden surgir si se efectúa un cambio signicante en la estructura lógica del sistema de información, destaca la necesidad de readaptación a la nueva denición del esquema de los datos almacenados en las fuentes de información. Este proceso es conocido como evolución del esquema de la fuente de información y, de no llevarse a cabo, puede provocar la inconsistencia de las instancias almacenadas con respecto al nuevo esquema denido. A continuación, mediante un ejemplo, se analizará qué necesidades pueden existir cuando se realizan cambios en un dominio de creación de diseños grácos representados en documentos XML. Seguidamente se determinará qué funcionalidades debe tener nuestro sistema y nalmente se estudia si éstas se cumplen en los modelos y sistemas de gestión de versionado actuales Ejemplo de Necesidades en un Dominio de Gestión de Versiones Un creativo de una empresa de diseño gráco lleva varios meses concentrado en desarrollar un producto para una nueva campaña publicitaria para su cliente más importante. Para ello debe ofrecer diferentes versiones de una idea inicial que servirán como base en la campaña. A la hora de desarrollar este nuevo proyecto, el diseñador partirá de una primera versión del diseño, que llamaremos V 0. Consideraremos esta versión V 0 como la versión vacía inicial de la que parte cualquier línea de diseño. Lógicamente, este diseño inicial se irá modicando hasta conseguir que alguno de los diseños cubra las expectativas del cliente. Los cambios que se irán realizando sobre el documento surgirán por la adición de contenido, la actualización de un determinado objeto, por el cambio de la estructura del diseño, etc. Nótese que según el diseñador avance en el boceto gráco con mucha probabilidad necesitará regresar a un boceto anterior del actual si los últimos cambios realizados no se adecúan a lo esperado, pero sin perder estas últimas modicaciones realizadas, pues pueden serle de gran ayuda. Esta característica de disponer de varios diseños alternativos es de vital importancia en este marco de trabajo (diseño) donde se puede considerar que en cada instante se puede tener un conjunto de diseños válidos. Analicemos cómo puede afrontar esta empresa el proceso de creación de esta nueva campaña: el diseñador almacena cada día el trabajo realizado y éste es recuperado al inicio de la sesión siguiente. Conforme vayan pasando los días, el documento se irá modicando hasta conseguir los diseños de la campaña. Con el n de no perder ninguna idea feliz, que pudiera haberse desechado en el proceso de maduración de la campaña, la empresa dispone de un método rudimentario de copias de seguridad que básicamente consiste en duplicar la información y hace muy difícil encontrar el diseño requerido en un instante dado. Para esta nueva campaña se va a utilizar un sistema de versionado. Obviamente el diseñador debe disponer de un conjunto de operaciones que le faciliten el trabajo y que le permitan gestionar distintas versiones del documento de forma ágil. Lógicamente, todas estas operaciones se llevarán a cabo de forma totalmente transparente y no implicará una preocupación excesiva por su parte. Antes de analizar las operaciones que debería incluir el sistema de versionado es necesario determinar la herramienta que se usará para almacenar la información y así poder establecer cómo gestionar sus versiones. Entre todas las técnicas que barajaron inicialmente para almacenar la información gráca generada a lo largo del proyecto, se optó nalmente por utilizar

25 Motivaciones 7 un documento de marcado XML especialmente diseñado para el tratamiento gráco vectorial SVG [Northway 05], por ofrecer mayor portabilidad que otros métodos. Estos documentos están sujetos a un esquema, que incluso puede redenirse para adaptarse a los grácos de la empresa, y los contenidos constituyen el diseño en cuestión. El conjunto de operaciones que le pueden interesar al creativo serían: 1. Al comienzo de una nueva jornada, lo normal sera que el creativo desee retomar su trabajo desde algún punto en que lo dejó. Por tanto, una operación a tener en cuenta será la recuperación de una versión de trabajo del documento / gráco. 2. Al nalizar la jornada de trabajo el diseñador debe poder almacenar los cambios realizados en el documento sin perder la versión anterior. Para ello necesita un mecanismo que: a) Detecte si el documento se ha visto modicado con respecto a la versión de trabajo que se haya tomado como punto de partida, y b) Permita crear una nueva versión registrando que es una versión descendiente de la versión de trabajo. 3. En otras ocasiones, según se vaya dando forma al diseño, puede suceder que un cambio recientemente realizado no cumpla con las expectativas. El sistema debe proporcionar algún mecanismo de retorno a una versión anterior, sin perder la versión de trabajo que era la actual. 4. Los días que el diseñador se encuentre inspirado puede llegar a generarse todo un abanico de versiones o un conjunto de versiones paralelas, a partir de la versión actual, pues retrocede a la versión de partida generando una nueva versión por cada nueva idea que le surja. El sistema debe permitir almacenar cada una de estas versiones y posibilitar consultas futuras u obtener las diferencias entre ellas. 5. Como consecuencia del punto anterior, el diseñador puede necesitar un mecanismo para: a) Navegar por el conjunto de versiones considerando la relación de derivación entre ellas, y b) Realizar la comparación de dos versiones distintas del documento. 6. Si suponemos que cada versión es una imagen gráca compuesta de diferentes objetos o componentes grácos, adicionalmente el diseñador puede estar interesado en conocer toda la historia de un determinado objeto del diseño, siendo necesario poder consultar los elementos que componen una versión del diseño gráco y compararlos con el resto de versiones del documento. Por ejemplo, un componente gráco puede cambiar sus propiedades en versiones descendientes de la actual o puede desaparecer. En esos casos le puede interesar cuestiones como, ¾dónde se usa este objeto del diseño gráco?, ¾en qué versiones ha dejado de usarse?, ¾en qué versiones se ha modicado?, Finalmente, otras operaciones recomendables para el diseñador pueden ser la posibilidad de fusionar versiones del documento, eliminar versiones que está seguro que no necesitará, etc.

26 8 Capítulo 1. Introducción Figura 1.1: Ejemplo de Funcionalidades de un Sistema de Versionado La gura 1.1 recoge de forma esquemática las distintas operaciones que surgen de analizar día tras día las necesidades del diseñador. El punto de partida del gráco es la versión V 0 del documento, comentada en el planteamiento del ejemplo (punto 1 del gráco). En dicho punto, el creativo comienza su trabajo con un boceto inicial del diseño (T1) y posteriormente desarrollará el resto del diseño (T2, T3, T4). Cuando inicie una nueva sesión de trabajo, lo primero que hará será recuperar la versión actual de su diseño (2), aunque también puede desear recuperar una versión anterior (3). En determinadas ocasiones puede tener varias versiones de un mismo documento, todas válidas, (4) y sería aconsejable que pudiese consultar cualquiera de ellas en un momento dado. También puede realizar la comparación de dos versiones diferentes de un mismo documento (5) y continuar desde la que más le interese en ese momento. A partir de este ejemplo observamos que el diseñador además de necesitar mantener los antiguos diseño, necesita que el sistema de versionado sea capaz de disponer de varias versiones alternativas del boceto lo que se conoce como versionado ramicado o no lineal. En este caso en cada instante de tiempo el diseñador puede tener no únicamente una versión válida del objeto sino un conjunto de ellas, aunque diferentes, del mismo objeto. De este modo por cada una de los objetos será necesario mantener sus distintas versiones y lo que es más importante representar la relación de versionado entre ellas Funcionalidades de un Sistema de Gestión de Versiones A partir del ejemplo anterior, se puede comprobar que la información de un documento XML, gráco SVG, puede evolucionar a lo largo del tiempo. Esta evolución se lleva a cabo mediante cambios en el documento XML. En este caso estos cambios afectan directamente a los datos, de modo que únicamente estudiaremos versiones producidas por cambios en la estructura de las etiquetas del documento XML y del contenido almacenado en los elementos

27 Motivaciones 9 y en los atributos. Nótese que podría existir otro cambio que concierne a los esquemas del documento XML pero que no será abordado en este trabajo, de modo que o bien no se dispone de esquema asociado al documento XML, o el esquema es constante para todas las versiones, como ocurre en este caso para los cheros SVG. Cuando se realizan estas actualizaciones, si no se dispone de un sistema de control de cambios, la información del documento XML se sobreescribe. Así, el diseñador del ejemplo no podría disfrutar de las facilidades descritas anteriormente. Para ello es necesario disponer de un sistema capaz de detectar cuándo se han realizado cambios en el documento XML, representar estos cambios en el sistema y nalmente almacenarlos para su posterior recuperación. Este sistema lo denominaremos Sistema Gestor de Versiones. Además de gestionar las versiones, deben ofrecerse funcionalidades que faciliten las operaciones de consulta. Sin embargo, debemos tener en cuenta que las consultas en este tipo de sistemas suelen realizarse a dos niveles. De una parte, podemos considerar consultas sobre cada versión en relación con el resto de versiones. En este caso los objetos de consulta son documentos propiamente dichos y buscamos operaciones que faciliten su inserción y borrado en la relación de versionado y los resultados de su comparación con el resto de versiones según dicha relación. En nuestro ejemplo, la relación de versionado es la relación de derivación de versiones, que es una relación ramicada y para la cual necesitamos recuperar (1), añadir (2.b), navegar (3, 4, 5.a) o incluso eliminar (7) donde los números entre paréntesis hacen referencia a las operaciones descritas en el ejemplo del diseñador gráco de la página anterior. De otra parte, también partiendo de este ejemplo, y puesto que cada versión del diseño gráco se encuentra constituida por un conjunto de elementos grácos (líneas, círculos, etc), podemos estar interesado en consultas sobre la evolución que han tenido estos componentes individualmente lo que nos permirte también considerar consultas sobre los elementos que constituyen el objeto. Por ejemplo, podemos comparar una versión con otra detectando los elementos comunes, eliminados o añadidos en cada una de las versiones (2.a, 5.b), o también podemos consultar la historia y evolución de un objeto concreto con respecto a las versiones relacionadas con la actual (6). A partir de este ejemplo, se pueden intuir las características deseables en todo sistema de control de cambios y gestión de versiones. Estas funcionalidades se resumen a continuación: 1. El sistema debe ofrecer un conjunto de primitivas para poder realizar cambios en el documento XML. Debe ser capaz de detectar y representar los cambios realizados en la estructura y en el contenido del documento. Estos cambios pueden realizarse mediante primitivas de cambio o a través de editores especícos que nos ayuden a realizar las labores comentadas de forma gráca. En el caso que nos ocupa, es necesario detectar cada una de las versiones del documento así como representarlas, para que el diseñador conozca con qué versión del documento está trabajando. 2. En el sistema debe existir un mecanismo que permita recuperar cualquier versión del documento XML. 3. El sistema debe permitir modicar cualquier versión del documento XML de forma que a partir de una versión se pueden generar distintas versiones válidas paralelas o ramicadas. Esta funcionalidad implica dotar de una relación entre las versiones denidas en el documento que aporte una semántica adicional y facilite su gestión. 4. El sistema debe proporcionar facilidades para consultar tanto la información contenida en las versiones del documento XML como los cambios que se han llevado a cabo entre

28 10 Capítulo 1. Introducción las distintas versiones, lo que permite analizar la evolución de los datos. Una de las principales características de un sistema gestor de versiones son las consultas que éste permite realizar. El sistema debe ser capaz de resolver consultas como: 1) Cambios que se han realizado entre dos versiones, 2) Recuperar la traza de un determinado elemento, 3) Versiones en que se ha modicado una parte del documento, etc. Nótese que es necesario que estas consultas se puedan formular usando los estándares XML de consulta, de modo que no sea necesario ningún requerimiento, únicamente procesadores XML / XQuery, para poder establecer estas operaciones Limitaciones de las Soluciones Actuales Si consideramos los distintos tipos de almacenamiento, nos encontraremos con distintas soluciones para la gestión de cambios como comentamos en este apartado. Para el caso de los cheros de texto uno de los dominios de aplicación en los que se ha hecho patente la necesidad de sistemas de gestión de versionado ha sido en el desarrollo de proyectos de software. Desde la aparición de los primeros lenguajes de programación en los años 60, los desarrolladores de software dedican gran parte de su tiempo a labores de reescritura de código (modicación del código), debido a la constante necesidad de adaptar los programas a nuevas especicaciones o a corregir fallos existentes. Esto hace necesarias herramientas de gestión de los cambios realizados, que suelen recibir el nombre de software de control de versiones. En cuanto a los sistemas de cheros, las herramientas de control de versiones [CVS 85, Tichy 85, Subversion 00] suelen usar algoritmos de diferencias que trabajan o bien a nivel de líneas (si se trata de un documento textual) o bien a nivel de byte (si se trata de un chero binario). Su objetivo, por tanto, es encontrar el conjunto de diferencias existentes entre dos cheros obteniendo con ellos un chero de salida de cambios que, aplicado al chero origen, nos permitirá obtener el segundo de ellos. El principal inconveniente de su uso en documentos XML se debe a que éstos tienen una estructura jerárquica de etiquetas que delimitan sus elementos y su tratamiento como meras lineas textuales eliminaría su jerarquía. Además estas soluciones no permiten consultas mediantes estándares XML de consulta como XPath o XQuery. La gestión de cambios en la información almacenada en una base de datos, tanto relacional [Snodgrass 95, Tansel 93, Steiner 98] como orientada a objetos [Lautemann 96, Roddick 95], consiste principalmente en asociar a los datos (tupla o atributos) una historia o marca de tiempo, lo que se denomina marcado temporal. Un amplio abanico de soluciones se han propuesto en las últimas décadas y han dado lugar a distintos modelos de datos, operaciones, lenguajes de consultas e implementaciones de sistemas temporales. Sin embargo, debido a la naturaleza líneal del tiempo estos sistemas no tienen soporte para versionado ramicado. En los últimos años se ha profundizado en el estudio de la gestión de versiones en documentos XML, donde muchas de las soluciones propuestas surgen de aplicar a este tipo de documentos las soluciones anteriormente comentadas. Entre ellas se pueden destacar: Delta XML [Marian 01, Chien 01c]: Básicamente consiste en almacenar los cambios realizados sobre el documento XML mediante comandos o instrucciones XML de modicación, lo que permite regresar a cualquier estado anterior deshaciendo la ejecución de las operaciones de cambio realizadas. Igual que las soluciones deltas sobre cheros planos, no permite las consultas mediante lenguajes como XPath o XQuery y requiere un coste computacional bastante elevado para versiones distintas a la actual. Temporal XML [Grandi 00, Zhang 02, Wang 04a]: Consiste en integrar en un único

29 Motivaciones 11 Tabla 1.1: Comparativa de Soluciones Tipo Doc. Control Gestión Clásicas Textual/Binaria Ramicado Histórico de Op. BD BDR/BDOO Lineal Histórico de Datos Temporales Delta XML XML Ramicado Histórico de Op. XML XML Lineal Histórico de Datos. Temporal Versionado XML Ramicado Histórico de Datos. XML Propuesta de XML Ramicado Histórico de Datos. esta tesis Funcionalidades χ χ χ χ χ χ documento XML sus distintos estados mediante la incorporación de marcas temporales en el documento (principalmente a nivel de elemento XML) que especican la validez de los distintos componentes de un documento XML. Esta solución aprovecha el gran aporte cientíco de las bases de datos temporales para gestionar las distintas versiones, pero destacamos como principal inconveniente la imposibilidad de gestionar versionado no-lineal, pues el uso de aspectos temporales, lineal por denición, condiciona este hecho. Versionado XML : La idea consiste en representar y gestionar versiones no lineales del documento. Para ello añaden el grafo de derivación de las versiones en el sistema y denen la validez de la información variante en base a dicho grafo. En la actualidad no existen muchas soluciones basadas en esta técnica para documentos XML. Principalmente podemos destacar [Wuwongse 04], basado en deltas temporales, donde adicionalmente los autores almacenan por cada versión información de la versión de la cual deriva. Sin embargo su principal desventaja, al basarse en deltas, es que no se pueden realizar consultas históricas. Otra solución es mediante técnicas de indexación [Vagena 04] pero éstas no permiten el uso de estándares de consultas XML. En la tabla 1.1 se muestra un resumen de estas soluciones, a nivel genérico, para la gestión de versiones de documentos XML. En ella se analiza la fuente de información utilizada, el tipo de versionado soportado (lineal o ramicado), el mecanismo utilizado para representar y almacenar las versiones (basado en histórico de operaciones o histórico de valores) y nalmente si satisfacen cada una de las cuatro funcionalidades descritas en el apartado anterior. A partir de esta tabla se aprecia que las soluciones actuales tienen principalmente dos deciencias: las soluciones temporales no soportan de versionado ramicado mientras que las soluciones deltas no permiten consultas usando estándares XML. Además otro problema detectado es que no existe un modelo de versionado que sirva de referencia para el desarrollo de cualquier solución. El objetivo de esta tesis será resolver estas grandes limitaciones, usando para ello la propuesta que aparece reejada en la última la de la tabla.

30 12 Capítulo 1. Introducción 1.3. Objetivos de esta Tesis La nalidad de esta tesis se centra en proporcionar el marco adecuado para la gestión de versiones en documentos de marcado XML. Los objetivos principales se desglosan en los siguientes puntos: Denición de un modelo que describa un sistema de versionado genérico para documentos. Especicación de un modelo para la gestión de documentos XML versionados de forma ramicada. El modelo propuesto debe ajustarse al modelo de versionado descrito anteriormente, teniendo en cuenta la semántica inducida por los documentos XML. Representación eciente de las versiones que permita realizar consultas tanto sobre la relación de versionado como sobre los elementos que componen cada versión con respecto al resto de versiones. Utilización de los estándares XML XQuery, XPath y XSLT para la ejecución de las consultas. Implementación de un sistema de versionado XML portable basado en los modelos previos que además proporcione una interfaz para el desarrollo de aplicaciones sobre datos versionados Guía de Lectura En esta sección se describe la estructura de la presente tesis ilustrada grácamente en la gura 1.2. En ella podemos observar dos módulos principales: los capítulos 3, 4, 5 y 6 que constituyen la denición formal de la tesis y los capítulos 7, 8 y 9 donde se recoge la implementación del sistema de versionado. Aunque no se muestra en la gura, esta memoria se encuentra dividida en cuatro grandes módulos. El primero de ellos denominado El problema de la gestión de versiones lo constituyen el capítulo 1 y 2 con el objetivo de introducir al lector en la materia. Posteriormente, el módulo II, Versionado de documentos XML, se encuentra formado por los capítulos 3, 4, 5 y 6, que muestran nuestra solución para la gestión de versiones de documentos XML. A continuación los capítulos 7, 8 y 9 forman el módulo denominado Prototipos y Experimentación donde se ilustra el sistema de versionado desarrollado y, nalmente, el módulo 4, Aportaciones y Conclusiones, resume los logros conseguidos con este trabajo. A continuación, explicamos de forma resumida el contenido de cada uno de los capítulos. Capítulo 2: Estado del Arte Todo proceso de investigación comienza con la lectura exhaustiva de toda la documentación referente a la temática de estudio. En este capítulo se analizan aquellas referencias que han servido de punto de partida para la elaboración de esta tesis. Se comenzará resumiendo la gestión de versiones en documentos planos y en bases de datos, tanto relacionales como de objetos y objetos/relaciones, para, posteriormente, profundizar en las orientadas a documentos semi-estructurados y documentos XML.

31 Guía de Lectura 13 Figura 1.2: Estructura de la Tesis

32 14 Capítulo 1. Introducción Capítulo 3: Modelo de Documentos Versionados vdoc La denición de documento versionado se aborda en este capítulo. El objetivo fundamental de este tipo de documentos consiste en disponer del conjunto de sus estados versiones, entre los que debe establecerse alguna relación. En representaciones no-lineales, el modelo de documentos versionados suele basarse en el concepto de derivación que consiste en poder identicar el conjunto de nuevas versiones del documento obtenidas a partir de una versión dada. Además se describen las operaciones básicas que se pueden realizar en el modelo vdoc. Capítulo 4: Modelo de Datos para Documentos XML En este punto del trabajo ya conocemos los elementos básicos de los que partiremos para llevar a cabo nuestra investigación. Es por tanto un buen momento para presentar el modelo de datos en el que se basa el presente estudio. Nuestra propuesta es un modelo de datos para documentos XML [W3C 94, Bray 98] denido en base a un grafo dirigido acíclico, con un único nodo raíz, grafo al que se denomina Grafo XML. En esta representación se han denido distintos tipos de vértices y de arcos para dar cabida a cada uno de los componentes que pueden formar parte de un documento XML. Nuestra atención se ha centrado principalmente sobre unos arcos especiales denominados referencia que serán usados en los capítulos posteriores. En este capítulo también se describen las operaciones básicas de cambio que pueden realizarse sobre este modelo. Capítulo 5: Grafo vxml y Documentos vxml La idea central que se presenta en este capítulo es un modelo de datos para grafos de documentos XML versionados, denominado Grafo vxml, que mantiene toda la información acerca de cómo ha evolucionado un grafo XML a lo largo del tiempo. Se ha denido un nuevo modelo basado en un grafo XML donde para mantener la historia se ha utilizado una nueva técnica, denominada versionstamp, que garantiza una fácil gestión de versiones no-lineales. Se realiza un análisis de cómo afectan los cambios a este grafo de versionado y, nalmente, se explica cómo transformar un grafo vxml en un documento XML versionado. Capítulo 6: Modelo de Documentos XML Versionados: vdocxml Todos los capítulos anteriores nos han servido para introducir y analizar en profundidad cada uno de los elementos fundamentales que van a componer nuestro modelo de datos de documentos XML versionados. Establecimos como punto de partida la denición de un modelo de datos genérico, para documentos de versionado, donde se presentó su estructura y las operaciones que pueden realizarse sobre él. Nuestro siguiente paso fue modelar un tipo de documento concreto, los documentos XML, que posteriormente fue usado para representar en él múltiples versiones de un grafo XML, denominándolo grafo vxml. Como última fase de nuestro estudio, aplicamos el modelo vdoc a los documentos XML, llamando a este nuevo modelo vdocxml, y presentamos una implementación basada en el modelo de datos vxml. Capítulo 7: Diseño de un Sistema de Versionado basado en vdocxml Para veri- car el funcionamiento de la técnica propuesta en esta tesis, se han realizado distintas implementaciones. En este capítulo se describen todas ellas destacando la implementación realizada mediante módulos XQuery. Esta se caracteriza por su amplia portabilidad pues permite su uso tanto en un procesador XQuery como su integración en una base de datos nativa XML con soporte para XQuery. En este sentido mostraremos cómo se ha extendido una base de datos

33 Guía de Lectura 15 nativa XML, exist [Exist. 01], para soportar la gestión de versiones de documentos XML. Además también se describe la API pública de versionado. Capítulo 8: Construcción del Sistema Gestor y de Consultas Dentro de este capítulo se analiza el resto de la implementación realizada en el capítulo 7. Entre todos los módulos hacemos especial hincapié en el modulo vquery pues en él denimos las diferentes consultas que se pueden realizar en un documento XML versionado. Comenzamos analizando las consultas básicas sobre el eje de versionado (recuperar la historia de un documento, recuperar una versión, realizar consultas empleando distintos operadores de versionado, etc.) para, a continuación, abordar las consultas basadas en rango de versiones. Capítulo 9: Experimentación del Sistema En este capítulo ponemos de maniesto la experimentación llevada a cabo sobre nuestro sistema de versionado. Esta experimentación se ha realizado en dos niveles: por una parte a nivel de rendimiento para comprobar el comportamiento de nuestra técnica de versionado ramicado y, por otra parte, en el desarrollo de distintos interfaces de versionado que permiten experimentar con la API pública de versionado denida. Capítulo 10: Aportaciones y Conclusiones En este ultimo capítulo se sintetizan las conclusiones principales que, a nivel global y de forma más general, se pueden extraer de todo el trabajo realizado.

34 16 Capítulo 1. Introducción

35 Capítulo 2 Estado del Arte Contenidos 2.1. Gestión de Cambios y Gestión de Versiones Conceptos Previos: Versión Conclusiones Gestión de Cambios en Sistemas de Ficheros Gestión de Cambios en Bases de Datos Bases de Datos Relacionales Bases de Datos Orientadas a Objetos Gestión de Cambios en Documentos Semi-Estructurados Gestión de Cambios en Documentos XML Tecnología XML Delta XML Documentos XML Temporales Versionado Ramicado en Documentos XML Versionado de Esquemas Conclusiones Este capítulo tiene tres objetivos: presentar el conjunto de conceptos, ideas, trabajos e implementaciones relacionadas con el versionado en distintas fuentes de información, destacar las aportaciones de cada sistema para el versionado y mostrar las desventajas e insuciencias que presentan para alcanzar las funcionalidades de un sistema de versionado planteadas en el capítulo anterior. La primera sección dene los conceptos fundamentales para el tratamiento de versiones en las distintas fuentes de información, así como las principales técnicas para su gestión. Iniciaremos esta sección proporcionando los conceptos de estado, cambio, versión, historia y derivación. A continuación analizaremos en profundidad la diferencia existente entre los dos tipos de derivación: versionado lineal y versionado ramicado. La primera consiste, por lo general, en asociar un tiempo a cada uno de los estados que ha tenido el objeto, deniéndose de este modo su validez temporal. La segunda técnica consiste en asociar un identicador de versión basado en la relación de versionado existente entre unas versiones y otras, normalmente a partir de un grafo de derivación. El uso de ambas soluciones se analizará para las

36 18 Capítulo 2. Estado del Arte fuentes de información más habituales en el resto de secciones; también comprobaremos si las características de un sistema de versionado, denidas en el capítulo 1, se cumplen en las fuentes de información a analizar. En la sección 2.2 se describirán las soluciones propuestas para el control de versiones en sistemas de cheros, basadas principalmente en obtener, representar y almacenar las diferencias textuales entre dos versiones de un mismo documento. Estas diferencias se generan en un chero de salida de cambios denominado Delta, de forma que la obtención de los distintos estados del documento solamente requiere la aplicación del chero de cambios sobre el documento origen. Esta solución se encuentra ampliamente aanzada dentro del campo de la ingeniería del software para el desarrollo de proyectos software complejos. Su estudio nos ha servido para introducirnos en la materia de versionado a través de conceptos como versión, rama, versiones paralelas, etc., así como para descubrir las operaciones más usuales de estos sistemas. En la sección 2.3 se aborda el estudio de las soluciones para la gestión de información histórica tanto en bases de datos relacionales como orientadas a objetos, soluciones basadas en el uso de aspectos temporales. La solución consiste en asociar a cada valor, o a aquellos que son susceptibles de cambio, un tiempo (instante, intervalo o elemento) que represente cuándo dicho valor se asume que ha sido, es o será válido. Esta técnica se ha aplicado también a los documentos XML, de forma que su estudio nos ha servido para comprender mejor la derivación lineal entre las versiones así como operaciones de consultas, modelos de datos, etcétera. En la sección 2.4 se profundiza en las soluciones planteadas para la gestión de versiones en documentos semi-estructurados, los cuales se caracterizan por carecer de una estructura ja. Estos tipos de documentos son la antesala de los documentos XML, de modo que su estudio nos ha ayudado a comprender mejor el modelo de datos de documentos XML y, a la par, a conocer cómo representar su historia mediante la asociación de meta-información a los arcos del grafo semi-estructurado. En la sección 2.5 analiza las soluciones aportadas para los documentos XML basadas principalmente en las técnicas descritas con anterioridad y que han sido aplicadas a estos documentos. De este modo se han usado las soluciones de los cheros planos basadas en Deltas para obtener las diferencias entre dos documentos XML (Delta XML), los aspectos temporales para meta-marcar las etiquetas del documento y representar así sus distintos estados y, nalmente, técnicas de versionado consistentes en meta-etiquetar el documento en base al grafo de derivación del documento. Finalmente, en la sección 2.6 se concluye que los sistemas actuales para la gestión de versiones de documentos XML o bien no tiene soporte para versionado ramicado o bien tienen dicultades para consultar los documentos XML versionados mediante estándares XML. La propuesta de esta tesis será dar una solución que resuelva ambos problemas Gestión de Cambios y Gestión de Versiones En los últimos años el concepto de almacén de información ha vivido una constante evolución, fuertemente relacionada con la importancia que están adquiriendo las nuevas tecnologías, herramientas y arquitecturas que han ido apareciendo en el campo de los sistemas de información. Hasta los años 70 los únicos almacenes de información eran los cheros planos, a los que sólo podía accederse desde aplicaciones construidas en base al formato de la propia información. Posteriormente los Sistemas Gestores de Base de Datos dieron la oportunidad de

37 Gestión de Cambios y Gestión de Versiones 19 separar los datos de las aplicaciones, además de introducir mejoras en el tratamiento de los datos. En la década de los 90, la explosión de Internet ha provocado la aparición de nuevos almacenes que incluyen el contenido de miles de documentos HTML, y que están almacenados en servidores repartidos por toda la red mundial; de la misma manera se ha extendido el uso de documentos XML, al tratarse de documentos autodescriptivos y con gran facilidad para el intercambio y gestión de la información. Tradicionalmente, las fuentes de información sólo reejaban el valor de los datos para un determinado instante, es decir, sobreescribían sus valores cuando se producía un cambio en los mismos. Sin embargo, tal y como se vio en el capítulo anterior, en muchas ocasiones es necesario representar y gestionar la evolución de los datos para así poder consultar tanto la información actual como la pretérita. Por este motivo, actualmente, se demandan sistemas que contemplen en modo nativo la capacidad de detectar, representar y almacenar el ciclo de vida de los datos, es decir, sus distintos estados o versiones, a n de gestionarlos ecientemente de forma cómoda y transparente para el usuario. Este sistema gestor de versiones se caracterizará por varios factores tales como: la granularidad de la información a versionar, los tipos de cambios que puedan producirse, el mecanismo de gestión de control que se emplee y el tipo de derivación que soporta el sistema gestor Conceptos Previos: Versión Antes de analizar cada uno de los factores mencionados en el apartado anterior deniremos una serie de conceptos que se usarán a lo largo de esta tesis. Dichas deniciones se abordarán de forma genérica, sin centrarnos en un objeto concreto. Estado de un objeto o ente de información: Se puede denir como una descripción instantánea del objeto. La descripción se realiza mediante unos valores sobre una estructura de datos o conjunto de atributos. Por ejemplo, si hablamos de un chero de texto nos estaríamos reriendo a la información textual almacenada en él; si se tratase de un documento XML sería el conjunto de elementos denidos en el mismo a partir de la información textual almacenada; si se tratase de una tabla relacional sería el conjunto de tuplas que contiene, etc. Cambio: Cualquier acción realizada sobre un objeto que provoca la aparición de un nuevo estado. Normalmente nos referimos a primitivas de cambio, que se denen como los cambios mínimos que originan un nuevo estado. Nótese que cuando se genera un nuevo estado, a partir de uno o varios cambios, éstos pueden provocar que el nuevo estado no sea consistente con respecto al esquema o la semántica del objeto. Por ejemplo, si añadimos a un documento XML un elemento sin etiqueta de cierre, o si añadimos una tupla duplicada a una tabla relacional. De este modo, nos interesarán los estados consistentes que pueden obtenerse a partir de una serie de cambios sobre un objeto, y que denotaremos habitualmente como versión del objeto. Versión: Es un estado semánticamente correcto de un objeto. En general, nos interesa gestionar conjuntos de versiones de un objeto que sean signicativas. Por ejemplo, distintas versiones de un diseño gráco, o distintas versiones de un poema. Por tanto, nos interesa disponer tanto del conjunto de versiones, como de alguna información adicional que permita relacionarlas entre sí para poder gestionarlas con facilidad.

38 20 Capítulo 2. Estado del Arte Un objeto versionado está compuesto por un conjunto de versiones y un conjunto de relaciones denidas sobre las versiones. Normalmente se tiene una única relación R denominada relación de versionado y que en la mayoría de los casos se trata de una relación de orden parcial inducida por algún atributo asociado a cada versión, por lo que suele tener asociada la semántica inherente a dicho atributo. Control de versiones: La capacidad de identicar, representar y gestionar las versiones que va sufriendo un objeto, es decir, su evolución o ciclo de vida. Uno de los tipos de relación de versionado usado más frecuentemente es la relación de derivación. En ella una versión representa información actual de un objeto el cual evoluciona debido a distintas operaciones de cambios sobre él. Así, la nueva versión del objeto se crea a partir de las modicaciones realizadas sobre el objeto en un estado anterior, comenzando por una versión inicial, normalmente conocida como V 0. Obviamente a un nuevo estado no se llega exclusivamente por la ejecución de una única primitiva sino a partir de un conjunto de ellas que denominamos transacción de cambios. Así el sistema de gestión de versiones debe tener algún mecanismo para gestionar esta historia de sus objetos. La evolución de un objeto se encuentra fuertemente condicionada por el grado de libertad para modicar el objeto versionable, es decir, si sólo está permitido realizar cambios sobre el estado actual del objeto versionable o sobre cualquiera de sus estados anteriores. Este factor nos va a conducir a denir el concepto de derivación. Derivación : Es el proceso por el cual una versión es creada a partir de las modicaciones realizadas sobre las versiones previas del objeto versionable, comenzando por una versión inicial, normalmente conocida como V 0. Una o varias versiones son derivadas de la versión precedente. Para seguir el rastro se utiliza una historia de versiones para saber cómo una versión ha llegado al estado actual. De este modo, mediante esta historia se mantiene una traza de estas derivaciones. Desde un punto de vista práctico pueden existir tres tipos de derivaciones: ˆ versionado lineal: aquella derivación donde se permite únicamente modicar la versión actual. ˆ versionado ramicado: se permite modicar cualquier versión anterior del objeto con la particularidad que una versión sólo puede derivar de una única versión padre. En este caso un estado puede derivarse en varias versiones, a las que se conoce como versiones paralelas o alternativas. ˆ versionado multiramicado: se puede modicar cualquier versión y una versión puede derivar de varias versiones En el capítulo anterior denotamos la importancia que tiene en esta tesis el aspecto de derivación, pues nuestra aportación es la capacidad para gestionar versionado ramicado para el objeto: documentos XML. Por este motivo, a continuación analizamos en profundidad los dos primeros tipos de derivaciones Versionado Lineal En este caso la evolución consiste en modicaciones sucesivas del objeto versionable donde la identicación de los distintos estados puede realizarse mediante números correlativos, de

39 Gestión de Cambios y Gestión de Versiones 21 modo que la relación de derivación puede obtenerse fácilmente a partir de la relación de orden total (>). Por ejemplo, sean dos versiones de un mismo objeto identicadas por dos números i y j donde i > j, podemos asegurar que el estado i ha derivado del estado j. Usualmente se ha empleado el tiempo para modelar este tipo de versionado pues sus valores se encuentran ordenados con respecto al predicado de comparación >. Los investigadores han establecido tres formas de modelar el tiempo [Tansel 93, Jensen 97]: Continuo: establece el tiempo como isomórco a los números reales. Cada número real se corresponde con un punto en el tiempo y, por tanto, entre dos puntos del eje de tiempo existen varios puntos. Denso: dene el tiempo como isomórco a los números racionales. Discreto: mapea el tiempo en base a números enteros. Mediante esta representación entre un punto de tiempo y su sucesor o antecesor no puede existir ningún otro punto. En [Snodgrass 95] se analiza cada uno de ellos estableciendo que el modelo discreto es el que permite representar el tiempo más elmente adaptado a la realidad, desde un punto de vista computacional. El modelo discreto es representado generalmente mediante un eje de coordenadas que representa un conjunto de puntos en el tiempo. Mediante el uso de tiempo se puede modelar la historia de un objeto. La idea consiste en asociar a cada estado un dato temporal [Allen 83, Tansel 93, Böhlen 95, Zaniolo 97], sea un instante, un intervalo o un elemento temporal, que indica en qué periodo de tiempo dicho estado ha sido válido. De este modo, la relación de derivación se establece en base a un conjunto de predicados denidos para los distintos tipos de datos temporales, como puede observarse en [Allen 83, Tansel 93, Snodgrass 95]. En la gura 2.1 se muestran varias versiones de un mismo objeto dentro de un eje temporal. Cada uno de sus estados tiene asociado un intervalo de tiempo que determina su validez. El objeto versionable usado en la gura es una gura geométrica, que cambia de forma; se ha usado este tipo de objeto para no tener que asociarlo a ninguna de las fuentes de información conocidas. De este modo en el intervalo [ , ], versión V 0, el estado del objeto está representado mediante un cuadrado. A continuación, en el siguiente intervalo, el objeto es un círculo y así sucesivamente para el resto de intervalos del eje. Figura 2.1: Ejemplo de Gestión de Versiones con Tiempo Podemos concluir este apartado estableciendo que se puede modelar la historia lineal de un objeto mediante una identicación de los estados basada en una numeración correlativa o de tiempo. La existencia de un conjunto de predicados permite realizar la comparación de estos identicadores y por tanto determinar fácilmente si una versión deriva de otra. Por ejemplo, a partir de la gura anterior se puede decir que la versión V 2 es anterior a la versión V 3, tanto por la numeración correlativa usada como por el dato temporal asociado a cada versión.

40 22 Capítulo 2. Estado del Arte Versionado Ramicado Cuando hay versiones alternativas, es decir, cuando pueden derivarse varias versiones a partir de una versión dada del objeto, entonces el grafo de evolución ya no es una secuencia lineal, sino que adopta la forma de un árbol. Si queremos seguir numerando las versiones se necesitará ahora una numeración distinta que permita reejar la relación padre-hijo de derivación. No existe un modo jo de numerar una versión, se deja al criterio de cada desarrollador aunque sí existen ciertas prácticas habituales en la numeración como el uso de cifras separadas por puntos que delimitan las numeraciones de cada nivel [CVS 85]. Otra forma de identicar las versiones, diferente de la numeración, es asociar a cada estado una identicación obtenida a partir del grafo de derivación de las versiones. Cada versión, representada por un vértice en el grafo, está asociada a un estado concreto y su vértice padre es la versión a partir de la cual se ha obtenido. En este caso la relación de una versión con otra se establece en base a la relación de precedencia en dicho grafo, es decir, la existencia de un arco entre un vértice origen V 1 y un vértice destino V 2 determina que la versión V 2 ha derivado de la versión V 1. Figura 2.2: Ejemplo de Gestión de Versiones con Grafo de Derivación En la gura 2.2 se ilustra un ejemplo de versionado ramicado usando un grafo de derivación. Cada uno de los estados que ha tenido el objeto versionable tiene asociado un vértice del grafo que lo identica. A partir de este grafo, y teniendo en cuenta la relación de precedencia, se puede fácilmente determinar si una versión, por ejemplo V 2, deriva de otra versión, V 1, pues sólo es necesario ver si existe un camino desde el primer vértice al segundo. Además, otra característica del grafo de versionado es la posibilidad de representar versiones alternativas, pues desde un mismo vértice pueden derivarse varias versiones. Por ejemplo en esta gura desde la versión V 2 se han generado tres nuevas versiones: V 3, V 5 y V 6 cada una con un nuevo estado del objeto versionable. A partir de los dos apartados anteriores se puede concluir que ambas técnicas, versionado lineal y versionado ramicado, permiten la gestión del ciclo de vida de un objeto pues mantienen la traza de derivación de sus distintos estados. En el primer caso, el versionado lineal, donde se usan aspectos temporales, se asocia a cada uno de los estados una información temporal que determina su validez y a través de los operadores de comparación se establece la derivación entre las distintas versiones. Sin embargo su uso no permite representar la historia con múltiples ramas de derivación, lo que se conoce como versionado no-lineal o ramicado. Además el uso de aspectos temporales suele partir de la premisa de que el estado de cada

41 Gestión de Cambios y Gestión de Versiones 23 objeto en un momento del tiempo es único. Sin embargo, en el caso de un sistema ramicado un mismo objeto no tiene por qué tener asociado un único estado en un instante de tiempo, sino que puede tener diferentes estados válidos simultáneamente Conclusiones En este primer apartado hemos presentado una serie de conceptos que se usarán a lo largo de la presente memoria. Entre todos ellos hemos puesto especial atención a las restricciones semánticas que denen los objetos versionables, es decir, si se gestionan los cambios únicamente para la última versión de los datos, versionado lineal, o en cualquiera de ellas, versionado ramicado o no lineal, pues este factor delimitará las funcionalidades del sistema gestor de versiones. En el primer caso, la identicación de las versiones suele realizarse mediante algún mecanismo que permite establecer un orden total entre las identicaciones, como puede ser el tiempo. En el segundo caso, cuando existen versiones alternativas, la derivación ya no es una secuencia lineal, sino que adopta la forma de un árbol o grafo de derivación. El sistema de control de versiones o gestor de versiones dependerá de algunas de estas características así como del tipo de documento con el que se va a trabajar, y dentro del documento seleccionado, de la granularidad del objeto susceptible de ser versionado, pudiendo ir desde el documento global hasta los diferentes elementos lógicos o físicos que lo componen. Si profundizamos en el concepto de control de versiones, surgen un conjunto de preguntas que deben responderse como cuál va a ser el objeto versionable a tratar (granularidad), cómo se detectarán los cambios, cómo se representarán las versiones y nalmente cómo se realizará su gestión. Para poder enfrentarnos a estas preguntas analizaremos los siguientes factores: 1. Granularidad de la información a versionar, que determina el objeto sobre el cual se va a realizar la gestión de la información. Éste depende a su vez de otros parámetros tales como el tipo de información: si se consideran documentos textuales, datos almacenados en una base de datos relacional, programas ejecutables, información binaria (sonido, vídeo, imágenes), etc. 2. Tipo de cambios, que determina cómo detectar la evolución del objeto. Fundamentalmente se han usado dos técnicas: a) Comparación de versiones, que consiste en detectar las diferencias entre dos estados de un mismo objeto. b) Primitivas de Cambio, que se basa en aplicar una secuencia de operaciones de cambio básicas que modican el objeto hacia un nuevo estado. 3. Gestión de control, que determina cómo se va a representar el ciclo de vida del objeto versionable. En el factor anterior se recogía cómo detectar los cambios y en éste se ja cómo se realiza su representación, pudiendo ser: a) Histórico de operaciones, que almacena los cambios producidos mediante comandos o instrucciones de modicación de modo que, aplicado a la información origen o destino, nos permitirá obtener los nuevos/antiguos estados. b) Histórico de valores, que mantiene la historia de todos los valores del objeto, siendo necesario especicar cuándo es válido cada uno de los valores, lo que se denomina validez.

42 24 Capítulo 2. Estado del Arte 4. Tipo de derivación. Tal y como se ha visto en los dos apartados anteriores pueden existir principalmente dos casos: versionado lineal y versionado ramicado. A continuación, en el resto de las secciones de este capítulo, analizaremos cada uno de estos factores para las principales fuentes de información, más concretamente: cheros planos, bases de datos, documentos semi-estructurados y nalmente, ya en profundidad, los documentos XML. Este estudio servirá para analizar cada uno de los factores anteriormente mencionados en estas fuentes de información así como, principalmente, para vericar si éstas cumplen las características de un sistema de versionado expuestas en el capítulo 1: capacidad de detectar y representar cambios, posibilidad de recuperar cualquier versión, soporte para versionado ramicado y capacidad para consultar los documentos con estándares XML Gestión de Cambios en Sistemas de Ficheros Desde la aparición de los primeros lenguajes de programación en los años 60, los desarrolladores de software dedican gran parte de su tiempo a labores de reescritura de código, debido a la constante necesidad de adaptar los programas a nuevas especicaciones o corregir fallos existentes. Este modo de trabajo se agilizaría notablemente si se dispusiera de herramientas para la gestión de los cambios realizados, de forma que se permitiera retroceder a un código fuente anterior si hubiera algún problema o se comprobase que la nueva implementación no se ajusta a las necesidades. Este tipo de herramientas reciben el nombre de software de control de versiones. Se puede decir que un sistema de control de versiones es un software que administra el acceso a un conjunto de cheros y mantiene un historial de cambios realizados. Las herramientas de control de versiones utilizan algoritmos de diferencias que trabajan o bien a nivel de líneas (si se trata de un documento textual) o bien a nivel de byte (si se trata de un chero binario). Su objetivo, por tanto, es encontrar el conjunto de diferencias existentes entre dos cheros obteniendo con ellos un chero de salida de cambios, denominado delta, que, aplicado al chero origen, nos permitirá obtener el segundo de ellos. Tal y como se expone en [Trielo 06] estas herramientas usan algoritmos matemáticos basados en grafos o matrices que permiten obtener las diferencias en base a operaciones básicas de inserción y borrado sobre una secuencia de elementos textuales. Los primeros acercamientos a esta materia se realizaron en el marco de la Gestión de Conguración (Conguration Management) para gestionar las versiones de desarrollo del hardware por los años 60. La primera implementación real se produjo en 1972 por los laboratorios Bell- Labs con la generación de SCCS (Source Code Control System) [Rochkind 75], posteriormente reescrito e incorporado en los sistemas operativos UNIX. Actualmente se encuentra en desuso aunque su formato sigue empleándose internamente en otros programas como BitKeeper y TeamWare. Posteriormente, en el año 1980, Walter F. Tichy desarrolla RCS [Tichy 85] para mejorar la herramienta anterior. Existen multitud de sistemas de control de versiones, como se puede comprobar en [Wikipedia-CRCS 08] pero, sin duda, el más popular es CVS [CVS 85]. CVS comenzó siendo un conjunto de scripts shell que usaba RCS y tuvo el mérito de ser el primer sistema utilizado por el movimiento de código abierto para que los programadores colaborasen remotamente mediante el envío de parches. Más recientemente ha surgido Subversion [Subversion 00] que solventa ciertos problemas que tiene CVS, tales como: permite realizar un conjunto de cambios

43 Gestión de Cambios en Bases de Datos 25 (transacciones), registra cambios en directorios de forma recursiva, acepta multitud de protocolos (http/s, webdav), utiliza un sistema centralizado consistente (base de datos Berkley) y permite el uso de cheros tantos textuales como binarios. En los últimos años están apareciendo sistemas descentralizados que se caracterizan porque no existe un repositorio central sino que incluyen varios repositorios distribuidos y descentralizados en diversas maquinas que pueden o no ser independientes entre si. Entre estos sistemas podemos destacar git, bazaar y mercurial. En [Wikipedia-CRCS 08] se muestra un gran número de soluciones de control de versiones para cheros con sus características principales. La principal ventaja de estas soluciones es que se encuentran ampliamente respaldadas y aanzadas por los años que llevan en uso pero no se recomienda su utilización para la gestión de versiones de documentos XML por las siguientes razones: Los documentos XML tienen una estructura de etiquetas anidadas que delimitan sus elementos y que los algoritmos de diferencias textuales tratan como simples caracteres, obviando de este modo la estructura jerárquica del documento. Este problema se pone de maniesto, por ejemplo, en un elemento XML formado por dos atributos que de un estado a otro cambian de orden. A nivel textual se establecería una diferencia en el documento, sin embargo a nivel estructural el documento no tendría ninguna diferencia, pues los atributos son componentes no ordenados de un documento XML. Lo mismo sucedería, por ejemplo, con los espacios en blanco que en documentos XML son no signicativos, o con los espacios de nombres que pueden especicarse de múltiples formas. No se pueden consultar las versiones o información de los documentos a partir de lenguajes estándares de consultas XML como XQuery o XPath. Precisan un alto coste computacional para recuperar una versión distinta de la actual, pues requieren la reconstrucción de todas las versiones anteriores, mediante la ejecución de las Delta, hasta llegar a la versión solicitada Gestión de Cambios en Bases de Datos Los primeros sistemas de bases de datos se sustentaron sobre los modelos jerárquicos y en red, mucho más cercanos a la forma en que los datos se almacenan físicamente, pero el modelo relacional se impuso posteriormente [Codd 70]. Su éxito reside por un lado en su sencillez, ya que el usuario percibe la base de datos como una serie de tablas, y, por otro lado, en el carácter declarativo de su lenguaje de consulta y manipulación (SQL), frente a sus predecesores que eran procedimentales. Con posterioridad aparecieron las bases de datos orientadas a objetos que denen a la base de datos en términos de objetos, sus propiedades y sus operaciones y surgieron para poder representar situaciones que por la rigidez del modelo relacional no se pueden representar, tal como los datos multivaluados. En las últimas décadas, los investigadores de bases de datos han intentado modelar aspectos no tradicionales de los datos, dando lugar a las bases de datos deductivas, multimedia, espaciales, etc [Zaniolo 97]. Entre ellas se encuentran dos aspectos relacionados con esta tesis que nos ocupa. Por una parte, las Bases de Datos Temporales, que mantienen la información histórica de los datos, y, por otra parte, el Versionado de Esquema, que amplía la gestión de cambios al nivel de esquemas de una base de datos. En las bases de datos es fundamental determinar qué tipo de información es susceptible de cambio, pudiendo existir distintas granularidades: atributos, grupo de atributos, tupla, obje-

44 26 Capítulo 2. Estado del Arte to, colección de tuplas u objetos o incluso el esquema. Obviamente este factor dependerá del modelo inherente seleccionado. A continuación analizamos algunas soluciones propuestas relacionadas con los dos aspectos mencionados anteriormente para las bases de datos relacionales y orientadas a objetos Bases de Datos Relacionales La gestión de cambios de los datos relaciones se ha realizado principalmente mediante lo que se conoce como bases de datos temporales. Las bases de datos temporales se basan en modelos de datos temporales que denen una estructura de datos, las operaciones y las restricciones de integridad que son necesarias para representar información variante o cambiante en el tiempo. Por lo general, los modelos de datos temporales asocian a los datos una historia o marca de tiempo; dicha asociación se denomina marcado temporal (timestamping). Para realizar este marcado se pueden usar distintos tipos de datos temporales: Instante de tiempo: Está denido como un punto de tiempo en un eje o dominio del tiempo. Cada instante de tiempo representa un crono [Tansel 93], que es la mínima duración de tiempo que puede ser representada en el modelo de tiempo. Intervalo de tiempo: Utilizado para representar un conjunto de instantes de tiempo consecutivos y denido por los extremos de dicho conjunto. Su principal problema es que no es cerrado con respecto al conjunto de operaciones básicas que se pueden realizar con ellos pues, por ejemplo, la unión de dos periodos de tiempo disjuntos no consecutivos no es un periodo de tiempo. Elementos temporales: Aparecieron para solventar los problemas de los periodos de tiempo. Éstos se denen como la unión nita de periodos de tiempo [Gadia 86] y tienen la propiedad de que son cerrados para la mayoría de las operaciones de conjuntos. Éstos conducen a trabajar con atributos no atómicos, modelos de datos orientados a objetos o esquemas que no se encuentran en primera forma normal (1FN). En una base de datos temporal cada dato puede tener asociado uno o varios dominios de tiempo, donde cada uno de ellos representa una interpretación de tiempo diferente. Los investigadores de bases de datos temporales han establecido fundamentalmente dos dimensiones temporales [Tansel 93]: tiempo válido y tiempo transaccional. El primer concepto se centra en el tiempo de un hecho desde el punto de vista de su validez (esta noción de tiempo almacena el dato junto a la información de cuándo fue, es o será válida en el mundo real), mientras que el segundo representa cuándo los hechos son guardados en la base de datos, siendo normalmente de solo lectura. Otras dimensiones temporales que se han analizado son: tiempo de usuario [Snodgrass 86] o tiempo de publicación [Cabo 99]. Según se considere alguna de estas dimensiones, los investigadores principalmente han distinguido 4 tipos de bases de datos temporales [Snodgrass 95]: instantáneas, históricas, transaccionales y bitemporales. Por lo general las bases de datos temporales relacionales modelan la información histórica de las tuplas contenidas en las tablas de la base de datos, por lo que cada atributo o tupla susceptible de cambio debe tener asociado una marca temporal. Los dos mecanismos usados para el marcado temporal en una base de datos relacional son: Marca de tiempo a nivel de tupla: Se añade una marca de tiempo a cada tupla de la relación indicando cuándo cada tupla fue, es o será válida. La principal desventaja de

45 Gestión de Cambios en Bases de Datos 27 este tipo de marcado temporal es la redundancia de datos que origina pues, el hecho de que cada tupla represente un estado del mundo real, conlleva que la modicación del valor de un único atributo implica la inserción de una nueva tupla, idéntica a la original exceptuando el valor del atributo modicado. Esta redundancia es conocida como anomalía vertical (tabla 2.1). Marca de tiempo a nivel de atributos: Esta idea surge para eliminar la desventaja de la aproximación anterior, la existencia de datos redundantes. El uso de marca de tiempo a nivel de atributos añade una marca de tiempo a cada valor del atributo (tabla 2.1). Obviamente para poder llevar a cabo esta solución es necesario que el modelo relacional tenga soporte para datos multivaluados. Tabla 2.1: Marcado Temporal en una BDR Marcado a Nivel de Tupla IdObjeto Ubicación Tiempo Comienzo Tiempo Final O3567 Veletas [ ] [ ] O3567 Conservación [ ] [ ] O3456 Regional [ ] O3567 Veletas [ ] Marcado a Nivel de Atributo IdObjeto Ubicación [ , ]>3567 [ , ],[ , ]>Veletas [ , ]>Conservación [ , ]>O3456 [ , ]>Regional Ejemplo: En la tabla 2.1 se muestran los dos tipos de marcado temporal en bases de datos relacionales. En este ejemplo se almacena en una tabla la información de los movimientos de los objetos de museos. Esta viene denida por el identicador del objeto junto con la situación actual del objeto. En un momento dado t1, la tabla movimientos tiene almacenada unos datos que posteriormente en un instante t2 se realiza una operación de actualización sobre los datos de la tabla. De este modo, se puede comprobar que el objeto O3567 ha tenido dos ubicaciones a lo largo de su vida: por una parte el museo Veletas, cuyo valor ha sido transaccionalmente válido en dos intervalos de tiempo no consecutivos, y por otra Conservación, cuya validez se ha producido desde [ ] al [ ]. Se puede constatar mediante el ejemplo que en un marcado a nivel de tupla la información debe replicarse cuando el mismo estado de una tupla es válido en intervalos de tiempo distintos, mientras que en el caso de un marcado a nivel de atributo, esta situación no se produce. Dentro de esta línea de investigación son muchísimas las propuestas realizadas, tal y como recoge Grandi en un recopilatorio de publicaciones sobre esta temática [Grandi 04]. En este apartado resumiremos muy brevemente las aportaciones más signicativas. Se han denido, además, un gran número de modelo de datos temporales [Ozsoyoglu 95], que resumimos en la tabla 2.2, indicando sus dimensiones temporales, así como el lenguaje temporal de consulta.

46 28 Capítulo 2. Estado del Arte Tabla 2.2: Modelo de Datos y Lenguajes Temporales Relacionales Modelo de Dato Dimensiones Lenguaje de Consulta Referencia HDM T. Válido HDM [Cliord 83] HDRM T. Válido HDRM [Cliord 87] Lorentzos T. Válido [Lorentzos 88] Navathe T. Válido TSQL [Navathe 89] Sadeghi T. Válido HQL [Sadeghi 87] Sarda T. Válido HSQL [Sarda 90] Segev T. Válido TDM [Segev 87] TQuel Bitemporal TQuel [Snodgrass 87], BCDM Bitemporal+Usua. TSQL2 [Jensen 94] TIMEDB Bitemporal+Usua. ATSQL [Steiner 98] También se ha establecido un conjunto de operadores temporales para operar especícamente sobre datos temporales [Allen 83, Tansel 93, Snodgrass 95], así como una serie de operaciones para recuperar la información almacenada [Snodgrass 86, Tansel 93, Böhlen 95, Steiner 98, Dyreson 03]: proyección temporal, selección temporal, join temporales así como funciones de agregación sobre los datos temporales. Igualmente han sido numerosos los lenguajes que denen nuevos constructores sobre el lenguaje SQL para incorporarle características temporales. Partiendo de los primeros lenguajes temporales, HSQL [Sarda 90], HRDM [Cliord 87] y TQuel [Snodgrass 87], podemos considerar TSQL2 [Snodgrass 95] como el padre de todos ellos, pues fue el primer lenguaje en atender las especicaciones del estándar y una gran parte de los investigadores del campo de las bases de datos temporales contribuyeron en su desarrollo. En 1994 Snodgrass, propuso una nueva versión para el estándar SQL conocido como SQL3 [Eisenberg 99]. Este lenguaje incorpora un apartado que da cabida a la modelización del tiempo en el lenguaje SQL conocido como SQL/Temporal. En noviembre de 2007 se realizó una nueva propuesta de estandarización de SQL, denominado SQL4 [Combi 07]. Finalmente se han realizado distintas implementaciones, algunas de ellas resumidas en [Böhlen 95], entre las que merecen una mención especial las siguientes: Cronolog [Böhlen 94] (temporal deductiva, marcado a nivel de tupla, tipo de dato intervalo, tiempo válido), TimeDB [Steiner 98] (temporal, marcado a nivel de tupla, intervalo como tipo de dato, bitemporal) y TimeMultiCal [Soo 93] (temporal, marcado a nivel de tupla, intervalo como tipo de dato, bitemporal). Versionado de Esquemas Los cambios de esquemas en las bases de datos relacionales pueden provocar que los datos almacenados en las tablas no puedan ser recuperados por las aplicaciones que usan un esquema distinto al que actualmente es usado por la base de datos. [Roddick 93] muestra una taxonomía de cambios basada en tres clases para los esquemas relacionales: evolución del dominio, evolución de la tabla y designación de atributos-tablas donde también este trabajo proporciona posibles soluciones para cada uno de ellos. A nivel relacional principalmente se han usado dos soluciones para el versionado de esquemas: 1) basada en vistas, también denominada esquema completo [Roddick 91], que consiste en formar cada una de las versiones de las tablas de la base de datos uniendo los atributos que han sido denidos a lo largo de la vida de la relación, 2) basada en dimensiones tempo-

47 Gestión de Cambios en Bases de Datos 29 rales [Roddick 95, De Castro 97, Edelweiss 05], cuyo objetivo es la denición de dimensiones temporales en el diccionario de datos que identiquen en cada instante el esquema con el cual se trabaja Bases de Datos Orientadas a Objetos Al igual que en el caso anterior se pueden establecer dos niveles de cambios en las bases de datos orientadas a objetos: los que afectan a los valores de las instancias de la base de datos y los que afectan al esquema. Para el primer tipo de cambio una posible solución, al igual que en el modelo relacional, son las bases de datos temporales orientadas a objetos que se encargan de asociar una marca temporal a cada uno de los valores de los atributos. En [Bertino 96] se clasican los distintos tipos de atributos temporales que pueden ser modelados en una base de datos temporal, distinguiéndose entre temporal, inmutable y no-temporal. Un atributo temporal es un atributo cuyo valor varía a lo largo del tiempo y sus sucesivos valores deben ser almacenados en la base de datos. Un atributo inmutable es aquel que no puede variar a lo largo del ciclo de vida del objeto. Un atributo no temporal es aquel que puede evolucionar pero no queda constancia de ello en la base de datos. En la tabla 2.3 se muestra un resumen de los principales modelos temporales orientados a objetos junto con algunas de sus características. Esta tabla se ha obtenido de los trabajos [Kim 95] y [Bertino 96] donde analizan en detalle estos modelos de datos. La columna atributos temporales indica el tipo de atributo temporal que dene y la columna siguiente presenta las dimensiones temporales para el modelo en cuestión, pudiendo ser Tiempo Válido (TV) y Transaccional (TT). La columna de Marcado reeja las dos posibles soluciones para asociar información histórica en los modelos de datos orientados a objetos: Objeto (si se asocia una marca de tiempo a todo el estado del objeto replicando el valor de cada uno de los atributos cuando únicamente varía una parte de él) y Atributo (si se asocia una marca de tiempo a cada uno de los atributos que forman parte del objeto). De este modo para recuperar un determinado estado, en el primer caso, es necesario realizar la instantánea del objeto completo para el tiempo solicitado mientras que en el segundo caso existen distintas soluciones para recuperar su valor válido: funciones de usuario y secuencia de valores, como se muestra en la columna Rec. Estado de la tabla 2.3. La columna ref son las referencias de los modelos de datos 1. De entre todos estos modelos nos gustaría resaltar T-Chimera [Guerrini 98], pues fue la primera denición formal de un modelo de datos temporal orientado a objetos, así como TIKUGAT [Goralwalla 94] y TOM [Steiner 98], los cuales son modelos de datos similares a T-Chimera. Finalmente, se debe también destacar el modelo de datos TOODOR [Cabo 01], usado para la representación y consultas de documentos con características temporales. 1 La numeración de la columna referencia de la tabla 2.3se corresponde con las siguientes publicaciones: 1-[Cliord 88] 2-3- [Goralwalla 94] 4- [Käfer 92] 5- [Pissinou 93] 6- [Rose 91] 7- [Su 91] 8- [Tansel 93] 9- [Guerrini 98] 10- [Steiner 98]

48 30 Capítulo 2. Estado del Arte Tabla 2.3: Resumen de modelos de Datos Temporales OO Ref Modelo de Datos OO 1 generic 2 OODaplex 3 TIGUKAT 4 MAD 5 3DIS 6 generic 7 OSAM 8 OODAPLEX 9 T-Chimera 10 TOM Atributos Temporales Dominios Temporales Marcado Rec. Estado Temp Inmu no-temp x Tv Atributo Funciones x Tv Atributo Funciones x Tv Ambos Pares de Valor x Tv+Tt Objeto Atómico x Tv Atributo x Tv+Tt Atributo Sequencia de tuplas x Tv Objeto Atómico x Tv Ambos Funciones Tv Atributo Funciones Tv+Tt Atributo Funciones Versionado de Esquemas Debido a la exibilidad que tienen los modelos de datos orientados a objetos para representar datos más complejos, desde las década de los 80 los investigadores han centrado sus esfuerzos en la gestión de cambios de los esquemas pues observaron un amplio abanico de campos de aplicación, como por ejemplo diseño asistido por computador (CAD), manufacturación o herramientas CASE, donde los objetos tienen una mayor complejidad. En este apartado no entraremos en detalle pero se comentarán brevemente las soluciones propuestas porque los mismos problemas, ya abordados para las bases de datos, los podemos encontrar en la gestión de cambios de esquemas XML. El modelo relacional, por su simplicidad, presenta un conjunto limitado de operaciones de evolución del esquema, sin embargo, el modelo orientado a objetos contempla aspectos que aumentan la complejidad del versionado de esquemas (redeniciones de métodos, reorganizaciones de jerarquías de herencia, tipos complejos de datos...). La granularidad del versionado de esquema se puede establecer en dos niveles: a nivel de toda la base de datos y a nivel de clase. El problema del versionado de esquemas en BDOO se pone de maniesto en [Skarra 87, Bertino 93] donde se muestra una taxonomía inicial de cambios, proponiéndose también una solución que recurre a manejadores para mantener la consistencia de comportamiento de las instancias persistentes respecto de las aplicaciones que las utilizan. A la hora de gestionar estos cambios básicamente deben resolverse dos problemas: por una parte los posibles problemas inducidos por la semántica del cambio en sí, pues no todo cambio esta permitido y, por otra, la propagación del cambio en las instancias. Referido al primer punto es necesario denir un conjunto de reglas que mantengan la consistencia del esquema, que deben comprobarse cada vez que se produzca una modicación y que son conocidas como Invariantes del esquema ; en segundo lugar la adaptación de las instancias, que puede ser o bien en base a funciones de conversión [Ferrandina 94, Lautemann 96], o bien mediante vistas. [Roddick 95] distingue entre evolución y versionado de esquema. El primer concepto se caracteriza porque no se pierde información al adaptar las antiguas instancias al nuevo esquema y el segundo permitiría acceder a la información vieja bajo esquemas recientes, y a la

49 Gestión de Cambios en Documentos Semi-Estructurados 31 información nueva bajo esquemas antiguos. En este segundo caso se utilizan grafos dirigidos acíclicos, (DAGs), para representar la evolución de los esquemas. Por ejemplo en [Cellary 90] se utiliza un marcado en las instancias basado en un grafo de derivación. Si una versión de la base de datos tiene un marcado de la forma i, entonces las versiones derivadas de esta versión tendrá la forma i.j. Por cada uno de los objetos de la base de datos existe una tabla que relaciona en qué versiones dicho objeto es válido. Nótese que se puede establecer un paralelismo de este trabajo con el presentado en esta memoria, pues nosotros almacenamos el grafo de derivación del documento XML y marcamos cada componente XML con información procedente de este árbol. Finalmente nos gustaría destacar como bibliografía básica algunos modelos de versionado de esquemas clásicos como ORION [Banerjee 87], GemStome [Bretl 89] y O 2 [Ferrandina 95] y los trabajos [De Castro 97, Lautemann 99, Grandi 03a, Edelweiss 05]. Conclusiones: Teniendo en cuenta la información aportada en esta sección podemos armar que la gestión de cambios en el campo de las bases de datos, tanto relacionales como orientadas a objeto, ha sido ampliamente estudiada. Podemos concluir que, dependiendo de varios factores: como por ejemplo la granularidad del objeto considerado o si el modelo es relacional u orientado a objetos, se han propuesto distintas soluciones: el uso de vistas, la asociación de un dato temporal o la utilización de grafos de derivación (DAG). Aunque las bases de datos dieren de los documentos XML, su estudio nos ha permitido extraer conclusiones sobre las soluciones propuestas y comprender mejor su posible aplicabilidad a los documentos XML, las ventajas que tienen las soluciones temporales (su fácil aplicabilidad), así como su principal inconveniente: carecen de soporte para versionado ramicado debido a la naturaleza lineal del tiempo Gestión de Cambios en Documentos Semi-Estructurados Hasta ahora se han analizado sistemas de información con una estructura ja, bien denida, sin embargo también existen sistemas que se caracterizan por modelar la información almacenada siguiendo una estructura irregular e incompleta tal y como se dene en [McHugh 97]. Este nuevo concepto surge ante la necesidad de tratar información que no se adapta a un formato tan estricto como las bases de datos y que tampoco puede gestionarse de forma libre como en los sistemas de recuperación textual. Por ejemplo, imaginemos que se desea crear una agenda de contactos que almacene los restaurantes de nuestra ciudad. Antes de decidir qué sistema utilizar para almacenar la información, observamos la naturaleza de los datos. Hay restaurantes que pueden modelarse simplemente teniendo en cuenta su nombre, dirección y el precio de su menú, mientras que podemos encontrarnos otros establecimientos con una información más dispar. Esta situación se muestra con mayor detalle en la gura 2.3, donde se recurre a un documento semiestructurado para modelarla. El modelo canónico para documentos semiestructurados es OEM (Object Exchange Model) [Papakonstantinou 95] dentro del proyecto TSIMMIS [Hammer 97]. OEM se basa en un grafo dirigido etiquetado donde sus nodos representan un objeto o un valor y los objetos complejos son denidos mediante arcos etiquetados de salida entre los nodos, formando la escasa estructuración del documento. Este modelo fue implementado en una base de datos semiestructurada denominada Lore [McHugh 97] la cual disponía del lenguaje LOREL [Abiteboul 97], que es una extensión del lenguaje OQL [Alashqur 89] orientado a datos semiestructurados, para las consultas de los usuarios.

50 32 Capítulo 2. Estado del Arte Con posterioridad también se ha abordado la gestión de información variante en este tipo de documentos. El primero de ellos fue [Chawathe 98, Chawathe 99] que describe el modelo de datos Delta OEM (DOEM) para la gestión de información histórica en documentos semiestructurados. En este trabajo los autores añaden a cada arco del grafo información (delta) acerca de cuándo se realizó el cambio así como del tipo de cambio realizado. Para ello denen los cambios básicos que se pueden realizar sobre un grafo OEM y establecen que el proceso de reconstrucción de una determinada versión del grafo consiste en aplicar las transformaciones almacenadas en los arcos al grafo inicial para conseguir la versión requerida. En [Chawathe 98] los mismos autores denen Chorel, un lenguaje de consulta para este modelo de datos. Figura 2.3: Ejemplo de un documento OEM Ejemplo: La gura 2.3 muestra un grafo semiestructurado que almacena la información de dos restaurantes siguiendo el formato OEM. Su grafo equivalente representado en DOEM que asocia además información histórica a los arcos se muestra en la gura 2.4. Analizando la gura 2.3 se observa que la estructura del grafo no es ja, pues el arco address puede contener valores atómicos en unos casos (por ejemplo 120 Lyon) mientras que en otras ocasiones podría estar formado por un conjunto de nodos complejos. En la gura 2.4 cada arco del grafo contiene información de su historia, además del nombre de su etiqueta, indicando el momento en que fue realizada la operación de cambio. Por ejemplo, en Enero de 1997 se añadió un tercer restaurante al grafo. Siguiendo la misma losofía que Chawathe (DOEM), añadir información a los arcos del grafo, [Oliboni 01] propone un modelo de datos gráco así como un lenguaje de consultas para documentos semiestructurados con tiempo transaccional y [Dyreson 99] lo completa incorporando tanto el tiempo válido como el tiempo transaccional. En ambos casos, la solución elegida consiste en añadir un intervalo de tiempo a cada arco para indicar el periodo de validez de los arcos y de todos sus descendientes. Finalmente, en [Stavrakas 02, Stavrakas 04] los autores almacenan en un mismo documento semiestructurado distintas dimensiones o versiones empleando lo que denomina vértices multidimensionales. En este caso los autores añaden a los arcos del grafo dos dimensiones: por una parte, una dimensión temporal que permite representar la validez de la información y por otra parte, una dimensión dependiente del contexto del usuario. Por ejemplo, en el caso anterior del documento semiestructurado de restaurante permitiría denir para el arco price

51 Gestión de Cambios en Documentos XML 33 Figura 2.4: Ejemplo de un documento DOEM del restaurante distintos contextos basados en la moneda: euro, libras, etc. Posteriormente los mismos autores modelan estos documentos semiestructurados mediante documentos XML en [Gergatsoulis 03] pero no aportan dato alguno sobre cómo realizar las consultas. Podemos concluir de este apartado que estos documentos aportan una gran exibilidad a la información almacenada por lo que se han utilizado principalmente para el intercambio e integración de Datos que provienen de distintas bases de datos. Su estudio nos ha ayudado en gran medida a comprender mejor el modelo de datos de documentos XML, también basado en grafos, y cómo meta-etiquetando dichos grafos se puede mantener la historia de sus valores y de su estructura Gestión de Cambios en Documentos XML Después de analizar para las distintas fuentes de información cómo éstas han resuelto el problema de la evolución de la información que almacenan, en este apartado analizaremos las soluciones que se han propuesto para la gestión de versiones de documentos XML. En primer lugar introduciremos qué es un documento XML, así como un pequeño conjunto de estándares relacionados con él, para posteriormente analizar las principales soluciones para gestionar sus cambios Tecnología XML Documentos XML En 1969 IBM creó el lenguaje GML (Generalized Markup Language) que sirvió como base para el estándar ISO 8879 más conocido como SGML (Standard Generalized Markup Language). SGML dene un marco de trabajo en el cual pueden denirse lenguajes de marcado para diferentes propósitos. Debido a la complejidad de este lenguaje se realizó una simplicación y

52 34 Capítulo 2. Estado del Arte adaptación del SGML denominada XML. El estándar XML [Bray 98], acrónimo en inglés de Extensible Markup Language (lenguaje de marcas extensible), es un metalenguaje de etiquetas desarrollado por el World Wide Web Consortium (W3C)[W3C 94] que permite denir la gramática de otros lenguajes. Los documentos XML se caracterizan por el empleo de marcas, de apertura y cierre, para etiquetar la información que contienen. Las etiquetas de inicio se denen con el formato <nombre_etiqueta>, mientras que las de cierre usan el formato </nombre_etiqueta>. A diferencia de HTML, en un documento XML toda etiqueta de apertura tiene su correspondiente etiqueta de cierre, denominándose a este anidamiento elemento. Los elementos XML determinan la estructura del documento y pueden estar formados por contenido (caracteres donde realmente reside la información), subelementos (elementos hijos anidados) o elementos vacíos (no contienen información). Cada elemento XML puede incluir información adicional, normalmente añadiendo atributos en la etiqueta de inicio. Cada atributo se especica mediante un nombre y un valor encerrado entre comillas. Todo documento XML debe satisfacer las reglas de especicación de documento XML bien formado [Sperberg-McQueen 04]. Denición 1. Documento XML Bien Formado Un documento XML se dice que está bien formado si cumple las reglas de especicación siguientes [Sperberg-McQueen 04]: 1. Estructura jerárquica de elementos: El documento debe tener una estructura estrictamente jerárquica en lo que respecta a las etiquetas que delimitan sus elementos. Una etiqueta debe estar correctamente incluida en otra, es decir, las etiquetas deben estar correctamente anidadas. 2. Un sólo elemento raíz. Los documentos XML sólo permiten un elemento raíz, del que son descendientes el resto de elementos. 3. Atributos únicos por cada elemento. Para un determinado elemento no pueden existir dos atributos con el mismo nombre. Denición 2. Documento XML Válido Un documento XML se dice que es válido si está bien formado y además el documento se ajusta a las reglas de un documento esquema. Un esquema es una especicación formal de las normas de un documento XML que indica qué elementos, atributos y qué combinaciones de ellos están permitidas. En la actualidad existen múltiples lenguajes de denición de esquemas [Lee 00] entre los que destacamos principalmente DTD y XML-Schema [Fallside 01], Relax-NG. En la gura 2.5 se muestra un documento XML que almacena información de los restaurantes y cocineros de una determinada ciudad junto con su denición en formato XML-Schema. El nodo raíz de este documento es doc y está formado por subelementos hijos: cook, que no contiene ninguna información textual asociada, y dos elementos rest formados a su vez por varios subelementos. El elemento cook está formado por dos atributos id y name con valores c1 y Arzak respectivamente. Un documento XML puede estar formado por otros componentes aparte de elementos y atributos: entidades (representan símbolos atómicos, encerrados entre los símbolos & y ; que son entendidos por el procesador), comentarios (encerrados entre <! y > al igual que en HTML), secciones CDATA (utilizadas para indicar una parte del documento XML que tiene que ser interpretada tal cual, sin hacer ningún procesamiento de su contenido).

53 Gestión de Cambios en Documentos XML 35 Figura 2.5: Documento XML de Restaurantes y Cocineros Otros Estándares XML Como ya adelantamos al comienzo de este apartado, XML no puede considerarse realmente un lenguaje, sino que más bien debe ser visto como un medio para denir lenguajes que den solución a diferentes necesidades. Por este motivo se ha extendido rápidamente como un formato universal extremadamente versátil que permite almacenar datos de muy diversa naturaleza: páginas web (XHTML), mensajes web entre aplicaciones (SOAP), representación de bases de relacionales, interfaces de usuario (XUL), transacciones nancieras y bancarias (XRL), grácos vectoriales (SVG), sindicación de contenidos (RSS), archivos de conguración, documentos omáticos OpenOce.org (.odt) o Microsoft Oce 2007 (.docx), etc. Además, su uso crece cada día y es que, junto a XML, se han propuesto estándares como XPath [Clark 99b, Fernández 05] para construir expresiones que recorren y procesan un documento XML, XSLT [Clark 99a, Kay 07] para la transformación de los datos XML usando reglas de plantillas o lenguajes de consulta como XQuery [Boag 07] para consultar colecciones de datos XML que dotan a esta tecnología de gran potencia y compatibilidad entre sistemas. Analizaremos brevemente estos tres estándares pues serán usados a lo largo de la tesis para la recuperación y/o transformación de documentos XML. XPath [Clark 99b], abreviatura de XML Path Language, es un lenguaje que permite denir expresiones para la localización de nodos y fragmentos en árboles XML. Cuando un documento XML es procesado por un analizador (o parser) se construye su árbol de nodos (árbol DOM - Document Object Model), el cual comienza por un elemento raíz con sus elementos descendientes y acaba en los nodos hoja, que contienen texto, comentarios, instrucciones de proceso o están vacíos. De este modo, este estándar proporciona una sintaxis para localizar y devolver un conjunto de nodos de este árbol. La evaluación de las expresiones tiene lugar con respecto a un nodo contexto que se de- ne como el nodo del árbol que se toma como punto partida para evaluar la expresión. Las expresiones XPath se construyen a partir de un camino de localización (location paths) que especica el patrón de búsqueda sobre el árbol de nodos. Este patrón se establece a partir de tres partes: 1) un eje, que especica la relación jerárquica entre los nodos seleccionados por el paso de localización y el nodo contextual (tabla 2.4), 2) nodo que especica el tipo de nodo y el nombre-expandido de los nodos seleccionados y 3) los predicados que sirven para renar aún más el conjunto de nodos seleccionados por el paso de localización. Adicionalmente se pueden

54 36 Capítulo 2. Estado del Arte Tabla 2.4: Ejes del lenguaje XPath Eje Descripción Abreviatura child Contiene los hijos del nodo contextual descendant Contiene los descendientes del nodo contextual./* parent Contiene el padre del nodo contextual.. ancestor Contiene los ancestros del nodo contextual following-sibling Contiene los hermanos que siguen al nodo contextual preceding-sibling Contiene los hermanos que preceden al nodo contexto following Contiene todos los nodos que siguen al nodo contexto preceding Contiene todos los nodos que preceden al nodo contexto attribute Contiene los atributos del nodo self Contiene el propio nodo contextual. descendant-orself Contiene el nodo contextual y sus descendientes.// ancestor-or-self Contiene el nodo contextual y sus ancestros usar un conjunto de funciones que proporcionan mayor libertad de consulta al lenguaje. En la consulta 2.1 se ilustra un ejemplo de expresión XPath compuesta por cada una de las partes que conforman un camino de localización: se han usado los ejes /, //, attribute y child, los nodos doc, rest y *, el predicado = y la función position(). El resultado de la expresión es el conjunto de nodos situados en la posición 2 de los elementos rest cuyo atributo id tiene el valor r1, recuperándose en este caso el elemento XML menu para el documento de la gura 2.5. Consulta 2.1 Ejemplo de Expresión XPath 1 /doc//rest[attribute::id='r1']/child::*[position()=2]. XPath es la base principal sobre la que se han especicado otros estándares como XQuery y XSLT. XSLT [Clark 99a], abreviatura de XML Stylesheets Language for Transformation, es un lenguaje estándar para la transformación de documentos XML en otros formatos que incluso puede que no sean XML. Un documento XSLT es un documento XML donde se establece qué transformaciones se desean realizar y sobre qué partes del documento XML se van a realizar. Para el primer aspecto el propio XSLT dene un conjunto de constructores, y para el segundo XSLT se basa en la sintaxis que dene XPath. El elemento raíz de un documento XSLT es xsl:stylesheet y entre sus etiquetas se escriben las reglas de transformación propiamente dichas. Cada regla se dene mediante un elemento xsl:template, donde se indica a qué instancias de los elementos del documento XML de entrada se va a aplicar, además de cómo se van a transformar cada una de ellas. La gran ventaja del

55 Gestión de Cambios en Documentos XML 37 XSLT es la capacidad de transformar un único documento XML en innidad de formatos y de adaptar el contenido y la presentación para que se ajuste a cualquier medio, ya sean dispositivos visuales, móviles, etc.... XQuery [Boag 07], XML Query Language. Con la aparición de XML surgieron un gran número de lenguajes para la recuperación de su información: YaTL [Christophides 00], XQL [Robie 98], XML-QL[Deutsch 98], siendo XQuery [Boag 07] el lenguaje estándar para la consulta de documentos XML establecido por la W3C. XQuery es un lenguaje representado mediante una expresión que recibe una secuencia de datos XML como entrada y devuelve como resultado otra secuencia de datos XML de salida o incluso en otro formato. Una consulta XQuery puede estar compuesta por las siguientes cláusulas For, Let, Where, Order y Return (llamado FLWOR) donde: For: Genera una secuencia de datos de entrada a iterar a partir de una expresión XPath Let: Asocia el resultado de una expresión a una variable Where: Filtra la secuencia de entrada que no cumpla las condiciones dadas Order by: Ordena el resultado según el criterio dado Return: Construye el resultado de salida. Consulta 2.2 Ejemplo de Consulta XQuery 1 for $b in doc('rest.xml')//rest 2 let $c := $b/menu 3 where $c = 'Spanish' 4 order by $b/price 5 return <result>{ ($b/name,$b/price)}</result>. Ejemplo: En la consulta 2.2 se muestra un ejemplo de una consulta XQuery compuesta por las cinco cláusulas FLWOR. Esta consulta recupera el nombre y el precio de los restaurantes ordenados por su precio cuyo menú es Spanish. En primer lugar en la clausula for se establece la secuencia de entrada, todos los elementos rest de rest.xml. A continuación se dene la condición (where) que deben cumplir estos elementos: que el menú del restaurante representado en la variable $c sea igual a Spanish y nalmente en la clausula order by se establece el orden del resultado (return) compuesto por la información de los elementos name y price que cumplen la condición anterior. A continuación, y una vez introducidos los documentos XML, así como algunos de sus estándares usados en la tesis, analizaremos las principales soluciones para la gestión de versiones de documentos XML Delta XML En la sección 2 del presente capítulo analizamos las soluciones para el control de versiones en cheros, que consiste en obtener las diferencias textuales o binarias entre dos versiones de un

56 38 Capítulo 2. Estado del Arte mismo chero. En dicho apartado llegamos a la conclusión de que su uso en documentos XML no era recomendable pues estas soluciones no tenían en cuenta la estructura de un documento XML a la hora de obtener las diferencias. En este apartado analizaremos una aproximación, similar a esta, exclusivamente diseñada para obtener las diferencias en documentos XML. De este modo, esta solución consiste en obtener el conjunto de diferencias XML existentes entre dos documentos generando un chero de salida de cambios, denominado delta XML, que, aplicado al chero origen, nos permite obtener el documento destino. Fundamentalmente existen dos tipos de delta XML que dieren entre sí por la cantidad de información que necesitan almacenar sobre los cambios producidos [Marian 01, Cobena 02]: 1. Delta XML básica, que almacena la información mínima sobre el cambio. 2. Delta XML completa, que almacena toda la información del cambio producido. A la hora de trabajar con estos cheros de diferencias se pueden escoger distintas políticas de almacenamiento [Cobena 02]: Última versión + deltas básicas anteriores: El documento XML almacena la última versión y la recuperación de versiones anteriores consistiría en deshacer los cambios almacenados en el documento Delta. Primera versión + deltas básicas posteriores: Esta solución es análoga a la anterior. El documento XML almacena la primera versión del documento y para obtener la última versión, debe irse propagando cada uno de los cambios realizados. Almacenar la primera versión + última versión + deltas básicas posteriores: Mediante esta solución se intenta solventar el problema de recuperar la última o primera versión. Estas dos versiones se encuentran almacenadas junto con las operaciones de cambios que se han producido. Como se expone en [Cobena 02] ninguna de estas políticas presenta ventajas sobre las otras, pues siempre es necesario ejecutar los script de edición para recuperar una versión distinta a la actual. No obstante, la elección de la política se realizará teniendo en cuenta distintos factores (número de versiones, el número de cambios, etc) debido a que, por ejemplo, la última política reduce el tiempo de reconstrucción de versiones intermedias pero conlleva una mayor ocupación de disco. Para obtener un documento DeltaXML se utilizan algoritmos matemáticos, donde los documentos son representados mediante estructuras arbóreas o de grafo (con la semántica propia de los documentos XML), para encontrar las similitudes existentes entre estas estructuras y así obtener las diferencias en base a operaciones básicas de inserción, borrado y actualización. En la gura 2.6 se muestra un ejemplo de la comparación realizada entre dos versiones de un mismo documento. Como podemos comprobar el resultado determina que se ha realizado una operación de actualización del nodo 4 (ubicación) y una inserción en la posición 2 para el nodo 5. A la hora de realizar estas comparaciones existen principalmente dos tipos de algoritmos: Árbol ordenado (Ordered Tree), donde se modela tanto la relación padre-hijo como la relación de orden izquierda-derecha entre los hermanos de un nodo y Árbol No-Ordenado (Unordered tree), donde esta última relación no se recoge. En el primer caso las operaciones que pueden detectarse serían las de inserción, borrado, modicación y movimiento de un nodo mientras

57 Gestión de Cambios en Documentos XML 39 Figura 2.6: Comparación de dos versiones usando DeltaXML que en el segundo la operación de movimiento no se podría detectar al no existir la relación entre hermanos. En [Gregory Cobena 02, Al-Ekram 05, Rönnau 05, Peters 05] se muestran en detalle las principales soluciones de diferencias XML y se analizan sus características en base a la complejidad de computación del algoritmo, tipo de algoritmo utilizado, tamaño de memoria requerido, chero delta generado, las operaciones que es capaz de realizar, etc. La tabla 2.5 ilustra las principales características de estos algoritmos de forma resumida 2. Tabla 2.5: Comparativa de Algoritmos de Diferencias XML Algoritmo Tipo Operaciones Tiempo Refer. Otras Ord NoO I D U M C LaDi X O(ne+e2 ) 1 Latex MH-Di O(n2 log n) 2 3DM X O(n) 3 Libre XyDi O(n log n) 4 Libre: C++/java VMTools?????? 5 DiXml X O (ne+e2 ) 6 X-Di X X O(n2 ) 7 DeltaXML? 8 Comercial dix O(n) 9 Ord: Ordenado NoO: No-Ordenado Operaciones: I- Insertar D- Borrar U- Actualizar M- Mover C- Copiar Tiempo: Complejidad del Algoritmo Un gran número de las herramientas mostradas en la tabla anterior se ocupan únicamente de obtener las diferencias existentes entre dos versiones de un documento XML; sin embargo, a la hora de realizar la gestión de sus versiones es necesario un sistema que, usando estas 2 La numeración de la columna referencia de la tabla 2.5 se corresponde con las siguientes referencias: 1- [Chawathe 96] 2- [Chawathe 97] 3-[Lindholm 01] 4- [Cobena 02] 5-[VMT 01] 6- [Wang 03c] 7-8- [DeltaXML 01] 9- [Al-Ekram 05]

58 40 Capítulo 2. Estado del Arte herramientas, permita realizar las funcionalidades básicas de un sistema de versionado: añadir una versión al documento, obtener una versión distinta de la actual, etc. En este sentido se han propuesto un número signicativo de sistemas de versionado basados en Delta, entre los que destacamos algunos a continuación. En [Marian 01] se propone un sistema para detectar, gestionar y monitorizar las distintas versiones de un web data warehouse de documentos XML dentro del proyecto Xyleme [Xyleme 01]. Inicialmente los autores analizan qué cambios se pueden producir en un documento XML y denen una taxonomía de cambios que englobe todos los casos. Posteriormente desarrollan su técnica de diferencias basadas en dicha taxonomía [Cobena 02] usando una política de almacenamiento de ultima versión. En [Wuwongse 04] los autores proponen un modelo de datos para la gestión de versiones de documentos XML denominado Temporal-Version Data Model (TVDM) basado en deltas temporales que consiste en integrar en el propio documento las Deltas XML. De este modo a la hora de recuperar la información se comprueba si dicha delta debe aplicarse. En [Chien 01a] los autores utilizan una política de almacenamiento que consiste en guardar la última versión del documento junto con las operaciones anteriores. En [Rönnau 05] los autores utilizan la herramienta XyDi para documentos omáticos XML. Los autores han implementado una librería basada en dicha herramienta para realizar las operaciones básicas sobre documentos XML omáticos: creación de nueva versión, recuperación de una instantánea u obtención de las diferencias entre dos versiones. Finalmente nos gustaría añadir que todas las soluciones anteriores procesan el documento XML en memoria a la hora de realizar el proceso de comparación, hecho que provoca problemas de memoria cuando el documento es de un tamaño considerable ([Leonardi 04, Leonardi 05]). Esta situación ha sido estudiada en [Leonardi 05] donde los autores describen una técnica de diferencias usando una base de datos relacional. Para ello el documento XML es modelado en tablas relacionales y posteriormente en base a consultas SQL se obtienen las diferencias entre dos versiones de un mismo documento. Teniendo en cuenta los distintos aspectos mencionados en este apartado podemos concluir que existe un gran número de herramientas de diferencias XML pero son, relativamente, pocos los sistemas de versionado que se han llegado a implementar. Personalmente creo que esto se debe a que las soluciones DeltaXML no mejoran las soluciones clásicas Delta pues siguen teniendo las desventajas de una elevada carga computacional para recuperar una versión distinta a la actual y la imposibilidad de consultar los documentos de versionado mediante estándares XML. Por este motivo actualmente se siguen usando las soluciones Delta para la gestión de versiones de documentos XML en lugar de utilizar herramientas propiamente diseñadas para tal efecto. Para solventar estos problemas, de carga computacional y consultas históricas, se han propuesto técnicas [Amagasa 00, Zhang 02, Wang 03a, Arévalo Rosado 06] que integran todas las versiones de un documento XML en un único chero, que se mostrarán en el siguiente apartado, y que en muchas situaciones agilizan el proceso de obtención de una versión distinta de la actual y permiten las consultas usando estándares XML como XQuery y XPath. Nos gustaría resaltar que en el sistema de versionado propuesto en esta tesis se utiliza la herramienta jxydi [jxydi 06] para obtener las diferencias de dos documentos XML con el objetivo de obtener un chero log de transacciones de primitivas.

59 Gestión de Cambios en Documentos XML Documentos XML Temporales En las primeras técnicas que aparecieron para la gestión de versiones de documentos XML, se asumió que no era recomendable almacenar todas las versiones en un único documento, principalmente por motivos de capacidad. La solución propuesta al problema fue almacenar la historia de los documentos usando deltas, como se ha mostrado en la sección anterior. Sin embargo, tal y como se describe en [Nørvåg 04], en la actualidad el hecho de almacenar todas las versiones en un único documento no repercute en espacio y tiempo tanto como antiguamente, debido, entre otras cosas, al aumento de la capacidad y velocidad de los dispositivos. De este modo, la solución temporal XML consiste en integrar en un único documento sus distintos estados mediante la incorporación de marcas temporales al documento XML que especican la validez de los componentes XML. En [Grandi 04] se proporciona un análisis bibliográco muy completo sobre un gran número de publicaciones en el campo de las bases de datos temporales y versionado donde también se incluyen documentos XML temporales. En el caso de las bases de datos temporales la validez temporal se establecía a partir de un conjunto de atributos temporales añadidos a nivel de tupla o atributo, de forma que permitían representar los distintos valores que ha tenido cada tupla o atributo. En este caso, el objetivo va a ser el mismo, es decir, añadir información al documento, lo que se denomina meta-marcar el documento, para establecer la validez temporal de cada uno de los elementos XML del documento XML. En este marco se han usado dos técnicas de meta-marcado temporal: Atributos temporales (gura 2.7): la validez se establece añadiendo atributos temporales a cada uno de los elementos XML del documento, tantos como dimensiones se quiera modelar [Amagasa 00, Grandi 00, Manukyan 01, Wang 03a]. Si la validez se establece en base a un instante sólo es necesario añadir un atributo temporal, mientras que para intervalos es necesario añadir un par. La principal virtud de esta solución es la relativa facilidad de su implementación pues en los distintos estándares XML de consulta se incluyen distintos datos temporales (xs:datetime, xs:time,...). La principal desventaja es que no se pueden representar elementos temporales, es decir, cuando la validez se establece mediante un conjunto de intervalos de tiempo disjuntos, pues se tendrían que crear tantos atributos temporales como número de intervalos disjuntos tenga, y este dato se desconoce de antemano. Elementos hijos temporales (gura 2.8): En este caso la validez se establece añadiendo a cada elemento del documento XML tantos elementos hijos temporales, con información temporal, como intervalos válidos tenga dicho elemento [Zhang 02]. Esta solución al no tener la limitación de los atributos permite representar elementos temporales, aunque obviamente su principal inconveniente es la alta complejidad de este modelo. Ejemplo: En las guras 2.7 y 2.8 se muestra un mismo documento XML temporal usando ambas técnicas de marcado. En la primera de ellas, donde se usan atributos temporales, cada uno de los elementos XML tiene dos atributos temporales que denen el intervalo de tiempo en el que dicho elemento es válido mientras que en el segundo, usando elementos hijos temporales, cada elemento se encuentra constituido por un número de elementos hijos, etiquetados como valid, que establecen el conjunto de intervalos en los cuales es válido. Podemos comprobar que en la primera solución la existencia de información válida en intervalos disjuntos provoca la replicación de su información como es el caso del elemento ubicacion con valor Veletas.

60 42 Capítulo 2. Estado del Arte 1 <?xml version='1.0' encoding='utf-8'?> 2 <root> 3 <row> 4 <id_objeto tvstart=' ' tvend=' '>o3567</id_objeto> 5 <ubicacion tvstart=' ' tvend=' '>veletas</ubicacion> 6 <ubicacion tvstart=' ' tvend=' '>conservacion</ubicacion> 7 <ubicacion tvstart=' ' tvend=' '>veletas</ubicacion> 8 </row> 9 <row> 10 <id_objeto tvstart=' ' tvend=' '>o345</id_objeto> 11 <ubicacion tvstart=' ' tvend=' '>regional</ubicacion> 12 </row> 13 </root> Figura 2.7: Marcado Temporal mediante Atributos Temporales 1 <?xml version='1.0' encoding='utf-8'?> 2 <root> 3 <row> 4 <id_objeto> 5 <v:valid tvstart=' ' tvend=' '/> 6 O </id_objeto> 8 <ubicacion> 9 <v:valid tvstart=' ' tvend=' '/> 10 <v:valid tvstart=' ' tvend=' '/> 11 Veletas 12 </ubicacion> 13 <ubicacion> 14 <v:valid tvstart=' ' tvend=' '/> 15 Conservacion 16 </ubicacion> 17 </row> </root> Figura 2.8: Marcado Temporal mediante Elementos Hijos Temporales Modelos: El primer trabajo en abordar la gestión de información temporal en documentos XML fue [Grandi 00] donde los autores propusieron una técnica para representar información temporal en documentos XML. En este caso los autores añadían a cada etiqueta susceptible de cambio dos atributos temporales que indicaban su tiempo válido y a través de una hoja de estilo XSLT formalizaron la operación de recuperación de información válida para un determinado instante o intervalo de tiempo. Sin embargo los autores no abordaron otros tipos de consultas en este trabajo. Continuando con esta idea se han propuesto un gran número de extensiones al modelo de datos XML para agregarle tiempo. En [Amagasa 00] se describe el primer modelo de datos temporal XML, que de manera similar al trabajo anterior usa atributos temporales; sin embargo, el trabajo no describe cómo realizar las actualizaciones ni proporciona un lenguaje de consulta para recuperar la información. En [Zhang 02] se muestra una extensión al modelo de

61 Gestión de Cambios en Documentos XML 43 datos XPath con soporte para tiempo válido donde los autores utilizan elementos hijos temporales para modelar la información cambiante, sin embargo no aportan dato alguno sobre cómo consultar el documento XML temporal. El mismo autor en [Dyreson 01] extiende el modelo XPath con tiempo transaccional usando atributos temporales, centrándose en este caso en su utilización en un servidor web para incorporarle aspectos temporales donde, al igual que en el caso anterior, no se proporciona información alguna sobre cómo consultar los documentos temporales. En [di Vimercati 02] se muestra un modelo de datos para gestionar los accesos a documentos XML temporales, sin embargo los autores profundizan en el mecanismo de autorización en lugar de en los aspectos temporales. Los documentos XML temporales considerados por estos autores se basan en atributos temporales y modelan el tiempo válido, transaccional y el tiempo de publicación. En [Ali 08] se propone un modelo de datos XML temporal que diere ligeramente de los anteriores. Los autores siguen utilizando un meta-marcado a nivel de atributo pero con la particularidad de que en el caso de que los descendientes de un elemento XML temporal tengan el mismo intervalo de tiempo válido, en lugar de replicar esta información, añaden un atributo denominado inherit con valor verdadero indicando este hecho. Sin embargo la gran mayoría de los trabajos expuestos en el párrafo anterior no analizan ni cómo poder consultar el documento XML temporal ni cómo realizar el proceso de actualización, únicamente denen una técnica para representar información histórica en documentos XML. En [Wang 03a, Wang 03b, Wang 04b] los autores proporcionan un uso adicional a los documentos XML temporales, pues además de representar la historia de un documento XML, mantienen la evolución de una base de datos relacional temporal. Los autores en [Wang 02] muestran que una tabla relacional temporal puede ser modelada en un documento XML temporal mediante atributos temporales, lo que además reduce considerablemente la replicación de la información, pues los documentos XML permiten la representación temporal en atributos. Esta situación se ilustra en la gura 2.7 donde se muestra en formato XML temporal la tabla temporal de la gura 2.1 y donde se puede comprobar que no se ha replicado toda la tupla (elemento row) cuando únicamente ha cambiado el valor del atributo ubicacion. Posteriormente los autores en [Wang 03b] analizan las consultas temporales clásicas como proyección, instantáneas, consultas de duración, etc., usando el lenguaje XQuery en base a funciones de usuario y en [Wang 04b] denen un modelo de datos XML bitemporal donde modelan tanto el tiempo válido como el tiempo transaccional e implementan las operaciones para la actualización de un documento con versiones cuando se añade nueva información. Finalmente, otro modelo que ha añadido el tiempo en documentos XML es [Gergatsoulis 03], que almacena en un mismo documento distintas dimensiones o versiones mediante la denición de elementos multidimensionales que son aplicados a elementos y atributos. Éstos se encuentran denidos mediante intervalos de tiempo que representan para qué dimensiones o versiones son válidas; sin embargo, las consultas no son abordadas en este trabajo. Además, algunos de los modelos anteriores se han aplicado a otros documentos de marcado XML como es el caso de [Gutierrez 05] a documentos RDF y [Wang 05] a documentos RFID. En la tabla 2.6 se resumen las principales características de los modelos temporales anteriormente mencionados. Para cada uno de ellos hemos analizado las dimensiones temporales que modelan, la capacidad para representar la historia de los elementos y de los atributos, la posibilidad de realizar consultas temporales y si extienden el modelo de datos XML.

62 44 Capítulo 2. Estado del Arte Tabla 2.6: Modelos de Datos XML Temporales Modelo Dimensiones Temp. Element V T P [Wang 04b] x [Amagasa 00] x x [Grandi 03b] [Zhang 02] x x [Buneman 02] x x [Gergatsoulis 03] x [Ali 08] x x Temp. Attr Consulta Extiende XML XQuery x x - x x XQuery* x x - x x - x - XQuery x V= Tiempo Valido, T= Tiempo Transaccional, P= Tiempo de Publicación *= XQuery Extendido Consultas: Uno de los aspectos más importantes de todo modelo temporal son las consultas que se pueden realizar sobre los datos históricos. En este sentido muchas de las soluciones anteriores no han abordado este hecho y otras tantas únicamente han estudiado la recuperación de la información válida. Sin embargo es recomendable proporcionar al modelo otras consultas basadas en duración, fusión temporal, etc. Algunos de los trabajos que han estudiado este hecho se comentan a continuación. En [Wang 03b] los autores examinan cómo implementar las consultas clásicas temporales (instantánea, joins, históricas, de agregados, etc.) en documentos XML temporales. Para ello proponen consultas basadas en funciones de usuario XQuery usando el modelo planteado en [Wang 04a]. Por ejemplo en la consulta 2.3 se muestra el código XQuery para la recuperación del elemento ubicacion válido para el intervalo [ , ]. Para ello han denido dos funciones de usuario tstart y tend que recuperan la información temporal asociada al elemento que se esta procesando ($s). En [Ali 08] los autores analizan también las consultas históricas usando, al igual que Wang, funciones de usuarios XQuery para su implementación. En [Gao 03] se describe τquery, una extensión a XQuery para documentos XML con tiempo válido. En este caso los autores extienden el modelo de datos XQuery, incorporándoles nuevos constructores los cuales posteriormente son traducidos a XQuery, es decir, las consultas nalmente son evaluadas y ejecutadas por procesadores XQuery. Finalmente en [Nørvåg 02] los autores analizan un conjunto de operadores temporales para ser aplicados en documentos XML temporales. Consulta 2.3 Ejemplo de Consulta Temporal en XQuery 1 for $s in doc('museo.xml')/row/ubicacion 2 where tstart($s)>= ' ' 3 and tend($s) <= ' ' 4 return $s. Gestión: Muchos de los anteriores modelos se han propuesto en el plano teórico, es decir, han establecido únicamente cómo representar información variante en documentos XML, sien-

63 Gestión de Cambios en Documentos XML 45 do muy pocas las implementaciones llevadas a cabo. Podemos resaltar [Wang 08], donde los autores integran el modelo descrito en [Wang 04a] en la base de datos temporal arquis. Para ello han extendido arquis para soportar el almacenamiento de documentos XML históricos. En [Liu 03] los autores implementan el modelo de datos [Zhang 02] mediante una API Java para realizar la gestión de documentos XML. Los autores establecen mediante esta API un conjunto de primitivas básicas para la creación de un documento XML temporal, añadir nueva información y la extracción de la información válida. Las soluciones anteriores no utilizan técnicas de indexación para agilizar la recuperación de la información temporal sino que basan su técnica en estándares XML. Entre los trabajos que abordan la indexación de documentos XML temporales se pueden destacar [Buneman 02, Nørvåg 04, Rizzolo 08]. No profundizamos más en estos trabajos pues al igual que las soluciones anteriores nuestro objetivo será utilizar exclusivamente estándares XML para desarrollar nuestro sistema de versionado ramicado. A partir de todos los datos aportados en esta sección, podemos resumir que las soluciones XML temporales se basan en la idea de integrar todas las versiones de un documento en un único chero XML estableciendo para cada elemento XML cuándo éste es válido. El principal inconveniente de estas soluciones es que carecen de soporte para versionado ramicado debido a la propia naturaleza del tiempo, que es lineal. La solución que se propone en esta tesis también consiste en integrar todas las versiones en un mismo documento pero en lugar de usar marcado temporal (timestamp) representaremos la validez de cada etiqueta a partir de un grafo de derivación previamente almacenado, proporcionando soporte para versionado ramicado Versionado Ramicado en Documentos XML Dentro de este apartado se incluyen aquellas soluciones que permiten la gestión de versiones de documentos XML en un marco ramicado. La idea es representar y almacenar el grafo de derivación de las versiones y posteriormente denir la validez en base a dicho grafo. En la actualidad no existen muchas soluciones basadas en esta técnica para documentos XML, y aquellas que existen, son extensiones de las soluciones de marcado temporal, delta XML o técnicas de indexación. Una de las primeras soluciones para documentos XML es [Wuwongse 04] donde los autores proponen un modelo de datos para la gestión de versiones de documentos XML denominado Temporal-Version Data Model (TVDM) basado en deltas temporales. Adicionalmente los autores almacenan información de la versión de la cual deriva, su versión padre, de modo que se consigue representar el grafo de derivación. Esta solución presenta los siguientes problemas: por una parte, al igual que las soluciones deltas, no permite consultas temporales y, por otra parte, el mecanismo usado para representar el grafo de derivación limita ciertas operaciones de consulta como, por ejemplo, consultar los descendientes de una determina versión, comparar versiones hermanas, etc., pues requiere recorrer todas las deltas del documento vericando si es descendiente de la versión solicitada. En [Park 04] se describe una técnica, basada también en deltas, que almacena, al igual que en el caso anterior, información de la versión de la cual procede el cambio realizado, pudiendo simular de este modo el grafo de derivación. La gestión de versiones de documentos XML en un marco ramicado ha sido abordada con mayor profundidad mediante técnicas de indexación, lo que se denomina Multiversion XML [Jiang 00, Chien 01b, Rizzolo 08]. En [Jiang 00] los autores presentan una técnica para la inde-

64 46 Capítulo 2. Estado del Arte xación de documentos no XML denominada BT-Tree para la gestión ramicada de versiones. En primer lugar, se representa mediante un árbol el grafo de derivación y, posteriormente, se dene una técnica de paginación basada en este grafo. De forma similar en [Vagena 04] se dene un técnica de indexación denominada BT-ElementList para la gestión de versiones de documentos XML. Obviamente el uso de técnicas de indexación garantiza un mejor rendimiento a la hora de realizar la gestión de versiones pero no permite el uso de lenguajes estándares de consultas XML como XQuery y XPath para la recuperación de su información. La solución planteada en esta tesis, aunque probablemente tenga un peor comportamiento, no requiere extender el modelo de datos XML y su implementación se ha realizado siguiendo exclusivamente estándares XML Versionado de Esquemas Los documentos XML pueden tener asociado un documento esquema que describe la estructura y restricciones de los documentos XML basados en dicho esquema. Este tipo de documento, como cualquier otro, evoluciona, por lo que es necesario no solamente gestionar sus propias versiones sino también adaptar las instancias de los documentos al nuevo esquema, tal y como sucedía en el versionado de las bases de datos. En este apartado se resumirán brevemente las soluciones propuestas para el versionado de esquemas, pues como se mencionó con anterioridad este trabajo está enfocado exclusivamente a gestionar los cambios en los datos y estructuras de un documento XML. El primer trabajo en abordar este problema fue [Su 01] para los documentos DTD, donde se denieron y analizaron un conjunto de operaciones de cambio sobre estos documentos. De este modo, cuando se realizaba una de las primitivas denidas, se producía la ejecución de un conjunto de funciones que adaptaban las instancias según el cambio realizado. Sin embargo, tal y como se expone en [Lee 00], la simplicidad de tipos y estructuras de estos esquemas recomienda el uso de otros documentos de denición de esquemas. La evolución de DTD también ha sido abordada en [Bertino 02], donde los autores utilizan mecanismos de datamining para deducir los cambios que se tienen que realizar en los DTD a partir del análisis de los cambios que se han producido en los documentos. Los primeros trabajos sobre la evolución de documentos XML-Schema son [Guerrini 05]. En [Tan 04] los autores proporcionan una clasicación de los posibles cambios, pero sin llevarla a cabo en este trabajo. En [Tan 04, Guerrini 05, Guerrini 07] se dene un conjunto de primitivas de cambios para esta clase de documentos, así como las funciones de adaptación que se encargan de adecuar las instancias a partir de los cambios realizados. Obviamente los autores no abordan todas las posibles operaciones de cambios sino aquellas que garanticen que las instancias seguirán siendo consistentes con respecto al nuevo esquema. En [Guerrini 07] los mismos autores abordan uno de los principales problemas de este campo, que es la validación de las nuevas instancias con respecto al nuevo esquema antes de proceder a los cambios, lo que denominan validación incremental. De este modo, en primer lugar se verica la idoneidad de la actualización mediante precondiciones y solamente si es correcta se procede a su ejecución. En [Dyreson 06] los autores proponen un modelo de datos y una arquitectura, denominada τ XSchema, para la creación de esquemas temporales, mediante anotaciones que indican qué parte de las instancias son susceptibles de cambio a lo largo del tiempo. De este modo, permiten representar versiones de XML-Schema junto con versiones de las instancias. Sin embargo los autores no plantean ninguna solución para la adaptación de las instancias,

65 Conclusiones 47 solamente enfocan el trabajo a como representar las versiones. Esta temática está actualmente en un profundo proceso de investigación como así lo reeja el gran número de publicaciones que se han presentado recientemente [Moro 07, Atay 07, Brahmia 08, Simanovsky 08]. Nos gustaría resaltar el trabajo [Guerrini 09] donde los autores ponen de maniesto la necesidad de gestionar versiones de esquemas, muestran las principales soluciones hasta el momento y analizan las futuras tendencias en este campo de la investigación Conclusiones En este capítulo se ha presentado el conjunto de conceptos, ideas, trabajos e implementaciones relacionadas con el tratamiento de versiones en distintas fuentes de información. Aunque no se puede generalizar por el gran número de soluciones existentes que hemos analizado, en la tabla 2.7 se muestra un resumen por cada una de las fuentes de información estudiadas. Tabla 2.7: Soluciones actuales para la Gestión de Versiones Tipo Doc. Clásicas Textual / Binaria BD Temporales Delta XML XML Temporal Versionado XML. Índices Propuesta de esta tesis BDR / BDOO XML XML XML XML Granularidad Control Gestión Consultas Históricas Documento o Ramicado Histórico Dicultad línea / byte de Op. Tupla / Atributo u Objeto Componente XML Componente XML Componente XML Componente XML Lineal Ramicado Lineal Ramicado Ramicado Histórico de Datos Histórico de Op. Histórico de Datos Histórico de Datos Histórico de Datos Si Dicultad Si Si Si Inconveniente No tiene en cuenta la estructura XML Linealidad No permite consultas con estándares XML Linealidad No permite consultas con estándares XML En esta tabla, por una parte, se presentan algunos de los factores que expusimos al principio de este capítulo que pueden condicionar el sistema de versionado resultante: granularidad del objeto versionable, tipo de control y gestión de control. Por otra parte, esta tabla recoge si permiten consultas históricas y el principal inconveniente detectado. A partir de este resumen somos capaces de determinar si estas soluciones cumplen con las 4 características que expusimos en el capítulo anterior que debe tener un sistema de versionado: 1) ser capaz de detectar y representar cambios 2) ofrecer la posibilidad de recuperar cualquier versión 3) soporte para versionado ramicado y 4) facilidad para la realización de consultas, en nuestro caso basadas en lenguajes XML. Como puede observarse, no existe ninguna solución

66 48 Capítulo 2. Estado del Arte que se pueda aplicar a los documentos XML que cumpla con las 4 especicaciones. Centrándonos exclusivamente en documentos XML podemos resumir que, básicamente, existen las siguientes soluciones: Delta XML, que consiste en obtener y almacenar las diferencias XML entre dos versiones dadas. La recuperación de una versión consiste en aplicar los cambios realizados a la versión actual. Como principal desventaja podemos destacar el alto coste computacional de recuperar una versión distinta de la actual y que no permite consultas sobre la evolución del documento mediante XQuery o XPath Marcado temporal, que consiste en meta-marcar temporalmente (timestamp) cada etiqueta del documento, indicando en qué periodos de tiempo dicha etiqueta es válida. Esta solución integra todas las versiones del documento en un mismo chero, lo que facilita las consultas mediante lenguajes XML. Sin embargo esta propuesta, debido a la naturaleza lineal del tiempo, carece de soporte para versionado ramicado. La solución que proponemos en esta tesis está basada en el concepto de integración de todas las versiones en un único chero y en denir la validez de las etiquetas que forman parte del documento. Sin embargo en nuestro caso almacenaremos adicionalmente el grafo de derivación y deniremos la validez a partir de dicho grafo. De este modo, además de permitir consultas sobre la evolución del documento usando lenguajes XML, también se podrá realizar la gestión de versiones en un entorno ramicado.

67 Módulo II Modelo de Versionado de Documentos XML: vdocxml

68

69 Capítulo 3 Modelo de Documentos Versionados vdoc Contenidos 3.1. Modelo de Datos de Documentos Versionados vdoc Operaciones Básicas sobre Documentos Versionados vdoc Creación de un Documento Versionado vdoc Inserción de una Versión como Derivada de Otra Borrado de una Versión sin Versiones Hijas Revisión de las Operaciones sobre Documentos de Versionado Creación de un Documento Versionado vdoc Obtención del Documento Asociado a una Versión Inserción de Versiones Cambio del Padre de una Versión Borrado de Versiones Extensión de Operaciones sobre Documentos de Versionado Sustitución de Versiones Poda de Versiones Fusión de Versiones Operaciones Primitivas Operaciones Primitivas Operaciones Adicionales para la Gestión de Documentos Versionados Conclusiones En este capítulo se introduce el concepto de documento versionado y el conjunto de operaciones que podemos denir sobre él; ambos constituyen el modelo de documento versionado que hemos denominado vdoc. En la sección 3.1 se introduce la noción de documento versionado. El objetivo del documento versionado es disponer de un conjunto de sus estados o versiones, indicando alguna relación entre las mismas. Normalmente esta relación suele estar basada en el concepto de derivación, de forma que podamos indicar el conjunto de nuevas versiones del documento que

70 52 Capítulo 3. Modelo de Documentos Versionados vdoc se han obtenido a partir de una versión dada. Esta interpretación añade una serie de presupuestos que deberemos tener en cuenta a la hora de añadir o eliminar nuevas versiones al documento versionado. Por ejemplo: a) supondremos que no pueden existir versiones que no se deriven de otra dada, y b) cada versión procede de una y sólo una versión anterior. La primera consideración conduce a la necesidad de partir de una versión inicial del documento, que en nuestro caso será el documento vacío, es decir un documento en el que suponemos que aún no se ha escrito nada. La segunda condición implica que cada versión procede de una sola versión anterior, que denominaremos su versión padre. Esta relación se puede expresar de forma natural mediante un árbol cuya raíz sea el documento vacío. En la sección 3.2 se inicia el estudio de las operaciones que se pueden denir sobre un documento versionado. Para abordar de forma incremental el problema, inicialmente se consideran sólo operaciones básicas sobre el conjunto de documentos que constituyen las versiones del documento versionado. Estas operaciones consistirán en crear el conjunto de documentos de versiones con la versión inicial (el documento vacío), y las operaciones de añadir o eliminar un documento a dicho conjunto. Para ello se analizan las situaciones más simples impuestas por el grafo de derivación de versiones, por lo que consideramos solamente versiones que se deriven directamente a partir de una dada. Por tanto se estudian las operaciones que permitan añadir una versión derivada directamente a partir de otra existente o borrar una versión que no tenga ninguna otra versión que se derive de ella. En la sección 3.3 se revisan en profundidad cada una de las operaciones anteriores, prestando especial atención a la perspectiva de las mismas desde la ubicación de las versiones en el grafo de versiones. Ya no se trata simplemente de añadir o borrar un elemento de un conjunto, sino de considerar dichas operaciones para un nodo del grafo. Se denen con mayor precisión, y se extienden en algunos casos, las operaciones de creación de un documento versionado, y las de inserción y borrado de nuevas versiones. Además, se añaden dos operaciones nuevas como es obtener el documento asociado a una versión y el cambio del padre de una versión. En la sección 3.4 se dene un conjunto de operaciones avanzadas que ayudarán a manejar los documentos versionados. En primer lugar se presenta la sustitución de versiones, que permite la edición de una versión manteniendo su relación con todas las existentes. A continuación se denen las operaciones de poda o borrado masivo a partir de un nodo y, nalmente, se tratan las operaciones de fusión de versiones, tan habituales para la simplicación y mantenimiento de versiones en procesos de diseño. En la sección 3.5 se destaca el conjunto de operaciones básicas denidas a lo largo de las anteriores secciones que permiten denir el documento versionado vdoc. Además se demuestra que el resto de primitivas (sección 4) se pueden formular en base a estas primitivas básicas. De este modo, estas primitivas básicas constituyen un álgebra sobre las versiones de documentos de versionado vdoc. A lo largo del tema se ilustran las deniciones con ejemplos y se intenta dotar de las interpretaciones necesarias sucientes para aplicar este modelo al caso de documentos versionados XML (Extensible Markup Language [XML]) como se hará en el próximo capítulo Modelo de Datos de Documentos Versionados vdoc La representación del mundo real mediante datos ha estado basada, durante mucho tiempo, en la representación del estado de los objetos bajo un modelo (un esquema) y un estado concreto (el valor para ese objeto en ese esquema), como si fuera una fotografía. Normalmente,

71 Modelo de Datos de Documentos Versionados vdoc 53 este valor suele referirse al estado actual del objeto, de modo que cualquier modicación en el mismo se resuelve sobrescribiendo sus datos, perdiéndose los valores (estados) anteriores. Las consultas en esta representación están dirigidas a los estados actuales de los objetos que se almacenen en el sistema. Las bases de datos temporales han intentado resolver este problema, almacenando todos los estados anteriores y asociando a cada uno de ellos una referencia temporal. De esta forma se guarda una secuencia de valores que permite analizar la evolución del objeto a lo largo del tiempo. Las bases temporales suelen partir de la premisa de que el estado de cada objeto en un momento de tiempo es único. Sin embargo, como vimos en el capítulo 2, en el caso de un sistema ramicado un mismo objeto no tiene por qué tener asociado un único estado en un instante de tiempo, sino que puede tener diferentes estados válidos simultáneamente. De este modo, una versión se puede denir como: Denición 3.1. (Versión) Una versión es un estado semánticamente correcto de un objeto de acuerdo a un esquema. Además en estos sistemas no sólo nos interesa el conjunto de versiones de un objeto sino también dotar de una relación entre las versiones que aporte una semántica adicional y facilite su gestión. Normalmente se tiene una única relación R denominada relación de versionado. La relación de versionado es un mapa de referencia en el que podemos buscar y comparar versiones entre sí de acuerdo a dicha relación. En la mayoría de los casos se trata de una relación de orden parcial inducida por algún atributo, por lo que suele tener asociada la semántica inherente a dicho atributo. En otras ocasiones se trata de una relación de derivación, de forma que v i R v j si y sólo si la versión v i se ha derivado a partir de la versión v j y representadas de este modo mediante un árbol denominado árbol de versionado. Por ello solemos referirnos a la información más relevante de cada versión respecto de la relación de versionado como su historia. Denición 3.2. (Historia de una versión) Denominaremos historia de la versión vj a la información asociada a dicha versión y extraída a partir de la relación de versionado de vj con el resto de versiones. Si la relación de versionado indica la relación de derivación de versiones, la historia suele ser el camino desde la versión actual hasta el nodo raíz del árbol de versionado. En este trabajo propondremos un modelo para la gestión de versiones donde el objeto de estudio serán documentos, concretamente, documentos XML y donde se usará como relación de versionado la relación de derivación entre las distintas versiones. A la vista de todo lo anterior, podemos denir un documento versionado vdoc como un objeto que representa diferentes estados o versiones de un único documento, y para el que la relación entre las diferentes versiones se muestra mediante un grafo de tipo árbol. Cada versión, representada por un nodo en el grafo, está asociada a un documento concreto y su nodo padre es la versión a partir de la cual se ha obtenido. Suponemos que el estado inicial siempre corresponde al documento vacío que se tiene para cualquier documento al crearlo. Por ello denimos un documento versionado vdoc de la siguiente forma: Denición 3.3. (vdoc) Un documento versionado vdoc es una terna vdoc=(g, D, ρ) donde G=(V, E, v 0 ) es un árbol dirigido con un conjunto de vértices V, un conjunto de arcos E y con raíz v 0, D={d i } es una colección nita de documentos, denominados versiones del documento

72 54 Capítulo 3. Modelo de Documentos Versionados vdoc versionado vdoc, y ρ : v i V ρ(v i ) = d i D es una función biyectiva que permite identicar los vértices v i V del grafo G y los documentos d i D. Además G siempre tiene al menos el elemento raíz v 0 que siempre se identica con el documento vacío d 0 = ρ(v 0 ) D. Por tanto, cualquier documento versionado vdoc contiene al menos el documento vacío d 0 como versión inicial. Ejemplo: Un ejemplo de documento versionado aparece en la gura 3.1. Figura 3.1: Documento versionado vdoc=(g, D, ρ) Notación y observaciones a partir de la denición 1. Sobre el grafo G=(D, E, d 0 ). Por denición, un árbol G=(V, E, v 0 ) es un grafo dirigido conexo sin ciclos, en el que todos los nodos tienen uno y sólo un padre, excepto el nodo raíz v 0 que no tiene ningún nodo padre. Se usarán las siguientes notaciones: V es el conjunto nito de vértices en el grafo, E={e i, j =( v i, v j )/ v i, v j D } es un conjunto nito de arcos dirigidos entre los nodos en V y v 0 D es la raíz del grafo. Dado el arco e i, j = (v i, v j ) E diremos que la versión v i V es una versión de la que se deriva v j V, o que también la versión v j V se deriva de la versión v i V, y la misma terminología se aplicará de forma análoga a los documentos asociados ρ(v i ) = d i D. Por tanto, y aunque se puede dotar de cualquier otra semántica a la relación entre los documentos inducida por el árbol G, nosotros supondremos que un arco e i, j =( v i, v j ) denota que el documento d j = ρ(v j ) D es una versión de vdoc que se ha obtenido a partir de la versión d i = ρ(v i ) D. Además, usaremos las notaciones habituales sobre grafos dirigidos: parent(v j ) = {v i V/ e i, j = (v i, v j ) E}, child(v j ) = {v i V/ e j, i = (v j, v i ) E}, y los siguientes conjuntos de nodos constituyen una partición del grafo a partir del nodo v j : {ancestor(v j ), descendant(v j ), preceding(v j ), following(v j ), self(v j )}, y otros conjuntos habituales como preceding-siblings(v j ), following-siblings(v j ), etc. Diremos que un vértice v i D del grafo es hoja si card.(child(v i )) = 0, con lo que podemos denir la función booleana Is_Leaf(v i ) que nos indica si un nodo es hoja o no en el grafo G. De las deniciones son inmediatas las siguientes proposiciones: i) e i, j = (v i, v j ) E, v i v j.

73 Operaciones Básicas sobre Documentos Versionados vdoc 55 ii) v i V {v 0 }, card.(parent(v i )) = Sobre la biyección ρ. La biyección ρ permite identicar los documentos y los nodos del grafo, de forma que a menudo consideraremos G=(V, E, v 0 ) como G=(D, E, d 0 ). Además, de ello se deduce que el número de documentos (o versiones) de vdoc es siempre un número nito igual al número de nodos del grafo. En general, dado ρ(v i ) = d i D usaremos indistintamente v i para referirnos a la versión asociada al documento d i y d i para referirnos al documento asociado a la versión v i. 3. Sobre el contenido de los documentos d i D. Nótese que la biyección ρ establece que no puede haber un documento asociado a dos estados, es decir, los documentos d i D son independientes de su contenido. ¾Qué ocurre si para dos versiones se tiene que los documentos asociados a estas dos versiones son idénticos? Pues simplemente eso, que el contenido de ambos documentos es idéntico, pero aparecen duplicados, con sus identicadores diferentes y no se consideran como un mismo documento. Por tanto, si denominamos c(d i ) al contenido del documento d i se tiene que dos documentos diferentes d i d j puede ser que tengan el mismo contenido c(d i ) = c(d j ), pero dentro del conjunto D se consideran como dos elementos diferentes. Denotaremos c(d 0 ) = Ø. Como se comentará al nal esto introduce el problema de reutilizar las partes comunes a varias versiones redeniendo el modelo a un versionado de granularidad más na sobre elementos del documento. 4. Sobre el nombre de los documentos d i D y versiones v i V. Se pueden extender fácilmente las operaciones en las que se usan documentos para incluir también una etiqueta que sea el nombre del documento o el identicador de la versión que se vaya a crear, por simplicidad se utilizarán los subíndices para distinguir objetos del mismo tipo, bien sean versiones v i V o documentos d i D. 5. Sobre las versiones hijas de una dada. ¾Cómo se van a considerar las versiones derivadas a partir de una dada? Nótese que, por la denición del grafo dirigido G, el conjunto de versiones derivadas a partir de una dada es un conjunto ordenado. Esta ordenación se debe considerar para acceder a las versiones hijas de una versión dada y también para indicar el punto de inserción de una versión. Sin embargo, no suele servirnos de demasiada ayuda ya que el criterio de lugar de inserción no suele tener asociada una semántica denida. La forma más habitual de distinguir las versiones derivadas a partir de una dada suele basarse en el uso de atributos adicionales sobre las versiones para seleccionarlas u ordenarlas, como pueden ser los atributos temporales Operaciones Básicas sobre Documentos Versionados vdoc El conjunto de versiones de un documento versionado vdoc=(g, D,ρ) se encuentra materializado en el conjunto de documentos D. Por ello podemos pensar que las operaciones básicas sobre un documento versionado vdoc son las que permiten la creación del conjunto inicial D = {d 0 }, y las operaciones de inserción y borrado de documentos en dicho conjunto D. Sin embargo, cada documento d i D está siempre asociado mediante la función ρ a una versión o nodo en el grafo de versiones G=(D, E, d 0 ), por lo que cualquier modicación en D lleva asociada las correspondientes operaciones sobre el grafo G. De hecho, para considerar la inserción de un documento que se trate como una nueva versión de vdoc debe indicarse una

74 56 Capítulo 3. Modelo de Documentos Versionados vdoc versión ya existente en vdoc a partir de la cual se deriva esta nueva versión. Del mismo modo, al borrar un documento d i en D, también deberá eliminarse del grafo G su nodo asociado ρ 1 (d i ) = v i. Todas estas operaciones deben producir siempre un estado de vdoc consistente con la denición de documento versionado. De este modo, las operaciones que se puedan denir sobre el conjunto D de documentos van a estar condicionadas por las relaciones entre sus versiones asociadas según se indica en el grafo G. Por ello, en esta sección abordaremos las operaciones de inserción y borrado de documentos en D cuyos nodos asociados en G presenten situaciones aparentemente sencillas de tratar, como son los casos en los cuales los nodos que se insertan o borran en G son nodos hojas. Las situaciones más generales en que se deseen insertar o borrar los documentos para versiones cuyos nodos no sean hojas se discuten en la siguiente sección. Notación de las operaciones Para denir las operaciones se dará su sintaxis, descripción, precondiciones y postcondiciones de la operación, donde: Sintaxis: Nombre_Operación(vDoc, param i,..., param n ). Normalmente con esta descripción funcional se dene una operación que se aplicará sobre un documento versionado (vdoc=(g, D, ρ)), y los parámetros (param i,..., param n ) suelen ser versiones (apuntadores v i a nodos del grafo G) o documentos d i que vayan a añadirse al conjunto de documentos D. Nótese que para referirnos a un documento ya existente en el documento versionado vdoc usaremos su versión asociada v i y accederemos a dicho documento mediante ρ(v i ) = d i. Descripción: Dene el algoritmo o comportamiento de la operación. Precondiciones: Denen restricciones sobre el estado del documento versionado de entrada o sobre los parámetros que intervienen en la llamada a la función. Si se incumple alguna de estas restricciones la función devolverá un estado de error y no realizará ninguna operación sobre el documento versionado vdoc. PostCondiciones: Normalmente se denen indicando el resultado de la función, que será un nuevo estado del documento versionado vdoc'=(g', D',ρ ), o bien un código de error indicando algún problema que haya impedido la correcta realización de la operación Creación de un Documento Versionado vdoc Denición 3.4. Create(vDoc). La operación de creación de un documento versionado vdoc=(g, D, ρ) devuelve un objeto vdoc con sólo el documento vacío que será siempre la versión inicial de cualquier documento. Precondiciones: Ø Postcondiciones: Se crea el objeto vdoc=(g, D, ρ), donde: G = ({v 0 }, Ø, v 0 ), D = {d 0 } y ρ : v 0 ρ(v 0 ) = d 0. Ejemplo: En la gura 3.2 se muestra la estructura de un documento versionado vdoc=(g, D, ρ) después de aplicar la operación Create(vDoc).

75 Operaciones Básicas sobre Documentos Versionados vdoc 57 Figura 3.2: Creación de un documento versionado vdoc Inserción de una Versión como Derivada de Otra Como se ha comentado al denir el documento versionado, se puede indicar el lugar de inserción de una versión, pues el conjunto de hijos de un nodo en un grafo es un conjunto. No especicaremos esta característica en la operación, aunque podría tenerse en cuenta y supondremos que la versión se añade al nal de la lista de versiones hijas de la versión de la que derive. Otra opción es asociar un atributo adicional a cada versión, de forma que cada nodo tenga uno o varios atributos adicionales que informen de características especícas de la versión, como por ejemplo el tiempo de transacción asociado al momento de creación de la versión. Denición 3.5. Insert(vDoc, v i, d j ). Añade una nueva versión al documento versionado vdoc=(g, D, ρ), cuyo documento asociado es d j y que se ha derivado a partir de la versión v i. Precondiciones: (d j / D) (v i V ). Postcondiciones: Se obtiene el nuevo estado vdoc'=(g', D',ρ ) del documento versionado vdoc=(g, D,ρ), donde: G = (V {v j }, E {(v i, v j )}, v 0 ), D = D {d j } y ρ [ρ (v j ρ(v j ) = d j )]. Observaciones: 1. Nótese que no es necesario que la versión v i sea una hoja, es decir, esta operación puede aplicarse para que la nueva versión derive de cualquier otra versión existente en el grafo G. 2. La condición (d j / D) se reere a que no existe ningún subíndice j ya utilizado al describir los elementos de D. Como ya se ha comentado al denir la función ρ, puede que el contenido de d j sea el mismo que el de otro documento d i D, pero se considerarán elementos distintos si i j. Ejemplo: En la gura 3.3 se muestra la estructura de un documento versionado vdoc=(g, D, ρ) después de ejecutar la operación Insert(vDoc, v 3, d 7 ) que añade el documento d 7 como una nueva versión de vdoc que se ha derivado a partir del documento d 3 = ρ(v 3 ) D asociado a la versión v 3.

76 58 Capítulo 3. Modelo de Documentos Versionados vdoc Figura 3.3: Inserción de una versión como derivada de otra Borrado de una Versión sin Versiones Hijas Denición 3.6. Delete-leaf(vDoc, v i ). Dada una versión hoja v i V, es decir una versión de la cual no se ha derivado aún ninguna otra, se eliminará dicha versión v i del documento versionado vdoc=(g, D, ρ), borrando el documento asociado d i D. Precondiciones: (v i V ) (Is_Leaf(v i )). Postcondiciones: Se obtiene el nuevo estado vdoc'=(g', D', ρ ) del documento versionado vdoc=(g, D, ρ), donde: G = (V {v i }, E {(parent(v i ), v i )}, v 0 ), D = D {d i } y ρ ρ /v i. Observaciones: La expresión ρ ρ /v i se utilizará para indicar la función ρ eliminando del conjunto inicial los elementos indicados en la parte inferior, en nuestro caso eliminando v i. Ejemplo: En la gura 3.4 se muestra la estructura de un documento versionado vdoc=(g, D, ρ) después de ejecutar la operación Delete-leaf(vDoc, v 4 ) que borra la versión v 4 y su documento asociado d 4 del documento versionado vdoc Revisión de las Operaciones sobre Documentos de Versionado En esta sección se generalizan las operaciones básicas que debemos denir sobre los documentos de versionado vdoc para gestionar sus versiones. En primer lugar se generalizará la creación de un documento versionado para poder partir de una versión inicial diferente del documento vacío o incluso partir de un conjunto de documentos que sirvan de diferentes versiones a partir del documento vacío. Luego se considerará una función para obtener el documento asociado a una versión en el grafo de versiones, y, a continuación se abordarán las operaciones de inserción y borrado aplicadas a situaciones generales. Empezaremos analizando nuevas formas de inserción en el grafo diferentes de la

77 Revisión de las Operaciones sobre Documentos de Versionado 59 Figura 3.4: Borrado de una versión sin versiones hijas inserción de nodos hojas; para ello, consideraremos la posibilidad de insertar un nodo entre dos nodos conectados por un arco, lo que denominaremos inserción de una versión entre dos versiones derivadas. Al estudiar este problema, observaremos que su solución se reduce a cambiar el padre de un nodo por otro nodo del grafo, lo que denominaremos como modicación del padre de una versión Update_Parent. A continuación se estudia la generalización del borrado, obteniéndose una solución que puede expresarse en función de Update_Parent y el borrado de un nodo hoja. Como ya se ha comentado, estas operaciones denidas sobre el modelo de datos deben cumplir una serie de restricciones especicadas mediante precondiciones/postcondiciones que aseguren que el grafo sigue vericando la denición de documento de versionado vdoc. Por tanto, las operaciones sobre el conjunto D de versiones están condicionadas por las relaciones entre las versiones que representa el grafo G Creación de un Documento Versionado vdoc Creación de un Documento Versionado vdoc a partir de un Documento Habitualmente se crea un documento versionado a partir de un documento existente, por ello podemos extender la función de creación de documento versionado para que se realice a partir de un documento. Como podemos apreciar en la denición, se trata simplemente de una combinación de la operación de creación de un documento versionado con el documento vacío y la inserción del documento inicial como derivado de dicho documento vacío. Denición 3.7. Create(vDoc, d i ). Se crea un documento versionado vdoc=(g, D, ρ) que tiene además a v i = ρ(d i ) como versión derivada del documento vacío v 0. Precondiciones: Ø Postcondiciones: Create(vDoc, d i ) = Create(vDoc) + Insert(vDoc,V 0, d i ) Ejemplo: En la gura 3.5 se muestra la estructura de un documento versionado vdoc=(g, D, ρ) después de ejecutar la operación Create(vDoc, d 1 ).

78 60 Capítulo 3. Modelo de Documentos Versionados vdoc Figura 3.5: Creación de un documento versionado vdoc a partir de un documento Creación de un Documento Versionado vdoc a partir de un Conjunto de Documentos Denición 3.8. Create(vDoc, {d i } i I ). La operación de creación de un documento versionado se puede generalizar posibilitando que se utilice un conjunto nito de documentos {d i } i I como documentos que se han derivado directamente a partir del documento vacío de la siguiente forma: Create(vDoc, {d i } i I ) = Create(vDoc) + {Insert(vDoc, v 0, d i )} Observaciones: 1. La anterior será la denición general que tomaremos para la función de creación de un documento versionado. Nótese que si no se tiene ningún documento será {d i } i I = Ø y entonces Create(vDoc, {d i } i I ) = Create(vDoc); y si se tiene un único documento d a será {d i } i I = {d a } y entonces Create(vDoc, {d i } i I ) = Create(vDoc, {d a }) = Create(vDoc, d a ). 2. Usaremos frecuentemente expresiones como la anterior para combinar operaciones; en ella se usará el signo + para indicar una secuencia de operaciones en la cual se debe ejecutar la operación que aparece en primer lugar y después la que aparece a continuación del operador +; mientras que la unión ( ) indica que las operaciones se pueden aplicar en cualquier orden. Ejemplo: En la gura 3.6 se muestra la estructura de un documento versionado vdoc=(g, D, ρ) después de ser creado mediante la operación Create(vDoc, {d i } 1 i n ) Obtención del Documento Asociado a una Versión Como ya se ha indicado en el apartado Notación de operaciones en la Sección 2. Operaciones básicas sobre documentos versionados vdoc, para referirnos a un documento ya existente en el documento versionado vdoc usaremos su versión asociada v i y accederemos a dicho documento mediante ρ(v i ) = d i. Por tanto, basta realizar un recorrido por el grafo y denir i I

79 Revisión de las Operaciones sobre Documentos de Versionado 61 Figura 3.6: Creación de un documento versionado vdoc a partir de un conjunto de documentos Figura 3.7: Obtención del documento asociado a una versión para cada nodo v i V la función GetDoc(v i ) que permite obtener el documento asociado a la versión v i del documento versionado vdoc. Nótese que esta operación nos permite realizar las operaciones de navegación sobre los documentos a partir de las diferentes operaciones de navegación sobre el árbol de versiones. Denición 3.9. GetDoc(vDoc, v i ). Dada una versión v i V de un documento versionado vdoc=(g, D, ρ), la función GetDoc(vDoc, v i ) devuelve el documento asociado a la versión v i V. Precondiciones: (v i V ). Postcondiciones: Se obtiene el documento ρ(v i ) = d i D. Ejemplo: En la gura 3.7 se indica el documento d 4 que devuelve la operación GetDoc(vDoc, v 4 ) para el documento versionado vdoc=(g, D, ρ) donde ρ(v 4 ) = d 4 D.

80 62 Capítulo 3. Modelo de Documentos Versionados vdoc Inserción de Versiones Si intentamos imaginar las operaciones de inserción que podemos realizar en el árbol dirigido G=(V, E, v 0 ) es fácil deducir que no se puede añadir un nuevo nodo simplemente al grafo (se perdería la conectividad del grafo) o un nuevo arco sobre los nodos existentes (habría un nodo con dos padres). Esto signica que nunca se puede añadir un arco a un árbol sin añadir un nuevo nodo y también, que no se puede añadir un nodo sin añadir un arco. Supongamos que añadimos un nodo y un arco, según lo anterior el nodo a insertar v new / V debe ser origen o destino de dicho arco y el otro extremo del arco debe ser un nodo del grafo distinto del nodo a insertar (pues de lo contrario se tendría un ciclo), que denotaremos como v i V {v new }, por lo tanto se tendrá uno de los dos arcos siguientes (v new, v i ) ó (v i, v new ). Estudiemos estas dos posibilidades: a) (v i, v new ). Si el arco tiene como destino el nuevo nodo se tratará de una inserción del nuevo nodo como una hoja y su padre es el nodo origen del arco añadido, esta es la operación de inserción estudiada en la sección anterior. b) (v new, v i ). Si el arco tiene como origen el nuevo nodo entonces el nodo destino de dicho arco, v i, tendrá dos padres y el nodo v new aparece no conectado al árbol pues no tiene padre aún. Por tanto, deberemos borrar el arco que llega a v i desde su padre en el grafo inicial y además se deberá añadir un arco que conecte cualquier nodo del grafo con el nuevo destino para conservar la conectividad del árbol. La única solución posible es modicar el arco (parent(v i ), v i ) por (parent(v i ), v new ) y de esa forma queda conectado al árbol el nuevo nodo, v new, que pasa a ser el único padre del nodo v i. Esto nos lleva a considerar la operación de inserción de una nueva versión entre dos versiones existentes en el grafo, por lo que podemos denir la siguiente operación que amplía la operación de inserción de un documento como derivado de una versión existente. Ahora podemos insertar la nueva versión, no sólo como descendiente de una dada, sino entre ella y otra de sus versiones hijas. Para ello podemos considerar la sintaxis Insert_2(vDoc, (v i, v j ), d k ), donde v i = parent(v j ). Sin embargo, ¾es necesario dar el arco completo para especicar el lugar en el que se quiere insertar la nueva versión? Si sólo se diera v i, también se debería indicarse sobre cuál de sus hijos se va insertar una derivación intermedia, sin embargo, bastaría dar sólo v j y considerar que la inserción de d k se va a llevar a cabo entre dicho nodo y su padre. Nótese que esto queda unívocamente determinado por ser único el nodo padre de cada nodo en G. Por ello vamos a considerar la siguiente operación, que permite insertar una nueva versión asociada a un documento d k entre la versión v i y su padre parent(v i ), que denimos de la siguiente forma: Inserción de una Versión entre dos Existentes Denición Insert-up(vDoc, v i, d j ). Añade una nueva versión al documento versionado vdoc=(g, D, ρ), cuyo documento asociado es d j y que se ha derivado a partir del padre de la versión v i y que posteriormente se ha derivado en la versión v i. Precondiciones: (d j / D) (v i V {v 0 }). Postcondiciones: Se obtiene el nuevo estado vdoc'=(g', D', ρ ) del documento versionado vdoc=(g, D, ρ), donde: G = (V {v j }, E {(parent(v i ), v j ), (v j, v i )} {(parent(v i ), v i )}, v 0 ), D = D {d j } y ρ [ρ (v j ρ(v j ) = d j )]. Observaciones:

81 Revisión de las Operaciones sobre Documentos de Versionado 63 Figura 3.8: Inserción de una versión entre dos existentes 1. Nótese que v i no puede ser el nodo inicial del grafo V. Ejemplo: En la gura 3.8 se muestra la estructura de un documento versionado vdoc=(g, D, ρ) después de ejecutar la operación Insert-up(vDoc, v 9, d 7 ) que añade el documento d 7 como una nueva versión de vdoc que se ha derivado a partir del documento d 3 = ρ(v 3 ) D asociado a la versión v 3 = parent(v 9 ) y dicho documento d 7 se ha derivado posteriormente en v Cambio del Padre de una Versión Nótese que en la operación Insert-up(vDoc, v i, d new ) se ha propuesto como solución modicar el arco (parent(v i ), v i ) por (parent(v i ), v new ) y cuando se añada el arco de v new a v i queda conectado al árbol el nuevo nodo, v new, que pasa a ser el único padre del nodo v i. Esta solución considera una visión del problema desde el punto de vista del nodo padre, pero si lo vemos desde el punto de vista del nodo hijo v i, lo que hemos hecho es cambiar su padre de parent(v i ) a v new. Si pensamos sobre este hecho, podemos observar que este cambio es posible realizarlo obteniendo un grafo G que verica las condiciones de la denición para vdoc, siempre y cuando el nuevo nodo padre de v i no sea un descendiente de v i en el grafo (lo cual produciría un ciclo). Por ello podemos denir una nueva operación que denominamos cambio del padre de una versión y denotamos como Update-parent(vDoc, v i, v j ) que cambia el padre de v i a v j. Denición Update-parent(vDoc, v i, v j ). Cambia el padre de v i a v j en el documento versionado vdoc=(g, D, ρ). Por tanto, la versión v i pasa a ser una versión derivada de la versión v j. Precondiciones: (v i V {v 0, v j }) (v j / descendant(v i )). Postcondiciones: Se obtiene el nuevo estado vdoc'=(g', D',ρ ) del documento versionado vdoc=(g, D,ρ), donde: G = (V, (E {(parent(v i ), v i )}) {(v j, v i )}, v 0 ), D = D y ρ ρ. Observaciones:

82 64 Capítulo 3. Modelo de Documentos Versionados vdoc Figura 3.9: Cambio del padre de una versión 1. Nótese que esta operación no se puede descomponer en operaciones intermedias sin obtener un grafo inconsistente. Ejemplo: En la gura 3.9 se muestra la estructura de un documento versionado vdoc=(g, D, ρ) después de ejecutar la operación Update-parent(vDoc, v 9, v 7 ) que cambia el padre de la versión v 9 por la versión v 7. Hemos representado en dicha gura el proceso de cambio de padre mediante una línea discontinua roja etiquetada con el valor 1 y mediante una línea sólida azul la nueva derivación entre las versiones v 7 y v 9. El uso de la línea discontinua en el primer caso indica que deja de existir la relación de derivación entre las versiones v 3 y v 9. Proposición 3.1. La operación Insert-up(vDoc, v i, d j ) se puede expresar como combinación de las operaciones Insert() y Update-parent( ) de la forma: Insert-up(vDoc, v i, d j ) = Insert(vDoc, parent(v i ), d j ) + Update-parent(vDoc, v i, v j ) Nótese que es importante el orden en el que se efectúen las operaciones, ya que la operación Update-parent(vDoc, v i, v j ) requiere que v j G, lo que se consigue con Insert(vDoc, parent(v i ), d j ) Borrado de Versiones Borrado de una Versión con Versiones Hijas Como ya se ha comentado, no se pueden borrar solamente arcos, pues el grafo dejaría de ser conexo. Ya se ha tratado el borrado de una versión hoja, es decir, el borrado de una versión que no ha sido derivada en ninguna otra, mediante la operación Delete-leaf(vDoc, v i ). ¾Y para los nodos que no sean hojas?, ¾podemos denir algún tipo de borrado? Al borrar un nodo no hoja, es decir, que tenga versiones hijas derivadas, los nodos hijos quedarán desconectados en el árbol. Parece lógico que estas versiones se deriven a partir de su abuelo, es decir, del padre de la versión que se ha borrado. Esta idea se puede rearmar si consideramos una relación de transitividad en la noción de derivación, de forma que podemos decir que si v i deriva en v j y ésta en v k, podremos decir que también v i deriva en v k. Este tipo de borrado se reeja en la siguiente denición:

83 Revisión de las Operaciones sobre Documentos de Versionado 65 Figura 3.10: Borrado de una versión con versiones hijas (1/2) Denición Delete(vDoc, v i ). Borra el nodo no hoja v i, eliminando su documento asociado y todas las derivaciones en las que intervenga e introduciendo las derivaciones entre parent(v i ) y todos los hijos de v i en el documento versionado vdoc=(g, D, ρ). Precondiciones: (v i V {v 0 }) ( Is_leaf(v i )) Postcondiciones: Se obtiene el nuevo estado vdoc'=(g', D', ρ ) del documento versionado vdoc=(g, D, ρ), donde: G = (V {v i }, E {(parent(v i ), v i )} {(v i, v j )/v j child(v i )} {(parent(v i ), v j )/v j child(v i )}, v 0 ), D = D {d i } y ρ ρ /v i. Ejemplo: En la gura 3.10 se muestra el resultado de aplicar la operación Delete(vDoc, v 3 ), que realiza el borrado del nodo no hoja v 3. Nótese que el borrado de la versión v 3 lleva asociado el borrado en D del documento d 3 = ρ 1 (v 3 ) asociado a dicha versión, y el borrado de los arcos en que aparece la versión v 3, añadiéndose todos los arcos que van desde la versión v 2 = parent(v 3 ) a cada uno de los hijos de v 3. El uso de la línea discontinua indica que deja de existir la relación de derivación entre las versiones v 3 - v 9 y v 3 - v 4 por el borrado de la versión v 3. Es interesante considerar que esta operación se puede expresar en función de las operaciones Update-parent() y Delete-leaf(), como indica la siguiente Proposición: Proposición 3.2. La operación Delete(vDoc, ví), se puede denir para cualquier nodo (v i V {v 0 }) y expresarse en función de las operaciones Update-parent() y Delete-leaf() de la siguiente forma: Delete(vDoc, v i ) = v j child(v i ) {Update_parent(vDoc, v j, parent(v i )}+Delete_leaf(vDoc, v i ) Ejemplo: En la gura 3.11 se muestra el resultado de aplicar la operación Delete(vDoc, v 3 ), que realiza el borrado del nodo no hoja v 3, realizado mediante las operaciones Updateparent() y Delete-leaf(). Al igual que en el ejemplo, el uso de la línea discontinua indica que deja de existir la relación de derivación.

84 66 Capítulo 3. Modelo de Documentos Versionados vdoc Figura 3.11: Borrado de una versión con versiones hijas (2/2) 3.4. Extensión de Operaciones sobre Documentos de Versionado Además de las operaciones anteriores, necesitaremos frecuentemente otras que nos ayuden a mantener y gestionar las versiones existentes, en especial para controlar el crecimiento de versiones de un mismo documento versionado. Debemos pensar que el proceso de versionado proporciona una perspectiva histórica del desarrollo de un objeto, pero frecuentemente nos interesa desechar aquellas versiones que no aportan una información adecuada y mantener sólo las que son representativas de la evolución del documento. Por ello consideramos en esta sección un conjunto de operaciones que ayudan a controlar el crecimiento de versiones permitiendo algún tipo de borrado de versiones que no sean satisfactorias; estas operaciones se han clasicado en tres grandes tipos: sustitución de versiones, borrado masivo de versiones y fusión de versiones. La operación de sustitución permitirá cambiar un documento por otro con la particularidad de que la versión asociada mantiene las mismas relaciones de derivación que las asociadas al anterior documento. En la operación de borrado masivo, suelen ser frecuentes operaciones de vaciado de versiones a partir de una versión dada. Por ello se introducirán operaciones de poda a partir de una versión dada, bien manteniendo dicha versión o borrándola también. Finalmente, se consideran operaciones de fusión, que suelen abrir un extenso conjunto de problemas en situaciones en las que diferentes usuarios han trabajado en otros tantos desarrollos del documento versionado y se decide unicar todas sus aportaciones en una única versión Sustitución de Versiones Dado un documento versionado vdoc podemos considerar la sustitución de una versión existente. Eso signica sustituir una versión v i y su documento asociado d i por otro documento d j y su versión asociada v j, de forma que la versión v j siga manteniendo las mismas relaciones con las versiones del documento versionado que las que poseía v i, como se indica en la siguiente

85 Extensión de Operaciones sobre Documentos de Versionado 67 denición: Figura 3.12: Sustitución de versiones (1/2) Denición Replace(vDoc, v i, d j ). Sustituye en el documento versionado vdoc=(g, D, ρ) la versión v i V {v 0 } por una nueva versión v j cuyo documento asociado es d j. Precondiciones: (v j / G) (d j / D) (v i V {v 0 }). Postcondiciones: Se obtiene el nuevo estado vdoc'=(g', D', ρ ) del documento versionado vdoc=(g, D, ρ), donde: G = ((V {v i }) {v j }, E {(parent(v i ), v j )} {(parent(v i ), v i )} {(v i, v k )/v k child(v i )} {(v j, v k )/v k child(v i )}, v 0 ), D = D {d i } {d j } y ρ [ρ (v j ρ(v j ) = d j )]. Ejemplo: En la gura 3.12 se muestra el resultado de aplicar la operación Replace(vDoc, v 3, d 11 ), que elimina del grafo de versiones la versión v 3, sustituyéndola por la nueva versión v 11 donde ρ(v 11 ) = d 11. Debe observarse que esta operación no se puede expresar como la composición de solamente las operaciones de borrado e inserción, pues al realizar el borrado perdemos la información de las derivaciones de la versión borrada con el resto de existentes para el documento versionado. En cambio, esta operación sí se puede expresar mediante las operaciones Update-parent(), Delete-leaf() e Insert(), como muestra la siguiente proposición: Proposición 3.3. La operación Replace(vDoc, ví,d j ), se puede denir para cualquier nodo (v i V {v 0 }) y expresarse en función de las operaciones Insert(), Update-parent() y Deleteleaf() de la siguiente forma: Replace(vDoc, v i, d j ) = Insert(vDoc, parent(v i ), d j ) + {Update_parent(vDoc, v k, v j )} v k child(v i ) + Delete_leaf(vDoc, v i )) Ejemplo: En la gura 3.13 se muestra el resultado de aplicar la operación Replace(vDoc, v 3, d 11 ), que realiza el borrado del nodo no hoja v 3, y lo sustituye por el nodo v 11 = ρ 1 (d 11 ), realizado mediante las operaciones Insert(), Update-parent() y Delete-leaf().

86 68 Capítulo 3. Modelo de Documentos Versionados vdoc Figura 3.13: Sustitución de versiones (2/2) Poda de Versiones Uno de los ejemplos más habituales de borrado masivo son las situaciones de poda, en las cuales se decide que un conjunto de versiones derivadas a partir de una versión dada no son de interés y, por tanto, deseamos su eliminación del conjunto de versiones del documento versionado. Para especicar la operación de poda se indicará un nodo a partir del cual se realizará el borrado de todos sus nodos descendientes. En esta sección se distingue entre la poda a partir de un nodo sin borrarlo y la poda que incluye el borrado de dicho nodo Poda de los Descendientes de una Versión Denición Prune-from(vDoc, v i ). Elimina todos los nodos descendientes de la versión v i en el documento versionado vdoc=(g, D, ρ) para cualquier versión v i V {v 0 }. Precondiciones: v i V {v 0 }. Postcondiciones: Se obtiene un nuevo vdoc'=(g', D', ρ ) del documento versionado vdoc=(g, D, ρ), donde: G = (V {v j }, v j descendant(v i ), D = D {d j }yρ ρ /v j. Ejemplo: En la gura 3.14 se muestra el resultado de aplicar la operación Prune-from(vDoc, v 2 ), que elimina del grafo de versiones las versiones descendientes de v 2. Esta operación se puede expresar mediante la operación Delete para todos las versiones descendientes de la versión dada como muestra la siguiente proposición: Proposición 3.4. La operación Prune-from(vDoc, ví), se puede denir para cualquier nodo (v i V {v 0 }) y expresarse en función de la operación Delete() de la siguiente forma: P rune from(vdoc, v i ) = delete(v j )/ v j descendant(v i )

87 Extensión de Operaciones sobre Documentos de Versionado 69 Figura 3.14: Poda de los descendientes de una versión Poda a partir de una Versión Denición Prune(vDoc, v i ). Elimina todos los nodos descendientes de la versión v i incluyendo el propio nodo v i en el documento versionado vdoc=(g, D, ρ) para cualquier versión v i V {v 0 }. Precondiciones: v i V {v 0 }. Postcondiciones: Se obtiene un nuevo vdoc'=(g', D',ρ ) del documento versionado vdoc=(g, D,ρ), donde: G = (V {v j v i }, v j descendant(v i ), D = D {d j d i }. Ejemplo: En la gura 3.15 se muestra el resultado de aplicar la operación Prune(vDoc, v 2 ), que elimina del grafo de versiones la versión v 2 junto con todas sus descendientes. Esta operación se puede expresar mediante la composición de las operaciones P rune f rom y Delete como muestra la siguiente proposición: Proposición 3.5. La operación Prune(vDoc, ví), se puede denir para cualquier nodo (v i V {v 0 }) y expresarse en función de la operación Prune-from y Delete() de la siguiente forma: P rune(vdoc, v i ) = P rune from(vdoc, v i ) + delete(v i ) Fusión de Versiones Una de las operaciones más habituales en los sistemas de versionado es la fusión de versiones que añade una nueva versión al documento de versionado vdoc. Este nuevo documento tiene la particularidad de contener aquellos elementos comunes de dos versiones dadas del grafo de versionado, es decir, a partir de dos documentos contenidos en el grafo de versionado se genera un nuevo documento, y con ello una nueva versión, con aquellas partes del documento que son comunes. Nótese que en este apartado no discutiremos cómo se realiza internamente la operación de fusión sino cómo se representa en nuestro modelo de datos la inserción de un nuevo documento generado por dicha operación.

88 70 Capítulo 3. Modelo de Documentos Versionados vdoc Figura 3.15: Poda a partir de una versión Para especicar la operación de fusión se indicará un par de nodos del documento de versionado a partir de los cuales se realizará la fusión. En esta sección se distinguen distintos casos: la fusión de dos versiones hermanas, la fusión de dos versiones no hermanas y, nalmente, la generalización de ambas operaciones en lo que hemos denominado la fusión general de versiones Fusión de Versiones Hojas Hermanas Denición Merge(vDoc, {v i, v j }, d k ). Añade una nueva versión al documento versionado vdoc=(g, D, ρ) cuyo documento asociado es d k obtenido de la fusión de los documentos asociados a las versiones v i y v j y que se ha derivado de la versión padre de v i y v j. Precondiciones: v i, v j V {v 0 } parent(v i ) = parent(v j ) d k / D. Postcondiciones: Se obtiene el nuevo estado vdoc'=(g', D', ρ ) del documento versionado vdoc=(g, D, ρ), donde: G = (V {v j }, E {(parent(v i ), v k )}, v 0 ), D = D {d k } y ρ [ρ (v k ρ(v k ) = d k )]. Observaciones: 1. Las versiones v i y v j deben ser hojas. 2. La condición (d k / D) se reere a que no existe ningún subíndice k ya utilizado al describir los elementos de D. Como ya se ha comentado al denir la función ρ, puede que el contenido de d k sea el mismo que el de otro documento d l D, pero se considerarán documentos distintos si k l. Ejemplo: En la gura 3.17 se muestra el resultado de aplicar la operación Merge(vDoc, {v 4, v 9 }, d 10 ) al documento de versionado. Esta operación genera un nuevo documento d 10, que deriva de la versión v 3, versión padre de las versiones v 4 y v 9. Hemos representado en esta gura el proceso de fusión mediante una línea discontinua roja etiquetada con el valor 1 y mediante una línea sólida azul la derivación entre las versiones v 3 y v 10. El uso de la línea discontinua en el primer caso indica que no existe ninguna relación de derivación entre

89 Extensión de Operaciones sobre Documentos de Versionado 71 Figura 3.16: Fusión de versiones hojas hermanas las v 4 y v 9 con v 10 aunque este documento se ha obtenido a partir de la fusión de ambos documentos. Esta operación se puede expresar mediante la operación Insert como muestra la siguiente proposición: Proposición 3.6. La operación Merge(vDoc, {v i, v j }, d k ), se puede denir para dos nodos (v i, v j V {v 0 }) y expresarse en función de la operación Insert de la siguiente forma: Merge(vDoc, {v i, v j }, d k ) = Insert(vDoc, parent(v i ), d k ) Fusión de Versiones Hojas no Hermanas Denición Merge(vDoc, {v i, v j }, d k ). Añade una nueva versión al documento versionado vdoc=(g, D, ρ) cuyo documento asociado es d k obtenido de la fusión de los documentos asociados a las versiones hojas v i y v j. Este nuevo documento se ha derivado del primer antecesor común más próximo común de las versiones v i y v j. Precondiciones: v i, v j V {v 0 } d k / D. Postcondiciones: Se obtiene el nuevo estado vdoc'=(g', D', ρ ) del documento versionado vdoc=(g, D, ρ) donde G = (V {v j }, E {v m, v k )}, v 0 ), D = D {d k } y ρ [ρ (v k ρ(v k ) = d k )]; siendo v m el primer antecesor común más próximo de v i y v j. Observaciones: 1. Las versiones v i y v j deben ser hojas. 2. La condición (d k / D) se reere a que no existe ningún subíndice k ya utilizado al describir los elementos de D. Como ya se ha comentado al denir la función ρ, puede que el contenido de d k sea el mismo que el de otro documento d l D, pero se considerarán documentos distintos si k l.

90 72 Capítulo 3. Modelo de Documentos Versionados vdoc Figura 3.17: Fusión de versiones hojas no hermanas 3. En esta operación de fusión el nuevo documento se ha derivado del primer antecesor común más próximo de las versiones v i y v j y, por tanto, el documento obtenido se puede encontrar en un nivel distinto de las versiones que se han fusionado. Ejemplo: En la gura 3.16 se muestra el resultado de aplicar la operación Merge(vDoc, {v 9, v 7 }, d 10 ) al documento de versionado. Esta operación genera un nuevo documento d 10, que deriva de la versión v 2, pues es la versión antecesor común más próximo entre ambas versiones. Al igual que en el ejemplo anterior, hemos representado el proceso de fusión mediante una línea discontinua roja etiquetada con el valor 1 para aquellas derivaciones que desaparecen y mediante una línea sólida azul la nueva derivación entre las versiones v 2 y v 10. Esta operación se puede expresar mediante la operación Insert como muestra la siguiente proposición: Proposición 3.7. La operación Merge(vDoc, {v i, v j }, d k ) se puede denir para dos nodos (v i, v j V {v 0 }) y expresarse en función de la operación Insert de la siguiente forma donde v m es el primer antecesor común más próximo de v i y v j : Fusión General de Versiones Merge(vDoc, {v i, v j }, d k ) = Insert(vDoc, v m, d k ) Denición Merge(vDoc, {v}, d k ). Añade una nueva versión al documento versionado vdoc=(g, D, ρ) cuyo documento asociado es d k obtenido de la fusión del conjunto de documentos asociados al conjunto de versiones v. Este nuevo documento se ha derivado del primer antecesor común más próximo del conjunto de versiones v. Precondiciones: v i v, v V {v 0 } d k / D. Postcondiciones: Se obtiene el nuevo estado vdoc'=(g', D',ρ ) del documento versionado vdoc=(g, D,ρ), donde G = (V {v j }, E {v m, v k )}, v 0 ), D = D {d k } y ρ [ρ (v k ρ(v k ) = d k )] siendo v m el primer antecesor común más próximo de v i y v j. Observaciones:

91 Operaciones Primitivas 73 Figura 3.18: Fusión general de versiones 1. Nótese que no es necesario que la versión v i y v j sea una hoja, es decir, esta operación puede aplicarse a cualquier versión existente en el grafo D. 2. La condición (d k / D) se reere a que no existe ningún subíndice k ya utilizado al describir los elementos de D. Como ya se ha comentado al denir la función ρ, puede que el contenido de d k sea el mismo que el de otro documento d l D, pero se considerarán documentos distintos si k l. 3. En esta operación de fusión el nuevo documento se ha derivado del primer antecesor común de las versiones v i y v j y por tanto el documento obtenido se puede encontrar en un nivel distinto de las versiones que se han fusionado. Ejemplo: En la gura 3.18 se muestra el resultado de aplicar la operación Merge(vDoc, {v 3, v 5, v 8 }, d 10 ) al documento de versionado. Esta operación genera un nuevo documento d 10, que deriva de la versión v 1, pues es la versión descendiente común entre ambas versiones. Hemos usado en la gura una línea discontinua roja etiquetada con el valor 1 para reejar las derivaciones que se eliminan y mediante una línea sólida azul la nueva derivación entre las versiones v 1 y v 10. Esta operación se puede expresar mediante la operación Insert como muestra la siguiente proposición: Proposición 3.8. La operación Merge(vDoc, {v i, v j }, d k ), se puede denir para dos nodos (v i, v j V {v 0 }) y expresarse en función de la operación Insert de la siguiente forma donde v m es el primer antecesor común más próximo de v i y v j : Merge(vDoc, {v i, v j }, d k ) = Insert(vDoc, v m, d k ) 3.5. Operaciones Primitivas En las secciones anteriores se ha analizado un conjunto de primitivas a partir de las cuales se pueden denir todas las operaciones que vamos a considerar sobre los documentos de versionado vdoc. Para cada una de ellas hemos presentado su sintaxis, descripción, precondiciones

92 74 Capítulo 3. Modelo de Documentos Versionados vdoc y postcondiciones, así como un ejemplo de uso. En esta sección, establecemos cuáles se pueden considerar operaciones primitivas dentro de nuestro modelo de datos y cuáles consideramos adicionales para llevar a cabo la gestión de documentos versionados Operaciones Primitivas La tabla 3.1 describe las operaciones primitivas para gestionar las versiones de los objetos vdoc. Éste es un conjunto mínimo para denir todas las operaciones que se puedan plantear sobre un documento versionado y nos permitirá formalizar las operaciones adicionales. En dicha tabla se presenta, junto a la sintaxis de cada operación, una breve descripción. Tabla 3.1: Operaciones Primitivas para vdoc Primitivas de vdoc Create (vdoc) Descripción Crea un documento versionado vdoc vacío, que consta sólo del documento vacío d 0 Insert (vdoc, v i, d new) Añade d new a D e inserta en G el arco ( v i, ρ 1 (d new)) GetDoc (vdoc, v i) Obtiene el documento d i = ρ(v i) asociado a la versión v i. Delete-leaf (vdoc, v i) Borra una hoja v idel grafo G; i.e. borra en el grafo G el nodo v i V y el arco (parent(v i), v i) E y además borra el documento d i = ρ 1 (v i) D y actualiza la función ρ. Update-parent (vdoc, Cambia parent( v i) por v j; i.e. cambia en G el arco (parent( v i), v i) por (v j, v i, v j) v i) Operaciones Adicionales para la Gestión de Documentos Versionados En la tabla 3.2 se muestra un conjunto de operaciones útiles sobre documentos de versionado que permiten gestionar más fácilmente las versiones. Operaciones adicionales Insert-up (vdoc, v i, d new) Delete (vdoc, v i) Tabla 3.2: Operaciones adicionales para vdoc Descripción Añade d new a D y sustituye en G el arco (parent( v i), v i) por los arcos (parent( v i), v new) y ( v new, v i), donde d new = ρ 1 (v i). Elimina el arco (parent( v i), v i) y sustituye todos los arcos ( v i, v j), con v j child(v i) por (parent( v i), v j)). Además elimina d i de D y ajusta la función ρ. Sustituye la versión v i por la versión v j asociada al documento d j = ρ 1 (v j). Replace (vdoc, v i, d j) Prune-from (vdoc, v i) Poda del árbol G todos los descendientes de v i. Prune(vDoc, v i) Poda del árbol G el subárbol con raíz v i. Merge (vdoc, v i, v j, d k ) Se crea la versión v k asociada al documento d k a partir de la fusión de las versiones v iy v jy tendrá como padre al antepasado común de ambas.

93 Conclusiones Conclusiones En este capítulo se ha propuesto el modelo vdoc deniendo el concepto de documento versionado así como las operaciones que se pueden realizar sobre él. Hemos considerado como operaciones primitivas las más habituales y simples de un sistema de versionado que consisten en: la creación de un documento versionado con sólo el documento vacío, la función de obtención del documento a partir de una versión y las operaciones de inserción y borrado de versiones hojas y la modicación del padre. Además se ha estudiado un conjunto de operaciones útiles sobre documentos de versionado que se han denominado adicionales. El conjunto de primitivas se pueden considerar un álgebra sobre las versiones de documentos de versionado vdoc. Nótese que el modelo que se ha presentado es un modelo general de gestión de versiones sobre un documento, independientemente del tipo de documento. Por tanto, este modelo se deberá ajustar a la semántica inducida por el contenido de cada tipo de documento que se trate de versionar; este es el caso de los documentos XML que se versionarán con este modelo vdoc para denir el modelo de versionado de documentos XML, que denominaremos vdocxml y explicaremos en los dos próximos capítulos. En concreto, el principal problema que nos encontraremos es cómo fundir el almacenamiento de todos los documentos d i D, reaprovechando los contenidos comunes a varias versiones del documento y en esta tesis hemos resuelto este problema para documentos XML. Además, nos interesaría poder extender el lenguaje de consulta sobre las versiones para recuperar contenidos del documento versionado que aparecen en un conjunto de versiones (comparación de versiones), o averiguar en qué versiones aparece un determinado contenido (determinación de versiones por contenido).

94 76 Capítulo 3. Modelo de Documentos Versionados vdoc

95 Capítulo 4 Modelo de Datos para Documentos XML Contenidos 4.1. Modelo de Datos para Documentos XML: Grafo XML Observaciones al Modelo de Datos Propuesto Cambios en un Grafo XML CrearGrafoXML AñadirNodo BorrarNodoDato BorrarNodoElemento ActualizarNodoDato Representación de un Grafo XML en un Documento XML Conversión de un grafo XML en un Documento XML Conversión de un Documento XML en un Grafo XML Modelización de Documentos XML mediante Grafos XML Identicación de Grafos XML y Documentos XML Cambios en Documentos XML Conclusiones En el modelo de versionado genérico de documentos denido en el capítulo anterior, la creación de una nueva versión se obtiene a partir de una única versión precedente. En el caso más habitual, cada versión consiste en modicar sólo parcialmente el documento asociado a la versión de la cual deriva. De esta forma, los documentos asociados a las diferentes versiones suelen contener gran cantidad de información común. Esto nos lleva a considerar la posibilidad de fundir el almacenamiento de todos los documentos o versiones reaprovechando los contenidos comunes a varias versiones del documento. En este capítulo se dene el modelo de datos de documentos XML, así como las operaciones básicas de cambio que provocan un nuevo estado del mismo, para posteriormente en el siguiente capítulo, proponer nuestra técnica para la integración de todas las versiones en un único documento XML.

96 78 Capítulo 4. Modelo de Datos para Documentos XML En la sección 4.1 se presenta nuestro modelo de datos para documentos XML [Bray 98], basado en el modelo descrito en [Beech 99], que se fundamenta en un grafo acíclico dirigido con un único nodo raíz y que denominaremos Grafo XML. Existen muchas propuestas de modelo de datos XML [Beech 99, Beeri 99, Jagadish 02, Su 01, Frasincar 02] y la gran mayoría de ellas modelan este tipo de documentos mediante una estructura arbórea. Aunque, por lo general, una estructura arbórea puede usarse para representar sintácticamente un documento XML, se ha optado por utilizar un modelo basado en grafos debido a que nuestra técnica para gestionar versiones XML requiere el uso de unos arcos especiales, denominados arcos referencias, que deben ser modelados mediante este tipo de estructuras de datos. Como se verá en el siguiente capítulo, a la hora de representar un documento XML versionado es necesario que los vértices que representan cada versión puedan tener más de un arco de entrada, procedentes de los elementos asociados a dicha versión, siendo imposible reejar este hecho mediante una estructura arbórea. Con esta estructura representaremos las diferentes piezas que componen un documento XML (elementos, atributos y contenido) y las relaciones entre ellas, usando para ello distintos tipos de vértices y de arcos en el grafo XML. En la sección 4.2 se profundiza en el estudio de las operaciones de cambio que se pueden producir sobre un grafo XML y que son las causantes de la aparición de nuevos estados o versiones del grafo XML. En este trabajo hemos considerado únicamente las operaciones básicas: inserción, borrado y actualización de vértices hojas en el grafo XML. Cada una de ellas será analizada en profundidad centrándonos en los siguientes factores: signicado, parámetros, precondiciones y postcondiciones resultado de su ejecución. A lo largo de esta segunda sección se mostrarán distintos ejemplos grácos que faciliten su comprensión. En la sección 4.3 se estudia el proceso de transformación de un grafo XML a un documento XML y viceversa. Estos algoritmos nos permitirán establecer una función biyectiva entre los dos tipos de objetos, es decir, podremos especicar indistintamente las operaciones tanto sobre grafos XML como sobre sus documentos XML asociados. En la sección 4.4 se describen las primitivas de cambios, sobre documentos XML. Para ello hemos enfocado nuestro estudio únicamente sobre los componentes de un documento XML analizados en la primera sección: elementos, atributos y contenido. Sobre éstos, abordamos las operaciones para añadirlos, eliminarlos o actualizarlos en un documento XML. Este conjunto de operaciones resulta ser completo, mínimo y consistente para poder expresar cualquier operación de cambio sobre un documento XML, tal y como se expone en [Su 01]: estas operaciones reejan todas las posibles operaciones de cambio sobre un documento XML, no se puede prescindir de ninguna de ellas y el documento XML resultante sigue estando bien formado una vez que se han ejecutado las mismas. Terminamos esta sección describiendo la noción de composición de primitivas de cambio, que permite expresar como una unidad el conjunto de cambios que sufre un documento XML hasta transformarse en una nueva versión, aunque este concepto se desarrollará en profundidad en el Capítulo Modelo de Datos para Documentos XML: Grafo XML Un documento XML está formado por una serie de elementos que identican los contenidos informativos que contiene el documento y hacen explícita su estructura. Por este motivo un documento XML puede ser considerado como una fuente de almacenamiento semi-estructurada. De este modo, un documento XML está compuesto por una colección de elementos delimitados por una etiqueta de apertura y otra de cierre, entre las cuales se encuentra el contenido

97 Modelo de Datos para Documentos XML: Grafo XML 79 de dicho elemento, que puede ser información textual, otros elementos anidados o carecer de información (elemento vacío). Además, la etiqueta de apertura puede incluir información adicional mediante atributos. En los últimos años se ha propuesto un gran número de modelos de datos generales para documentos XML [Beech 99, Beeri 99, Su 01, Jagadish 02, Frasincar 02], así como modelos especícos para XML temporales [Amagasa 00, Manukyan 01, Grandi 03b], indexación [Vagena 04, Mendelzon 04], autorización [di Vimercati 02], etc. Muchos de éstos se encuentran basados en los modelos para documentos semi-estructurados propuestos en [Buneman 97, Abiteboul 97, Abiteboul 00], entre los que destaca el Modelo de Intercambio de Objetos (OEM, Object Exchange Model). OEM [Abiteboul 00] puede considerarse como un grafo dirigido etiquetado, donde los nodos son objetos. Estos objetos pueden clasicarse bien como objetos atómicos, que contienen un valor para el tipo base (entero, cadena de caracteres,... ) y sin arcos de salida, o bien como objetos complejos, cuyo tipo es un conjunto de identicadores de objetos. Los objetos complejos pueden ser padres de múltiples objetos o hijos de múltiples padres. Los documentos XML pueden considerarse como una especialización de OEM, pues se pueden modelar mediante un grafo dirigido con un único nodo raíz donde sus nodos, en lugar de representar objetos, denen un elemento del documento o su valor y los arcos establecen la relación entre los elementos y subelementos o la relación elemento-valor de los atributos o contenido. Los investigadores en este campo han centrado sus modelos en dos tipos de estructuras: arbóreas [Jagadish 02, Frasincar 02] o de grafo [Beech 99, Rizzolo 08]. La principal diferencia entre ellas reside en la forma de tratar los documentos XML: únicamente a nivel estructural, es decir, compuestos por un conjunto de nodos y arcos donde solamente se formaliza la relación padre-hijo entre los nodos, o bien representar los constructores referencias que permiten enlazar desde un nodo del grafo a otro del mismo u otro grafo (IDREF, IDREFS, XLINK, XPointer). En este último caso un determinado nodo o vértice puede tener más de un arco de entrada procedente de uno o más vértices. Un análisis detallado sobre éstos distintos modelos de datos para documentos XML se realiza en [Frasincar 02] donde el autor analiza cada uno de ellos a partir de su álgebra y las operaciones que se pueden realizar sobre ellos. A partir de este estudio, y sabiendo que el modelo propuesto en el capítulo siguiente necesita de un modelo de datos XML basado en una estructura de grafo para representar los documentos XML, el modelo propuesto en esta tesis, formalizado en este apartado, se basa en el modelo descrito en [Beech 99], especicado mediante un grafo acíclico dirigido con un único nodo raíz. Su elección se debe a que este modelo de datos recoge todas las características necesarias para denir un documento XML, incluyendo los documentos XML versionados. De este modo un documento XML se podrá denir como un grafo XML, y un grafo XML como un documento XML según mostraremos en la sección 4.3. Para ello partiremos de la siguiente denición de grafo XML: Denición 4.1. (Grafo XML) Un grafo XML G es un grafo acíclico dirigido y conexo con un nodo raíz, que denotaremos como G=(V, E, root) donde V es un conjunto nito de vértices en el grafo, E es un conjunto nito de arcos dirigidos entre los vértices en V y root V es la raíz del grafo y que verica las siguientes propiedades: 1. Cada vértice v V tiene dos propiedades: type(v) T v y value(v) D(type(v)), donde T v es un conjunto nito de tipos T v ={element, ID, IDREF, IDREFS, string, int,...} y cada

98 80 Capítulo 4. Modelo de Datos para Documentos XML tipo t en T v tiene un dominio de valores, denotado como D(t). Esto permite clasicar los vértices en varias clases según su tipo asociado, de las cuales destacaremos los vértices de tipo elemento y el resto de tipo data, entre los que tendrán un tratamiento especial los tipos ID, IDREF, IDREFS. a) Vértices son de tipo element o data, V = V element V data donde V data = V ID V IDREF V IDREFS V int V string V date... con V i ={v V/type(v)=i}, i T v. b) Denotaremos D(element) ={ &i/i N} {root} c) v 1,v 2 V element, value(v 1 ) = value(v 2 ) v 1 =v 2. d) D(IDREFS)=P (D (ID))={u D(ID)/ u es nito} con D(ID)=D(IDREF). e) v 1,v 2 V ID, value(v 1 ) = value(v 2 ) v 1 =v 2. f ) v 1 V IDREF, v 2 V ID / value(v 1 ) = value(v 2 ) g) v 1 V IDREFS ( x value(v 1 ), v V ID / value(v)=x). 2. Cada arco e=(v 1,v 2 ) E tiene dos propiedades type y name con type(e) {E,A,R} que clasica E en tres conjuntos disjuntos (elementos, atributos y referencias) que denotaremos E = E E E A E R (con E i E j =φ, i j ), y name(e) N(type(e)) donde N(type(e)) denota el conjunto de nombres válidos para cada tipo de arco. También denotaremos parent(e)=v 1 y child(e)=v 2, teniendo las siguientes propiedades: e=(v 1,v 2 ) E E E A, name(e) ~ref. e=(v 1,v 2 ) E E, [( parent(e) = v 1 V element ) ( child(e) = v 2 V data ] ( name(e)=~data). e=(v 1, v 2 ) E A, ( parent(e) = v 1 V element ) ( child(e) = v 2 V data ). e 1, e 2 E A / ((parent(e 1 ) = ( parent(e 2 ) name(e 1 ) = name(e 2 )) e 1 = e 2 e=(v 1,v 2 ) E R, child(e) = v 2 V ID,name(e) = ~ref ˆ Si parent(e) = v 1 V IDREF (value(child(e)) = value(parent(e)))) ˆ Si parent(e)= v 1 V IDREFS (value(child(e)) value(parent(e))) 3. Se ha denido v Velement, outedges (v) = {e i E E / parent(e i )=v}, y v (V element -V ID ), inedges(v)={e j E E /child(e j )=v} con las siguientes propiedades: a) Card(inedges(root))=0) (Card(outedges(root)) 1 donde Card es una función que cuenta el número de arcos de salida u entrada. b) v V element -{root}, Card(inedges(v))=1 c) v V element, una relación de orden O v para sus arcos de salida outedges (v): O v ={(e 1,e 2,...,e n ) / (outedges (v) = 1<i<n {e i} E E ) ( i/name(e i )=name(e i+1 )= ~data)} Observaciones: 1. Un grafo XML vacío se encuentra formado por el vértice root, único vértice del grafo que no se puede borrar o actualizar y el cual no tiene arco de entrada. En el caso de que (Card(outedges(root)) = 0, diremos que el grafo XML está vacío.

99 Modelo de Datos para Documentos XML: Grafo XML Mientras que los vértices de tipo element se identican por su contenido (punto 1.c de la denición 1), la identicación de los vértices data se realizará en base a su vértice element padre y al arco que los une. Por tanto, en el modelo propuesto pueden existir dos o más vértices data distintos con el mismo valor para las propiedades type y value. Aunque se podrían representar usando un único vértice, no se ha optado por esa solución para evitar las complicaciones que se producirían en las operaciones de actualización. 3. El modelo de datos XML propuesto permite la representación de elementos XML mixtos, es decir, un vértice element con varios arcos E E de salida hacia vértices tanto data como element. Se ha considerado igualmente que no pueden existir dos arcos ~data consecutivos para un mismo vértice padre (punto 3.c de la denición 1). Denición 4.2. (Grafo XML Bien Formado) Un grafo XML G=(V, E, root) está bien formado si cumple el modelo descrito en la denición 4.1. La gura 4.1 muestra la representación gráca, en nuestro modelo de datos, de un grafo XML que contiene información sobre los restaurantes de una determinada ciudad así como de sus cocineros. El ejemplo se corresponde con el mismo documento XML mostrado en la gura 2.5. Con el n de claricar esta gura, hemos utilizado distintas representaciones grácas dependiendo del tipo de vértice y del arco: un circulo sólido para vértices element, un círculo con trazo de rayas discontinua para vértices ID (que representan valores únicos en el documento), un círculo rayas y puntos discontinuos para vértices data y nalmente un círculo de trazo punteado para vértices data con información referencia (IDREF o IDREFS). De forma análoga, se ha empleado también una representación distinta para cada tipo de arco (elemento, atributo y referencia): una echa con trazo continuo para los arcos que unen dos vértices element, una echa con trazo de rayas discontinuas para un arco que enlaza un vértice element con un vértice data y nalmente una echa punteada para los arcos referencia. Figura 4.1: Representación gráca de un Grafo XML A partir de esta gura podemos comprobar la existencia de un vértice especial etiquetado como root, único vértice sin arco de entrada, que establece el inicio del anidamiento entre los distintos vértices del grafo XML. En este caso concreto, desde este vértice existe un arco de salida E E al vértice &1, etiquetado como doc, que constituye el elemento raíz del documento

100 82 Capítulo 4. Modelo de Datos para Documentos XML XML. Cada vértice v del grafo con type(v)=element tiene como propiedad value (v)=&i donde &i es un valor único que identica al vértice. Desde el vértice &1 salen dos arcos E E cuya propiedad name son cook y rest respectivamente que establecen dos elementos XML denominados cook y rest respectivamente. Desde el vértice &3 existen dos tipos de arcos de salida: por una parte, dos arcos de tipo A que representan atributos XML y tres arcos E que constituyen tres subelementos de este vértice. Cada uno de estos tres vértices tienen como salida un arco E E a vértices data, que representan el contenido asociado a estos vértices. Finalmente nótese que desde el vértice data con propiedad value=c1 existe un arco referencia que enlaza dicho vértice con otro vértice del documento cuya propiedad type es ID, teniendo el nodo destinatario dos arcos entrantes. En la tabla 4.1 se muestran de forma resumida las propiedades de los vértices y arcos del grafo anterior, así como la información asociada a la relación de orden existente entre los arcos de salida de cada vértice. Nótese que esta relación de orden se aplica a los arcos E E que o bien unen dos vértices element o un vértice element con un vértice data del grafo XML, pues tal y como se reeja en la recomendación del W3C sobre XML los atributos asociados a un elemento carecen de orden (igualmente para los arcos referencias). Tabla 4.1: Representación en formato tabla del grafo XML de la gura 4.1 Vértice Vert. type value Orden v 1 Element root e 1 v 2 Element &1 e 2,e 5 v 3 Element &2 - v 4 String c1 - v 5 String Arzak - v 6 Element &3 e 9,e 11,e 13 v 7 String r1 - v 8 String c1 - v 9 Element &4 e 10 v 10 String Seafood - v 11 Element &5 e 12 v 12 String Spanish - v 13 Element &6 e 14 v 14 int 15 - Arco Edge (v 1,v 2) type name e 1 (root,&1) E doc e 2 (&1,&2) E cook e 3 (&2, v 4) A id e 4 (&2, v 5) A name e 5 (&1,&3) E rest e 6 (&3,v 7) A id e 7 (&3,v 8) A cooks e 8 (v 4,v 8) R ~ref e 9 (&3,&4) E name e 10 (&4,v 10) E ~data e 11 (&3,&5) E menu e 12 (&5,v 12) E ~data e 13 (&3,&6) E price e 14 (&6,v 14) E ~data Observaciones al Modelo de Datos Propuesto Una cuestión que surge a partir de la denición 4.1 es: ¾cómo se sabe el tipo que tiene asociado un vértice data?. El modelo de datos propuesto no contempla el procesamiento de documentos que denan esquemas asociados al documento XML. Estos esquemas pueden establecer un conjunto de restricciones y/o reglas de formación de un grafo XML, como por ejemplo que denan los tipos asociados a los contenidos de cada elemento. Sin embargo, supondremos que éste es un proceso independiente de nuestro modelo, y que se parte de esta información para decidir tanto el tipo asociado a cada elemento que se añada al grafo XML como para vericar dicho grafo posteriormente. En nuestro caso, el tipo de documento que se

101 Cambios en un Grafo XML 83 va a modelar como grafo XML gestionará sólo el atributo xml:id con tipo ID, que lleva asociada su unicidad en el documento [Veillard 05], y el tipo IDREFS para un atributo que enlace con los elementos de valor de atributo xml:id referenciados; el resto de tipos de los elementos data será CDATA. Este es el único tipo de referencias que necesitaremos para representar nuestro documento XML de versionado, vxml, tal y como se verá posteriormente en el Capítulo 5. La validez de cada versión respecto a su esquema podrá realizarse de forma independiente, tanto antes de fundir la versión en nuestro documento vxml, como después de recuperar la versión a partir del documento vxml. El arco referencia, descrito en el apartado anterior, tiene la semántica añadida de que debe existir un vértice en el grafo de tipo V ID cuyo valor es el mismo que el valor apuntado por el arco referencia. Aunque la presente tesis hace un tratamiento exclusivamente estructural de un grafo XML, este tipo de arcos se ha incluido en el modelo de datos propuesto pues va a ser fundamental en el modelo de datos, que se propone en el siguiente capítulo, para la representación y gestión de información histórica en grafos XML. El tratamiento de los arcos referencia dentro del modelo de datos XML debería controlar algunos aspectos como: Su representación XML: Actualmente el único mecanismo para establecer la restricción de los arcos referencia es mediante la anexión de un esquema, el cual permite establecer este conjunto de restricciones y/o reglas de formación de un grafo XML concreto. En esta memoria no se incluyen estos tipos de documentos esquemas de modo que para identicar los tipos de vértices V ID, usaremos el nuevo mecanismo del W3C que permite denir unicidades internas en los propios grafos mediante los atributos xml:id [Veillard 05]. Sin embargo en cuanto a los vértices V IDREF y V IDREF S no hay solución para representarlos sin enriquecer un documento XML (por ejemplo que el nombre de los arcos referencias en un documento XML comenzara con el carácter #). Borrado de un vértice V ID al cual hace referencia un vértice V IDREF o actualización de un vértice V IDREF. En ambos casos se debería estudiar una posible solución, que podría ser: permitir la operación de borrado del elemento, realizar la actualización en cascada o no permitir la actualización si existen referencias al vértice. Se quiere hacer constar que estos arcos referencia quedan al margen de la disposición física de un documento XML propuesta en la presente tesis, motivo por el cual el tratamiento que se va a realizar sobre ellos será equivalente al tratamiento sobre un arco atributo. En el siguiente capítulo, como hemos mencionado previamente, sí se realizará la gestión de estos arcos referencia exclusivamente para la gestión de las versiones de un grafo XML Cambios en un Grafo XML El grafo XML mostrado en la gura 4.1 evoluciona lo largo del tiempo debido a cambios introducidos en los menús de los restaurantes, en el precio, en los cocineros de cada restaurante, etc. En este apartado examinaremos cuáles son las operaciones básicas de cambio que se pueden realizar sobre un grafo XML. Antes de proceder a su denición, se estudiarán diversos factores que se han tenido en cuenta. En primer lugar se debe considerar la granularidad del objeto que deseamos modicar en el grafo XML para obtener una nueva versión, es decir, es necesario delimitar qué componentes de un grafo XML son susceptibles de cambio. En este sentido, hemos decidido que

102 84 Capítulo 4. Modelo de Datos para Documentos XML esta granularidad se dene en base a los vértices que representan los objetos básicos de un documento XML: elementos, contenidos de atributos y contenidos de elementos. El modelo se puede generalizar fácilmente para incluir el versionado del resto de elementos que componen un chero XML, como comentarios e instrucciones de procesamiento. En segundo lugar, sobre estos tres tipos de objetos se denirán los constructores válidos de un grafo XML y mediante su aplicación se podrán generar las distintas versiones de un grafo XML. En concreto, se considerarán las operaciones de inserción y borrado a nivel de hojas de esos tres tipos de objetos y la modicación de los contenidos, bien de atributos o de elementos. El conjunto de operaciones se denominará primitivas de cambio en un grafo XML. Además, tal y como se expone en [Su 01] toda taxonomía de operaciones de cambio debe cumplir estas tres propiedades: Completa: Cualquier operación de cambio sobre un grafo XML se puede denir en base a las operaciones denidas, es decir, en base a una o más primitivas de cambio. Mínima: Cada primitiva es sencilla y necesaria, es decir, no se puede llevar a cabo mediante el resto de primitivas o mediante primitivas más sencillas. Bien Formada: La ejecución de cada primitiva debe garantizar que el grafo resultante sigue cumpliendo el modelo de grafo XML. Esta propiedad se garantizará mediante un conjunto de precondiciones y postcondiciones para cada una de las primitivas que garanticen que el nuevo grafo XML generado después del cambio sigue cumpliendo con el modelo de datos propuesto en la sección anterior (denición 4.2) Finalmente, debemos determinar cómo expresar las operaciones de cambio. Nótese que estas operaciones se pueden expresar considerando simplemente la estructura del grafo subyacente al grafo XML, indicando las operaciones sobre vértices y arcos; pero en cada caso deberá seguirse una lógica adicional a la operación que debe conducirnos a obtener un grafo que siga ajustándose a la denición de grafo XML después de realizarla. Por ejemplo, la operación de borrado de un valor de atributo de tipo ID no se debe expresar únicamente borrando el vértice en cuestión, sino que debemos determinar si además se borran todos los arcos referencia que apuntan a él o si no se permite esta operación si existe algún arco referencia que apunte a él. Esto nos lleva a considerar que cada operación primitiva de cambio que deseamos denir puede expresarse mediante un conjunto de operaciones sobre los vértices y arcos del grafo subyacente, y que denominaremos operaciones elementales sobre un grafo XML. A partir de todos los puntos anteriores y teniendo en cuenta las tres propiedades anteriormente mencionadas, hemos considerado las siguientes primitivas de cambio: inserción y borrado de nodos, actualización de un nodo data y la operación de borrado de un nodo data, las cuales garantizan todas las operaciones que se pueden producir sobre un grafo XML. En la tabla 4.2 se ilustran de forma resumida las operaciones de cambio, con una breve descripción y unos casos de uso. (*) Nótese que la operación DeleteElementNode(G, idvertex), aunque no es una operación primitiva, la hemos considerado como tal pues es una generalización del borrado de un nodo elemento para el caso en que no sea un nodo hoja. En efecto, si consideramos la operación DeleteLeafElementNode(G, idvertex), consistente en eliminar un nodo hoja de tipo Element del grafo y su arco de entrada, entonces DeleteElementNode(G, idvertex), consiste en borrar, de forma recursiva y en cascada, todos los descendientes de dicho nodo elemento y nalmente se borra él mismo. Nótese además, que las operaciones DeleteDataNode y UpdateDataNode

103 Cambios en un Grafo XML 85 Tabla 4.2: Primitivas de Cambio en un Grafo XML Operación Descripción Casos de Uso (CG) CreateXMLGraph(G) Crea un grafo XML vacío G Crear grafo XML (AN) AddNode(G, type, newvalue, newedge, typeedge, idparent, pos) Añade un nuevo nodo, de tipo elemento, atributo o dato, junto con su arco de entrada Añadir elemento Añadir atributo Añadir contenido (*)(DEN) DeleteElementNode(G, idvertex) (DDN) DeleteDataNode(G, idparent, nameedge, pos) (UDN) UpdateDataNode(G, idparent, newvalue, nameedge, pos) Elimina un nodo de tipo Element del grafo, su arco de entrada y todos sus descendientes Elimina un nodo dato o un atributo de un elemento Actualiza el valor de un vértice data Borrar elemento Borrar atributo Borrar contenido Actualizar atributo Actualizar contenido requieren del nombre del arco y el tipo de arco pues la identicación de los vértices data se realizará en base a su vértice element padre y al arco que los une. Como ya hemos comentado, antes de proceder al estudio exhaustivo de cada una de ellas, debemos determinar cuál es el proceso de creación de un grafo XML pues condicionará en gran medida cómo puede evolucionar y, además, las primitivas de cambio se apoyarán en él para su implementación. Este proceso consiste en enlazar los vértices del grafo mediante arcos desde el vértice raíz hacía los vértices descendientes y así sucesivamente. Este proceso requiere de operaciones elementales sobre el grafo XML que permitan su creación así como la adición o eliminación de la información contenida en él. Para llevar a cabo este proceso, hemos extendido las operaciones básicas de gestión o manipulación de un grafo (Crear Vértice, Crear Arco, Borrar Vértice y BorrarArco) para considerar las propiedades particulares de los vértices y arcos de un grafo XML. Estas operaciones elementales sobre un grafo XML se muestran de forma resumida en la tabla 4.3 y se comentan brevemente a continuación: Tabla 4.3: Operaciones Elementales sobre un Grafo XML Operación CreateVertex (G, type, value) DeleteVertexElement (G, idvertex) DeleteVertexData (G, idparent, nameedge, pos) CreateEdge (G, idparent, idchild, nameedge, typeedge, pos) DeleteEdge (G, idparent, nameedge, typeedge, pos) UpdateVertex (G, idparent, newvalue, nameedge, pos) Descripción Crea un nuevo vértice del tipo type con el valor value en el grafo Elimina el vértice de tipo element identicado por idvertex Elimina el vértice de tipo data identicado por (idparent, nameedge, pos) Añade un nuevo arco entre idparent e idchild con el nombre nameedge y tipo typeedge. Elimina el arco nameedge de tipo typeedge para el vértice idparent situado en la posición pos. Actualiza la propiedad value por newvalue enlazada por el arco nameedge al vértice idparent en la posición pos.

104 86 Capítulo 4. Modelo de Datos para Documentos XML CreateVertex (G, type, value): Crea un nuevo vértice en el grafo XML. Para el caso de un vértice element el tipo es siempre V element y el parámetro value representa el identicador del vértice, mientras que, para un vértice data estos parámetros establecen su dominio y su valor. DeleteVertexElement(G, idvertex): Elimina el vértice de tipo element identicado por idvertex. Esta operación no se puede aplicar a un vértice data pues su identicación se realiza en base a su vértice padre, como se ha expuesto en el apartado anterior. DeleteVertexData(G, idparent, nameedge, pos): Elimina el vértice de tipo data identicado por el arco (idparent, nameedge, pos) y también elimina dicho arco. Esta operación presupone que éste es el único arco en el que participa dicho nodo, es decir, que el vértice de tipo data no tiene como arcos de salida o entrada arcos referencia, si existieran deberían borrarse previamente con la operación DeleteEdge. CreateEdge(G, idparent, idchild, nameedge, typeedge, pos): Establece un nuevo arco entre los vértices idparent e idchild del grafo con nombre nameedge y tipo typeedge en la posición indicada por pos. Esta operación debe cumplir un conjunto de precondiciones que garanticen el modelo propuesto: el arco debe ser E E si los vértices origen y destino son element, que el arco debe ser E A, E R si el vértice origen es element y el destino data o que el valor pos de un arco E A debe ser 0. DeleteEdge(G, idparent, nameedge, typeedge, pos): Elimina el arco nameedge de tipo typeedge cuyo vértice origen es idparent situado en la posición pos. Nótese que en el caso de tratarse de un arco E A o E R el parámetro de posición es siempre 0 pues estos arcos carecen de ordenación y en otro caso especica la posición del arco a borrar. Nótese que no pueden existir dos arcos atributos o referencias procedente de un mismo vértice con el mismo nombre de arco. UpdateVertex(G, idparent, newvalue, nameedge, pos): Esta operación sólo es aplicable a los vértices data pues la propiedad value de los vértices Element constituye su identicación y es inmutable. La propiedad value de un vértice data unida por el arco nameedge al padre idparent en la posición pos cambia su valor por newvalue. El parámetro posición adquiere el valor 0 si se trata de un vértice data con un arco de entrada E A o E R (atributos y referencias no están ordenados). En el caso de un arco E E este valor determina cuál de los posibles arcos ~data se desea actualizar para contemplar de este modo el caso de elementos XML mixtos con más de un valor ~data. Nótese que estas primitivas elementales no se han usado como primitivas de cambio pues muchas de ellas no generan un grafo XML bien formado. Por ejemplo, para crear un elemento vacío se aplicará en primer lugar la función CreateVertex que provoca que el grafo resultante sea no conexo, pues el nuevo vértice creado no se enlaza a ningún otro vértice mediante un arco, y a continuación se ejecutará la operación CreateEdge que añade el arco que conecte el vértice creado con el vértice element padre, dejando nalmente el grafo XML bien formado. Por este motivo, estas operaciones elementales solamente se usarán para denir y formalizar las primitivas de cambios que se establecen a continuación. Además con el objetivo de poder distinguir claramente qué operación se está usando (operación

105 Cambios en un Grafo XML 87 elemental o primitiva de cambio), en las tablas 4.2 y 4.3 hemos utilizado una nomenclatura diferente. En el caso de referirnos a nivel de grafo se utiliza vertex y edge para especicar las operaciones elementales, mientras que si nos referimos a las primitivas de cambio en un grafo XML usaremos una nomenclatura basada en node, en cuyo caso solemos referirnos a operaciones que afectan a más de un componente del grafo. Notación de las operaciones Para denir las operaciones se especicarán su sintaxis, descripción, precondiciones y postcondiciones, donde: Sintaxis: Nombre_Operación(G, param i,..., param n ). Normalmente con esta descripción funcional se dene una operación que se aplicará sobre un determinado vértice del grafo XML G=(V,E,root), y los parámetros (param i,..., param n ) suelen ser valores necesarios para llevar a cabo la operación. Descripción: Dene el algoritmo o comportamiento de la operación. Precondiciones: Denen restricciones sobre el vértice y los arcos de entrada o sobre los parámetros que intervienen en la llamada a la función. Si se incumple alguna de estas restricciones la operación no puede ser llevada a cabo y no realizará ninguna operación sobre el grafo G. Postcondiciones: Normalmente se denen indicando el resultado de la función o bien un código de error indicando algún problema que haya impedido la correcta realización de la operación CrearGrafoXML Esta operación permite crear un grafo XML vacío. Denición 4.3. CreateXMLGraph(G). Crea un grafo XML vacío, G. En este caso, el grafo XML G estará formado sólo por el vértice root. Precondiciones: ˆ Ninguna especial. Postcondiciones: ˆ Devuelve el grafo XML: G=(V, E, root) con V ={root} y E= AñadirNodo Esta operación es la única que permite añadir nuevo contenido al grafo XML pues el resto de operaciones o bien lo modican o bien reducen su contenido. Denición 4.4. AddNode (G, type, newvalue, newedge, typeedge, idparent, pos). Añade al grafo XML G un nuevo vértice de tipo type con valor newvalue así como el arco de salida desde el idparent con el tipo typeedge y el nombre newedge en la posición indicada por pos.

106 88 Capítulo 4. Modelo de Datos para Documentos XML Precondiciones: ˆ El identicador del nodo padre idparent debe existir en el grafo, es decir, p V element /D(p) = idp arent ˆ El identicador del nuevo vértice a crear, newvalue, no debe estar siendo usado en el grafo como contenido de algún vértice V ID. En el caso de tratarse de un valor vacío el sistema genera un nuevo identicador mediante la función newid(g). ˆ El elemento se insertará tras el elemento que ocupa la posición indicada por el parámetro pos. En particular, si pos=0 el nuevo nodo se añadirá como primer descendiente del nodo padre idparent, y si pos=nº de hijos de tipo element de idparent entonces el nuevo nodo se añadirá como último descendiente del nodo padre idparent. Supondremos por tanto que pos debe tomar un valor en el rango [0..nº de hijos de tipo element de idparent ]. ˆ Si el tipo del arco es E A no puede existir un arco hermano con el mismo nombre p V element /p = IdP arent/! x outedges(p)/type(x) = E A name(x) = newedge ˆ Si el tipo del arco es E R no puede existir un arco hermano con el mismo nombre y además debe vericar que existe un vértice en el grafo XML cuya tipo sea V ID y su valor el mismo que la referencia. ˆ Si el tipo de arco es E E y el valor del nombre del arco es ~data, el arco antecesor y sucesor no puede ser ~data. p V element /p = IdP arent! x outedges(p)/name(x) = data. Postcondiciones: newvalue=newid(g) y CreateVertex(G, type, newvalue) + CreateEdge(G, idparent, newvalue, newedge, typeedge, pos) Observaciones: 1. En el caso de tratarse de un vértice atributo o referencia el valor de la posición es 0 pues en los arcos E A y E R no existen ningún tipo de ordenación. 2. Nótese que esta operación añade también el arco desde el vértice padre al nuevo vértice creado. 3. Para facilitar el proceso de creación de nuevos vértices de tipo elemento, usaremos la función auxiliar newid(g) que devuelve un valor de tipo ID no utilizado en el grafo XML G. Ejemplo: En la gura 4.2 se muestra un ejemplo después de la ejecución de dos primitivas AddNode donde la parte izquierda ilustra el grafo origen y la derecha el grafo XML resultante después de la operación. Por una parte, se ha añadido un nuevo vértice element al Grafo XML (AN(G, element, 7, street, E E, &3, 4)) denominado street en la posición 4 para el nodo padre identicado por &3 y, por otra, se ha añadido un vértice data para el vértice recién creado, &7, con valor París 10 (AN (G, string, París 10, ~data, E E, &7, 1)). A continuación se exponen las operaciones de borrado. Nótese que mientras que la operación de inserción es única y se puede indicar en los parámetros el tipo de nodo que se inserta, para el borrado se han debido denir dos funciones, una para el borrado de nodos de tipo elemento, que pueden ser referenciados sólo con su valor, y otra para el borrado de nodos de tipo dato, bien nodos datos descendientes de un elemento o datos correspondientes al valor asociado a un atributo.

107 Cambios en un Grafo XML BorrarNodoDato Figura 4.2: Insertar un Nodo en un Grafo XML Denición 4.5. DeleteDataNode (G, idparent, nameedge, pos). Elimina del grafo XML G el arco procedente desde el vértice identicado por idparent con el nombre nameedge en la posición pos junto con el vértice destino de dicho arco. Si el vértice destino es de tipo IDREF o IDREFS, también se borran los arcos referencia asociados. PreCondiciones: ˆ El identicador de vértice IdParent debe existir en el grafo: p V element /value(p) = idp arent ˆ Si nameedge ~data entonces pos=0 y nos referimos al borrado de un atributo con nombre de arco nameedge. ˆ Si nameedge = ~data entonces el vértice idparent debe tener un arco con nombre ~data situado en la posición pos. PostCondiciones: ˆ DeleteEdge(G, idparent, nameedge,pos) + DeleteVertex(G, child(idparent), nameedge, pos) ˆ Si el tipo de este nodo de datos es IDREF o IDREFS se borrarán todos los arcos de salida a los elementos que contienen el identicador en su atributo ID. ˆ Si el tipo de este nodo de datos es ID, se comprobará que no existe ninguna referencia a dicho valor antes de proceder a su borrado. En el caso de existir alguna referencia no se realizará la operación devolviendo un código de error. Observaciones: Esta operación permite el borrado de los vértices data de un grafo XML pues como se ha comentado anteriormente sólo se puede identicar un vértice data a partir del arco que le une a un vértice element, es decir, esta operación permite el borrado de atributos y contenido de un Grafo XML.

108 90 Capítulo 4. Modelo de Datos para Documentos XML Figura 4.3: Borrado de un Nodo Data en un Grafo XML En el caso de tratarse de un vértice de tipo V ID entonces se ha tomado la opción de realizar el borrado sólo si no existe ninguna referencia hacia él. Ejemplo: En la gura 4.3 se muestra un ejemplo de ejecución de la primitiva DeleteDataNode donde se elimina el contenido asociado al elemento name del Grafo XML BorrarNodoElemento Denición 4.6. DeleteElementNode (G, idvertex). Elimina del grafo XML G el vértice de tipo element identicado por idvertex, su arco de entrada y todos los vértices y arcos descendientes. PreCondiciones: ˆ El identicador idvertex debe existir en el grafo, es decir, p V element /value(p) = idv ertex ˆ Si el elemento idvertex es un vértice que entre sus descendientes tiene un vértice data con un valor asociado de tipo ID, entonces se comprobará que no existe ninguna referencia externa a dicho valor, en caso contrario este nodo no podrá borrarse. PostCondiciones: El vértice es borrado junto con todos sus descendientes. Observaciones: ˆ Sea e el arco de entrada a idvertex, entonces: DeleteElementNode (G, idvertex) = DeleteVertex (para todos los descendiente de idvertex) + DeleteEdge(G, parent(idvertex), e.name, Order(idVertex)) + DeleteVertex(G, idvertex) Esta operación solamente puede ser usada para el borrado de vértices element pues son los únicos vértices que poseen identicación. En el caso de incluir los arcos referencias, esta operación es extremadamente delicada pues se debe contemplar la situación en la cual haya algún descendiente que sea un elemento V ID, existiendo las siguientes posibilidades: ˆ Permitir la operación de borrado del elemento V ID sin realizar ninguna comprobación, pudiendo quedar inconsistente el grafo XML.

109 Cambios en un Grafo XML 91 ˆ Realizar la actualización en cascada. Esta opción asegura no dejar estados inconsistentes del grafo aunque es más compleja y no permite realizar ningún control al usuario. ˆ No permitir la actualización si existen referencias al vértice, y para ello se dispone de una operación auxiliar que detecte los vértices con referencias al V ID a actualizar (sólo se realizará la actualización si no hay referencias al vértice). Esta es la opción que se ha decidido tomar, y que se especica en la segunda precondición y exige que el usuario realice un control exacto de las referencias existentes hacia el vértice V ID que se desea borrar. Ejemplo (DEN(G, &5)): En la gura 4.4 se muestra la ejecución de una primitiva DeleteElementNode. En este caso no solamente el vértice con el identicador &5 es borrado sino además todos sus descendientes, es decir, el vértice Spanish y el arco ~data. Figura 4.4: Borrado de un Nodo en un Grafo XML ActualizarNodoDato Denición 4.7. UpdateDataNode (G, idparent, newvalue, nameedge, pos) Actualiza en el grafo XML G el valor del vértice data identicado por el arco nameedge situado en la posición pos para el vértice idparent por el valor newvalue. Si el nodo data es de tipo ID, entonces no podrá realizarse la operación si existen referencias hacia él de tipo IDREF o IDREFS; y si no existen deberán crearse los arcos referencia correspondientes para el nuevo valor de tipo ID. PreCondiciones: ˆ El identicador del nodo padre debe existir en el grafo, esto es: p V element /value(p) = idp arent ˆ Si pos 0, entonces nameedge = ~data y el vértice padre idparent debe tener un arco de salida etiquetado como ~data en la posición pos. ˆ Si pos = 0, entonces el vértice padre idparent debe tener un arco de salida de tipo Atributo etiquetado como nameedge. ˆ Si el nodo es de tipo ID: 1) no debe existir ninguna referencia hacia este nodo y 2) el nuevo valor debe ser un valor de ID válido, es decir, no debe existir otro igual en el grafo XML.

110 92 Capítulo 4. Modelo de Datos para Documentos XML ˆ Si el nodo es de tipo IDREF o IDREFS, los nuevos valores deben ser válidos, es decir, deben existir vértices de datos de tipo ID con esos valores y, además, 1) se borrarán los arcos de tipo ref para los valores antiguos y 2) se insertarán los nuevos arcos de tipo ref para los nuevos valores del nodo. PostCondiciones: El valor de vértice se actualiza por el nuevo valor. Observaciones: Esta operación permite actualizar no solamente los vértices data para el arco E E sino también para los arcos E A y E R. Si se realiza sobre un vértice V ID existen los mismos casos que para el borrado de un vértice, no permitiendo la actualización si existe algún arco referencia a dicho vértice. Como se indica en la denición, en el caso de la actualización de un vértice V IDREF o V IDREF S se debe vericar la existencia de los nuevos valores como referencias a nodos V ID. Ejemplo UDN(G, &6, 18, ~data, 1): En la gura 4.5 se muestra el resultado de ejecutar una operación de actualización de nodo data. En este caso el vértice data con valor 15 ha cambiado su valor por 18. Figura 4.5: Actualización de un Vértice en un Grafo XML 4.3. Representación de un Grafo XML en un Documento XML En los apartados anteriores hemos presentado un modelo de datos para grafos XML analizando sus principales primitivas de cambio. En esta sección expondremos los algoritmos de conversión de un grafo XML en un documento XML y viceversa. Como veremos en la próxima sección estos algoritmos permitirán establecer una identicación de la clase de documentos XML con los grafos XML, de forma que cualquier documento XML se puede expresar como un grafo XML y con ello podremos considerar el álgebra de primitivas de cambio inducida sobre los documentos XML. Con esta biyección entre ambas representaciones podremos operar indistintamente en cualquiera de ellas.

111 Representación de un Grafo XML en un Documento XML Conversión de un grafo XML en un Documento XML El algoritmo 4.1 permite realizar la conversión de un grafo XML G a documento XML D y está diseñado bajo los siguientes principios: La raíz del grafo XML, es decir el vértice root de G, junto con su único arco de salida representan el elemento raíz del documento XML. Nótese que solamente puede existir un nodo raíz para un documento XML como establece la especicación del W3C sobre XML [Bray 98]. El elemento raíz es el primer elemento de un documento XML, del cual todos descienden, y se representa con el formato <nombre_etiqueta> y </nombre_etiqueta> respectivamente, donde nombre_etiqueta es el valor de la etiqueta que une el vértice root con el primer vértice del grafo XML. Todo vértice element del grafo XML, distinto de root, representa un elemento XML, donde el valor de su etiqueta se corresponde con el nombre del arco de entrada a dicho vértice. Todo arco de salida de este vértice hacía un vértice Element (solamente accesible mediante un arco E E ) establece el anidamiento existente entre elementos y subelementos XML donde el orden del elemento hijo se determina en base a la función Order. Todo vértice data representa un valor en el documento XML que puede ser el contenido asociado a un elemento XML, el valor de un atributo o el valor de un atributo referencia dependiendo del arco de entrada al vértice data. ˆ Si el arco de entrada es E E y el nombre del arco es ~data, el valor del vértice representa el contenido asociado a un elemento XML. El contenido de un elemento XML se sitúa entre la apertura y cierre de la etiqueta. ˆ Todo arco atributo del grafo XML establece su análogo en XML, es decir, representa un atributo XML asociado a un elemento donde el nombre del atributo es el nombre del arco de entrada al vértice de tipo data y su valor se corresponde con el valor de dicho vértice. Los atributos XML se representan mediante un nombre y un valor encerrado entre comillas después del valor de la etiqueta de apertura del elemento. ˆ Como expusimos anteriormente, si se modelan los arcos referencia en un documento XML sólo se puede establecer esta característica, sin usar un documento esquema, mediante convenio que establezca una semántica especial a los atributos o contenidos que sean de tipo ID, IDREF o IDREFS. Por ejemplo podría ser mediante la incorporación de un carácter especial que reeje este hecho, de este modo, en el caso de querer representar un arco referencia en el documento XML, éste se establecería añadiéndole al nombre de la etiqueta el carácter #. Bajo las consideraciones anteriores, podemos denir un proceso de conversión de un grafo XML en un documento XML según se muestra en el algoritmo 4.1. Se trata de un algoritmo recursivo que recibe como entrada el grafo XML y genera como salida el documento XML resultante. Supondremos la existencia de unas funciones (CreateOpenTag, createattribute y CreateCloseTag) que se encargan de proporcionar la salida en formato XML. En este algoritmo también supondremos que todo elemento XML creado tiene un atributo identicador denominado idf que se corresponde con el valor identicador de los vértices element. Tal y como se expone en el siguiente apartado esta propiedad nos sirve para la identicación de los elementos de un documento XML.

112 94 Capítulo 4. Modelo de Datos para Documentos XML Algoritmo 4.1 Conversión de un Grafo XML a un Documento XML Graph2XML (G, D) //input: G: Grafo XML //output: D: Documento XML //Complejidad: El algoritmo es de orden O(n), siendo n el número de vértices que denen el grafo XML de entrada //Observación: Ningún vértice element puede tener un arco atributo idf 1. begin 2. if outedge(g.root)=ø 3. then return(); 4. else 5. e=outedge(g.root); // Este valor es único por denición de grafo XML 6. GenerateXML(G, e.v2, D); 7. end_if; 8. end; GenerateXML(G, v, D) //input: G: Grafo XML //input: v: Vértice de E E en el Grafo XML G //output: D: Documento XML 9. begin 10. OpenTagCreate(D, inedge(v).name); //Etiqueta de apertura <NomEtiqueta 11. createattribute (D, idf, value(v)) //Atributo idf si no está denido para v 12. for each e in (outedges(v) E A ) do { //Generación de atributos para elemento v 13. createattribute(d, e.name,value(e.v2)); 14. end_for; 15. OpenTagClose(D); //Cierra etiqueta de apertura (>) 16. for i=1 to card((outedges(v) E E )) do { //Elementos descendientes de v en orden 17. e i = O(i, (outedges(v) E E )); 18. if e i.name=~data 19. then write(d, value(e i.v2)); 20. else GenerateXML(G, e i.v2, D); 21. end_if; 22. end_for; 23. CloseTag(D, inedge(v).name); //Etiqueta de cierre 24. end; El algoritmo comienza comprobando que el grafo XML de entrada no está vacío para a continuación realizar el proceso de creación del documento XML a partir del vértice enlazado por el arco con origen root (elemento raíz del documento XML de salida). El proceso de creación que realiza la función recursiva GenerateXML consiste en los siguientes pasos: 1) generación de la etiqueta de apertura del elemento XML junto con sus atributos (línea 10 15), 2) Procesamiento de los arcos de salida para el vértice de entrada (linea 16-22) y 3) Generación de la etiqueta de cierre del documento XML (linea 23). Nótese que el cierre de las etiquetas de un determinado elemento XML se produce cuando se han procesado todos los descendientes de este vértice, estableciendo de este modo el correcto anidamiento de todas etiquetas con respectos a sus descendientes.

113 Representación de un Grafo XML en un Documento XML 95 Figura 4.6: Grafo XML y su Representación en formato XML La gura 4.6 muestra el grafo XML expuesto en la gura 4.1 junto con su representación XML. En ella, comprobamos la existencia de un arco que une el vértice root y el vértice &1 que constituye el elemento raíz del documento XML (doc). Este elemento raíz se encuentra formado por dos elementos hijos (arcos E E ) etiquetados como cook y rest respectivamente. El primero de ellos, cook, contiene únicamente atributos (arcos E A entre un vértice element y un vértice data) mientras que el segundo se encuentra constituido por dos atributos y tres elementos XML descendientes. Finalmente comprobamos que los vértices data unidos por un arco ~data constituyen el contenido asociado a un elemento XML tal y como sucede entre los vértices &4 y Seafood o lo que es lo mismo <name>seafood</name> Conversión de un Documento XML en un Grafo XML El algoritmo 4.2 permite realizar la conversión de un documento XML D a un grafo XML G y está diseñado bajo los siguientes principios: El elemento raíz del documento XML constituye el vértice, junto con su arco de entrada, enlazado al vértice root del grafo XML. El valor de este arco, de tipo E E, se corresponde con el valor de la etiqueta de dicho elemento y el vértice creado tiene como identicación el valor del atributo idf. Todo elemento del documento XML, distinto de la raíz, representa un vértice en el grafo XML donde su arco de entrada es el valor del nombre de la etiqueta de dicho elemento y el valor de identicación del vértice creado es el atributo idf. El contenido asociado a un elemento XML tiene su equivalencia con un vértice data donde su valor es el valor del contenido y el arco de entrada, de tipo E E, esta etiquetado con el nombre ~data. Todo atributo de un elemento XML, distinto a idf, se representa mediante un vértice ~data con un arco de entrada E A donde el nombre del arco es el nombre del atributo y su valor es el valor del vértice. Bajo estas consideraciones, podemos denir un proceso de conversión de un documento XML en un grafo XML según se muestra en el algoritmo 4.2 donde el algoritmo resultante,

114 96 Capítulo 4. Modelo de Datos para Documentos XML Algoritmo 4.2 Conversión de un documento XML a grafo XML XML2Graph (D, G) //input: D: Documento XML de entrada representado en DOM //output: G: Grafo XML de salida //Complejidad: El algoritmo es de orden O(n), siendo n el número de elementos y atributos que aparecen en el documento XML de entrada 1. begin 2. createxmlgraph(g) //Crea un grafo vacío en G 3. if D=Ø then return(); 4. else 5. Node n = D/self::node() // Raiz del documento 6. GenerateGraph(D, n, G, root) 7. end_if; 8. return(); 9. end; GenerateGraph(D, n, G, v) //input D: Documento XML //input n: Apuntador en el árbol DOM a un nodo XML de tipo elemento //output G: Grafo XML //output v: Identicador del vértice de tipo elemento del grafo XML a partir del cuál se va a insertar como descendiente el elemento n 10. begin 11. AddNode(G, Element, n/@idf, name(n), E E, v, pos(n)) //Crea vértice 12. for each e in n/child::@* do { //Procesa los atributos 13. AddNode(G, string, value(e), name(e), E A, n/@idf, 0) 14. end_for; 15. for each e in n/child::* do { //Procesa elementos y contenidos 16. if e.element_node then //Si es elemento 17. GenerateGraph(D, e, G, n/@idf) //Llamada Recursiva 18. end_if; 19. if e.text_node then //Si es contenido 20. AddNode(G, string, value(e), ~data, E E, n/@idf, pos(e)) 21. end_if; 22. end_for; 23. end; al igual que en el caso anterior, es recursivo. Tiene como entrada el documento XML en su representación DOM y como salida el grafo XML equivalente. Supondremos que en el documento XML de entrada todos los elementos XML tienen un atributo idf ; en caso contrario, se puede obtener un documento XML equivalente al inicial que tenga un atributo idf con identicadores únicos de tipo ID, simplemente realizando un recorrido del documento XML y añadiendo a cada nodo el atributo idf asignándole un valor de identicación único generado mediante la función newid(g). Hemos utilizado la notación XPath en el algoritmo para el tratamiento de los distintos componentes de un documento XML. Analicemos el proceso de conversión del documento XML de la gura 4.6 a su representación en un grafo XML usando este algoritmo. En primer lugar se procede a la creación del

115 Modelización de Documentos XML mediante Grafos XML 97 grafo XML (línea 2) que genera un grafo XML vacío con el vértice root, para a continuación, si el documento XML no esta vacío, enlazar la raíz del documento XML (doc) a este vértice root (linea 11) mediante el uso de la operación AddNode. Esta operación AddNode crea un nuevo vértice de tipo element, cuya propiedad value es la identicación del vértice (atributo idf ), así como el arco de salida que une el vértice root con la raíz del documento. Una vez que se ha creado el vértice se procesan los atributos (línea 12) y los elementos descendientes (línea 15). En el primer caso únicamente es necesario la creación mediante la operación AddNode de estos atributos (con los parámetros oportunos) y en el segundo caso dependiendo si el nodo descendiente a procesar es un elemento o es un contenido se procede a la llamada recursiva o a la generación del texto respectivamente. Al igual que en el caso anterior en la gura 4.6 se muestra el documento XML junto con su representación en Grafo XML Modelización de Documentos XML mediante Grafos XML El algoritmo Graph2XML genera, a partir de un grafo XML, un documento XML que lleva identicado cada elemento por un atributo de tipo ID, y que hemos denominado idf. Este atributo permite conservar los identicadores de nodos de tipo elemento del grafo, y por tanto es inmediato deducir que el algoritmo de transformación inverso XML2Graph estudiado permitirá obtener el grafo XML inicial a partir del documento XML generado. En general, podemos pensar que cualquier documento XML se puede transformar en un documento equivalente que tenga un atributo idf de tipo ID para cada elemento, de forma que bastaría eliminar dicho atributo idf de cada elemento para obtener el documento XML inicial. Aplicando el algoritmo XML2Graph al documento XML con atributos idf, podemos obtener el grafo XML asociado, el cual tiene como identicadores para los vértices element los valores del atributo idf. Por tanto podemos establecer una biyección entre los grafos XML y los documentos XML equivalentes, de forma que el álgebra de primitivas se puede aplicar tanto a los grafos XML como a su representación en un documento XML equivalente. Como este álgebra realiza las operaciones básicas de gestión de elementos, atributos y contenidos que permiten denir un documento XML, podremos trabajar indistintamente con ambas representaciones para gestionar los documentos XML. En el capítulo 5 se estudiará cómo diferentes versiones de un grafo XML se pueden integrar en un único grafo, que denominaremos Grafo vxml y, por tanto, que también se podrán representar y gestionar en XML. Todos estos resultados nos van a proporcionar un modelo formal que nos permitirá especicar la gestión de versionado independientemente de la representación utilizada, tal y como veremos en el capítulo 6, donde este modelo cumplirá las premisas especicadas en nuestro modelo general de versionado dado en el capítulo 3. El hecho de que los GrafovXML se puedan representar y gestionar en vxml será explotado en el resto de la tesis para implementar un sistema de gestión de versionado XML sobre dichos cheros vxml. Para formalizar estas ideas, a continuación se expresa la identicación de los objetos en ambos modelos, grafos XML y documentos XML, y después se identican las operaciones que permiten expresar las diferentes versiones de cualquier grafo o documento XML Identicación de Grafos XML y Documentos XML De acuerdo con todo lo anterior podemos establecer los siguientes resultados:

116 98 Capítulo 4. Modelo de Datos para Documentos XML Figura 4.7: Identicación de las clases y Γ(G) Proposición 4.1. Si denominamos como a la clase de todos los documentos XML, entonces cualquier documento X se puede representar en otro documento equivalente D que contiene en todos sus elementos un nuevo atributo de tipo ID no usado en ningún elemento de X y que denominaremos idf. Si denominamos Γ( ) a la clase de todos los documentos XML que poseen un atributo de tipo ID para todos los elementos del documento, entonces podemos establecer una biyección entre y Γ( ) mediante la función idf(x), tal que: X, idf(x )=D Γ( ) / idf 1 (D)=X Demostración. Para denir la función idf podemos considerar la función auxiliar newid(a) que devuelve, para cualquier vértice A que no posea el atributo asociado idf, un valor de tipo ID no utilizado en el documento A. Entonces basta recorrer el documento X y añadir a cada elemento el atributo idf con valor generado por la función newid( X) para obtener idf(x )=. Es inmediato que realizando la operación de ltrado de dicho atributo al documento generado D=idf(X ), se obtiene el documento XML inicial X. Llamaremos a esa función idf -1 (D)=X. Proposición 4.2. Si denimos como Γ(G) a la clase de todos los grafos XML, entonces se puede establecer una biyección entre la clase de todos los documentos XML y Γ(G). Demostración. Los algoritmos anteriores XML2Graph y Graph2XML permiten denir una biyección entre las clases Γ( ) y Γ(G). Basta componer con la biyección idf entre y Γ( ) para obtener la biyección entre y Γ(G). En la gura 4.7 se muestran grácamente los anteriores resultados, indicando cómo a partir de un grafo XML se puede obtener el documento XML con identicadores equivalente y viceversa.

117 Modelización de Documentos XML mediante Grafos XML Cambios en Documentos XML Tal y como se ha expuesto a lo largo de los apartados anteriores, un grafo XML, y por consiguiente un documento XML, no es estático sino que su contenido y/o estructura varía a lo largo del tiempo. En este apartado, y una vez que se ha analizado cómo evolucionan los grafos XML, se estudian las operaciones de cambio que se pueden producir en un documento XML. Igual que en el caso anterior, antes de denir estas primitivas, examinaremos varios factores que se han tenido en cuenta. En primer lugar hay que determinar cuáles de los componentes de un documento XML (elementos, atributos, contenido, comentarios, prólogo, instrucciones de procesamiento, etc) son los susceptibles de cambio en nuestro sistema para así poder establecer qué operaciones se pueden realizar sobre ellos. A partir del modelo de datos XML propuesto en la sección anterior, hemos decidido abordar en esta tesis la gestión de cambios para elementos, atributos y contenidos pues constituyen el eje principal de un documento XML. A continuación y una vez analizados los componentes XML susceptibles de cambio, el siguiente paso es determinar qué primitivas de cambio se van a abordar. En este sentido, debemos tener en cuenta que las primitivas seleccionadas deben garantizar su correspondencia con las primitivas de un grafo XML, así como las propiedades descritas anteriormente (completas, mínimas y bien formadas). Así, hemos determinado que las primitivas básicas de cambio sobre un documento XML son las mostradas en la tabla 4.4. En esta tabla, se presentan las operaciones de cambios con una breve descripción y su operación equivalente en un grafo XML. Tabla 4.4: Primitivas de Cambio de un Documento XML y su correspondencia con Grafo XML Operación Signicado Grafo XML (CX) CreateXML(X) (IE) InsertElement(X, nidf, name, idf, pos) (DE) DeleteElement(X, idf) (IA) InsertAttribute (X, idf, name, value) (DA) DeleteAttribute (X, idf, name) (UA) UpdateAttribute (X, idf, name, n_value) (IC) InsertContent (X, idf, pos, data) (DC) DeleteContent (X, idf, pos) (UC) UpdateContent (X, idf, pos, new_data) Crea un documento XML vacío, sin ningún elemento raíz en el documento. Añade un nuevo elemento con el nombre name y valor de idf igual a nidf para el elemento padre CreateXMLGraph(G) AN (G, element, nidf, name, E E, idf, pos) idf en la posición pos. Elimina el elemento identicado por idf junto DEN (G, idf) con todos sus descendientes. Añade un nuevo atributo al elemento idf con AN (G, string, value, valor value y nombre name. name, E A, idf, 0) Elimina el atributo name del elemento idf. DDN (G, idf, name, 0) Cambia el valor del atributo name del elemento idf por el valor n_value. Añade el contenido especicado en data para el elemento idf. Elimina el contenido del elemento idf. Cambia el valor del contenido descendiente en la posición pos del elemento idf por new_data. UDN (G idf, n_value, name, 0) AN (G, string, data, ~data, E E, idf, pos) DDN (G, idf, ~data, pos) UDN (G, idf, new_data, ~data, pos)

118 100 Capítulo 4. Modelo de Datos para Documentos XML Observaciones a la tabla 4.4: Todas las deniciones de las primitivas de cambio para documentos XML se pueden deducir de las deniciones de las respectivas operaciones para el grafo XML, incluyendo las correspondientes precondiciones y postcondiciones. Igual que denimos la funcion newid(g), podemos denir la función newid(d) para obtener un nuevo valor de idf no usado en el documento XML D. Nótese que IE() no añade ningún contenido (PCDATA) al elemento creado. Para añadir un elemento junto con su contenido a un documento XML es necesario realizar una composición de primitivas de la forma IE + IC (insertar el elemento e insertar el contenido en el elemento recién creado). La operación (DE), al igual que se ha discutido para los grafos, se ha considerado de forma general como borrado del elemento y todos sus descendientes, pero debería haberse denido de forma más elemental como: DeleteEmptyElement() que sólo elimina el elemento cuando es sólo un elemento vacío (sin atributos, ni descendientes elementos o datos). En ese caso se tendría: DE(X, idf) = Σ DE(X, idf, pos) + DEE(X, idf) DN(G, idf) pos ord(idf) Σ a Attr(idf) DA(X, idf, a) + Sobre las operaciones (DA) y (UA). Nótese que para los atributos, o bien se borra el atributo (y su valor asociado) usando (DA), o como mucho sólo podemos actualizar el valor del atributo (UA). Nótese que no es necesario añadir operaciones de inserción/borrado/modicación de valores ID, IDREF o IDREFS pues para el caso de un documento XML lo que se necesita en estas situaciones son vericaciones semánticas si se conoce el tipo de estos datos, y en el caso de un grafo XML lo que se necesita es el mantenimiento de los arcos referencias correspondientes. Como hemos mencionado anteriormente, hemos considerado que los elementos XML en nuestros documentos tienen un atributo idf que los identica, exceptuando los atributos y contenido, que se identican a través del elemento XML que los contiene. En [Cobena 02] se analizan diversas técnicas para identicar un elemento XML, que se basan en añadir un atributo a cada elemento XML donde éste puede ser o un valor auto-incremental [Xyleme 01] en el documento o un valor obtenido por el recorrido transversal al nodo en cuestión (muy usado en la indexación de documentos XML)[Chien 01d, Exist. 01]. En nuestro caso, como ya hemos mencionado, hemos optado por la primera solución por la facilidad de su implementación y además porque la segunda solución requiere, en muchos casos, la actualización de los identicadores cuando se cambia la estructura del documento (algunas trabajos recientes evitan ya este problema [Chien 01b]). Cuando sobre un grafo XML o un documento XML se realizan cambios, la nueva versión no necesariamente se genera en base a la ejecución de una única primitiva sino que puede hacerse a partir de un conjunto de ellas; a esto se le denomina composición de primitivas. Este conjunto de primitivas se caracteriza por la ejecución secuencial de las operaciones a realizar, de modo que, la aplicación de una primitiva depende de las operaciones anteriormente realizadas. El sistema gestor de versiones debe disponer de un gestor de primitivas que garantice que no existen contradiciones en la secuencia de cambio.

119 Conclusiones 101 Figura 4.8: Composición de Primitivas en un Documento XML En la gura 4.8 se muestran varios ejemplos de aplicación de estas primitivas. Éste comienza mediante la creación del documento XML inicial, versión V 0, sobre el cual se realizan diversas operaciones de cambio. En primer lugar se genera, mediante estas primitivas, el documento XML de ejemplo seguido en este capítulo y a partir de ahí se producen una serie de cambios. Así por ejemplo desde la versión V 1 del documento a la versión V 2 se han realizado las siguientes operaciones: se ha añadido un nuevo elemento XML para el elemento rest en la posición 4 con valor de identicación 8, se ha actualizado el valor del atributo id del elemento rest, se ha actualizado el valor del contenido del elemento price y se ha añadido un atributo al elemento street creado anteriormente Conclusiones En este capítulo se ha presentado un modelo de datos para documentos XML así como las operaciones básicas de cambio sobre este tipo de documentos. Nuestra propuesta es un modelo de datos para documentos XML [W3C 94, Bray 98] de- nida en base a un grafo dirigido acíclico con un único nodo raíz, que hemos denominado Grafo XML. Este grafo está formado por distintos tipos de vértices y de arcos que permiten representar los diferentes componentes que forman un documento XML. Además hemos analizado cuales son las operaciones básicas de cambio sobre este modelo de datos. Éstas se caracterizan por tres propiedades: por ser completas, mínimas y bien formadas; es decir, que cualquier operación de cambio sobre un grafo XML se puede denir en base a las operaciones denidas, que cada primitiva no se puede llevar a cabo mediante el resto de primitivas o mediante primitivas más sencillas y que el grafo XML resultante se encuentra bien formado tras sus ejecuciones. En la tabla 4.5 se muestra la taxonomía de cambio tanto para un grafo XML como para un documento XML junto con una breve descripción. En el caso de un documento XML, en el nombre de la primitiva se ha añadido entre paréntesis su operación equivalente en un grafo XML. Una vez analizado el modelo de datos XML y sus operaciones de cambio, en el siguiente

120 102 Capítulo 4. Modelo de Datos para Documentos XML Tabla 4.5: Primitivas de Cambio en un Grafo XML y en Documento XML Operación (CG) CreateXMLGraph (AN) AddNode (DEN) DeleteElementNode (UDN) Update DataNode (DDN) DeleteDataNode Primitivas de Cambio en un Grafo XML Signicado Crea un grafo XML vacío Añade un nuevo vértice junto con su arco de entrada Elimina un vértice Element del grafo, su arco de entrada y todos sus descendientes Actualiza el valor de un vértice data Elimina un vértice data junto con su arco de entrada Primitivas de Cambio en un documento XML Operación Signicado CX(CG) CreateXML IE (AN) InsertElement DE (DEN) DeleteElement IA (AN) InsertAttribute DA (DDN) DeleteAttribute UA (UDN) UpdateAttribute IC (AN) InsertContent DC (DDN) DeleteContent UC (UDN) UpdateContent Crea un documento XML Añade un nuevo elemento XML Elimina un elemento XML identicado junto con todos sus descendientes. Añade un nuevo atributo a un elemento XML Elimina un atributo asociado a un elemento Cambia el valor de un atributo Añade contenido a un elemento XML Elimina el contenido asociado a un elemento Actualiza el valor del contenido asociado a un elemento capítulo se procederá al estudio de cómo representar distintos estados o versiones de un grafo/documento XML, que se habrán generado mediante las primitivas anteriores. A este nuevo modelo de datos lo hemos denominado Grafo vxml.

121 Capítulo 5 Grafos vxml y Documentos vxml Contenidos 5.1. Introducción a la Integración de Versiones Grafos vxml Árbol de Versionado Marcado de Versión: VersionStamp Grafo vxml Representación de un Grafo vxml en un Documento XML: Documentos vxml Árbol de versionado Marcado con Región de Versionado Recuperación de Versiones Recuperación de Versiones (Grafos XML) a partir de un Grafo vxml Optimización en la Recuperación de Versiones (Grafos XML) a partir de un Grafo vxml Recuperación de Versiones (Documentos XML) a partir de un Documento vxml Conclusiones En el capítulo anterior se denió un modelo de datos para documentos XML y sus operaciones de cambio que, aplicadas sobre dichos documentos, pueden generar sus distintos estados o versiones. El presente capítulo introduce un nuevo modelo de datos, vxml, que permite la representación y gestión de distintas versiones de un grafo XML en un marco de versionado ramicado. Más concretamente, en este capítulo trataremos el aspecto de cómo representar los distintos estados dentro de un mismo grafo XML (grafo vxml) y posteriormente, en el capítulo 6, se abordará cómo realizar su gestión. En la sección 5.1 se analizan distintas soluciones para gestionar los diferentes estados o versiones de un grafo XML. Entre todas ellas, y puesto que los distintos estados de un mismo documento suelen contener una gran cantidad de información común, analizaremos en profundidad la técnica de integración de versiones con el objetivo de reaprovechar los contenidos comunes y evitar la replicación de la información. Para ello se propone un mecanismo de almacenamiento que integra, en un mismo grafo XML, todos sus estados o versiones y una técnica

122 104 Capítulo 5. Grafos vxml y Documentos vxml denominada versionstamp o marca de versión que permite identicar fácilmente cada uno de estos estados en el grafo. Esta técnica se fundamenta en dos ideas: añadir en el propio grafo XML información de cómo ha ido evolucionando a lo largo del tiempo, es decir, representar la derivación entre las versiones almacenadas en el grafo (árbol de versionado) e indicar en cada arco del grafo las versiones del árbol de versionado en que dicho arco es válido (validez de versionado). Este nuevo modelo de datos lo hemos denominado Grafo vxml y será formalizado en la sección 5.2. En la sección 5.3 se muestra el proceso de conversión de un Grafo vxml a un documento XML con versiones o documento vxml, es decir, cómo representar en un documento XML distintas versiones. Este proceso consiste en adaptar el árbol de versionado y la validez de versionado asociada a cada arco a una representación XML bien formada. El árbol de versionado se ha modelado fácilmente mediante un fragmento o subdocumento XML donde la derivación de las versiones se establece en base al anidamiento de sus etiquetas. En cuanto a la validez de versionado, ésta se ha denido en función de dos atributos XML (v:start y v:end) asociados a cada elemento XML, que hacen referencia al árbol de versionado almacenado en el documento XML. En la sección 5.4 se analiza la operación fundamental de todo sistema de versionado, el recuperar aquellos elementos, atributos y contenidos válidos para una determinada versión (instantánea o snapshot de un documento). En primer lugar mostraremos un proceso de recuperación de información válida que pudiera denominarse como el más lógico y posteriormente propondremos una optimización que resuelva el problema de ineciencia del proceso anterior Introducción a la Integración de Versiones La información actual representada en un grafo XML constituye lo que se denomina estado de un grafo XML, el cual evoluciona a lo largo del tiempo debido a operaciones realizadas sobre sus vértices y sus arcos. De este modo el nuevo estado del grafo XML se crea a partir de las modicaciones, primitivas de cambio, realizadas sobre el grafo en un estado anterior, comenzando por una versión inicial, normalmente conocida como V 0. Obviamente a un nuevo estado no se llega exclusivamente por la ejecución de una única primitiva sino a partir de un conjunto de ellas. En un sistema de gestión de versiones debe existir algún mecanismo que permita representar la historia de sus objetos, en nuestro caso la historia de los arcos y vértices de un grafo XML, para así poder consultar, además de la información actual, la información pretérita. En este capítulo analizaremos cómo representar las distintas versiones de un grafo XML. Para gestionar estas versiones se pueden utilizar diversas técnicas tal y como expusimos en el capítulo 2. Las primeras técnicas que aparecieron para la gestión de versiones de documentos XML asumieron que no era recomendable almacenar todas las versiones en un único documento, principalmente por motivos de capacidad [Nørvåg 04]. Así, la primera solución fundada adoptada por los investigadores de este campo consistió en almacenar esta historia en función de los cambios que se habían producido entre dos versiones de un mismo documento, lo que se conoció como Delta XML [Su 01, Chien 01a, Chien 01d, Chien 01c, Cobena 02]. Esta técnica actualmente en uso tiene la desventaja de precisar un excesivo coste computacional y de acceso a disco para recuperar una versión distinta de la actual, tal y como se expone en [Nørvåg 04], pues es necesario reconstruir cada una de las versiones hasta la versión solicitada. En este

123 Introducción a la Integración de Versiones 105 mismo trabajo, Norvag arma que en la actualidad el hecho de almacenar todas las versiones en un único documento no repercute en espacio y tiempo tanto como antiguamente debido principalmente al aumento de la capacidad de los dispositivos (reduciendo el coste/bit de los dispositivos) y al aumento de su velocidad. Además también muestra que, en algunos casos, la diferencia en tamaño entre una versión completa de un documento y la versión delta es mínima: por ejemplo, si el cambio realizado afecta a una gran parte del documento (renombrado del nodo raíz). Por este motivo, en los últimos años, los investigadores han centrado su esfuerzo en buscar técnicas que integren en un mismo documento todas las versiones de un grafo o documento XML. Debemos tener presente que los documentos asociados a las diferentes versiones suelen contener gran cantidad de información común, lo que plantea la posibilidad de fundir el almacenamiento de todos los documentos o versiones reaprovechando los contenidos comunes a varias versiones del documento. Con este planteamiento, cuando se produce una nueva versión de un grafo XML a partir de las primitivas descritas en el capítulo anterior, los nuevos vértices y arcos son integrados con las versiones anteriores en un mismo grafo XML. Esta situación conduce a tener que especicar, para cada uno de los arcos o vértices del grafo, a qué estado, o estados, de todos los representados en el grafo pertenece, lo que se conoce como validez. El benecio de mantener la información de todos los documentos en uno único, no es sólo por razones de almacenamiento, sino que también nos permitirá optimizar el procesamiento de consultas sobre cada elemento respecto de las versiones en las que aparece. En nuestro caso la consulta se realizará sobre un único documento en lugar de tener que aplicarla de forma individual a los documentos asociados a todas las versiones. La solución actual más relevante basada en este planteamiento, integración de versiones, se centra en el uso de aspectos de bases de datos temporales [Snodgrass 95, Zaniolo 97] de modo que, utilizando instantes, intervalos o elementos temporales, se establece el periodo de tiempo en el cual un determinado vértice o arco es válido [Zhang 02, Wang 04a, Rizzolo 08]. Tal y como se expuso en el capítulo 2, estado del arte, la solución temporal imposibilita la gestión de versiones no-lineales. Para dar solución a este problema, en este tesis se proporciona una visión completamente distinta a las soluciones temporales, que consiste en representar la evolución de la información del grafo XML producida por los cambios. A continuación, procedemos a explicar esta nueva técnica. Comenzaremos mostrando un ejemplo (gura 5.1), usado como ejemplo base en el resto del capítulo, y que servirá para introducirnos en la materia. Hemos tomado como punto de partida el grafo XML del capítulo anterior sobre cocineros y restaurantes (gura 4.1) sobre el que se han generado múltiples estados o versiones; dicho grafo está representado en la parte inferior izquierda de la gura 5.1 y corresponde a la versión v1. Para claricar la gura, la transición a una nueva versión la representamos con un arco etiquetado con las operaciones que se aplican al grafo XML y junto al nodo de la versión que se obtiene se han representado los arcos que se añaden al grafo. Observando dicha gura, se puede comprobar que nos encontramos ante una evolución del grafo no-lineal o ramicada, pues se ha podido actualizar cualquier versión del mismo. Por ejemplo desde la versión V 2 se han realizado tres versiones alternativas: V 3, V 5 y V 6. Consideramos que esta posibilidad de representar versionado ramicado es fundamental en cualquier sistema de versionado que se precie pues, en muchas ocasiones, no se requiere recuperar la versión actual para su modicación sino que se decide descartarla y regresar a una anterior

124 106 Capítulo 5. Grafos vxml y Documentos vxml Figura 5.1: Cambios Ramicados en un Grafo XML que ofrece mejores características. Nótese que el subíndice asociado a una determinada versión no conlleva que derive de un índice de versión anterior, por ejemplo la versión V 5 del grafo XML no deriva de la versión V 4. A continuación se detallan algunos de los cambios realizados: El arco ~data procedente del vértice &5, con valor Spanish, ha actualizado su valor en las versiones V 3 (Italian) y V 10 (French) y se ha borrado en la versión V 9. El arco ~data procedente del vértice &4, con valor Seafood, ha cambiado su valor en la versión V 5 (Sea) y posteriormente dicho arco ha sido borrado en la versión V 6. En el transcurso de las versiones V 2 a V 3 y V 3 a V 4 se han realizado dos operaciones de inserción: por un lado un nuevo vértice Element denominado street y por otro lado un vértice ~data sobre dicho vértice, París 10. Un nuevo arco atributo para el vértice &6 con nombre Cur se ha añadido en la versión V 2 y posteriormente se ha borrado en la versión V 8 y actualizado en V 7. A partir del ejemplo anterior (gura 5.1) se puede abstraer el grafo de derivación que establece cómo ha evolucionado el grafo XML en dicho ejemplo. Otras soluciones propuestas no representan esta derivación pues siempre se modica el estado actual; sin embargo en nuestro caso es necesario representarlo y se hace mediante un árbol que hemos denominado version_tree (árbol de versionado). La relación jerárquica del árbol representa la relación de derivación existente entre las distintas versiones. En la gura 5.2.a se ilustra el grafo de derivación obtenido a partir de la gura anterior. Nuestro siguiente paso es integrar cada uno de los estados o versiones del grafo XML en un único grafo XML, evitando la replicación de toda la información común. Esto se ha

125 Introducción a la Integración de Versiones 107 Figura 5.2: a. Grafo de Derivación de la gura 5.1 b. Validez de Versionado en un grafo XML conseguido estableciendo para cada arco del grafo XML en qué versiones es válido, de entre todas las versiones del grafo de derivación; a esto se le ha denominado validez de versionado. De este modo para cada arco del grafo XML se añadirá una nueva propiedad, representada como VV, que establece la validez de versionado del arco. En la gura 5.2.b se muestra una posible representación para esta validez de versionado basada en un lista de identicador de versión. Así, por ejemplo, el arco comprendido entre los vértices &5 y Spanish del grafo de nuestro ejemplo sería válido en la lista de versiones VV={V 1, V 2, V 5, V 6, V 7, V 8 } o el arco street es únicamente válido en la lista de versiones VV={V 4 }. Aunque pueda pensarse que esta representación es un grafo XML al que se añade el atributo VV, sin embargo, esto no es así, pues las siguientes propiedades incumplen la denición de grafo XML: 1. Pueden aparecer dos arcos de tipo atributo con el mismo padre y etiquetados con el mismo nombre. 2. Pueden aparecer dos o más arcos de tipo data descendientes del mismo vértice element que sean consecutivos según la ordenación de descendencia. 3. Card(outedges(&1)) puede tomar cualquier valor según el número de versiones del nodo raíz del grafo. Esta estructura, que denominaremos versioned_doc la cual se interpreta de forma que para cada identicador de versión se puede obtener el grafo subyacente formado por todos los arcos que contienen ese identicador de versión en su validez de versionado. Deseamos que dicho grafo sea siempre un grafo XML, es decir, que para cada identicador de versión se obtenga un grafo XML. En el siguiente apartado deniremos un nuevo modelo denominado grafo vxml especicando las condiciones que debe vericar la validez de versionado para asegurar la condición anterior.

126 108 Capítulo 5. Grafos vxml y Documentos vxml 5.2. Grafos vxml En la gura 5.2 se distinguen claramente dos estructuras; una es el árbol de versionado que representa la historia de versionado del documento y otra es el grafo versionado que representa el grafo XML original con la integración de los cambios que se han producido en sus sucesivas versiones. En primer lugar deniremos el árbol de versionado como un grafo XML y a continuación se analiza la estructura del grafo versionado. Para ello proponemos una representación eciente de la validez de versionado (versionstamp) que facilite la obtención del cada grafo XML asociado a cada versión; además, se analizarán las condiciones que debe cumplir la validez de versionado para asegurar que se obtendrá un grafo XML bien formado para cada versión.finalmente, se integrarán estas dos estructuras en una única que denominaremos grafo vxml Árbol de Versionado El objetivo del árbol de versionado es representar qué versiones de un grafo XML se han producido y, lo más importante, las relaciones que existen entre ellas. Normalmente esta relación suele estar basada en el concepto de derivación, de forma que podamos indicar el conjunto de nuevas versiones del grafo que se han obtenido a partir de una versión dada. Este árbol de versionado se ha representado como un grafo XML de modo que los vértices representan cada una de las versiones y los arcos van a establecer la derivación entre ellas. Nótese en la denición que el árbol de versionado inicial de cualquier documento parte siempre de la versión V 0, que representa el documento vacío. Denición 5.1. version_tree. Vt=(V',E',&0) es un grafo XML donde &0 es la raíz del árbol de versionado y tiene las siguientes características: 1. El vértice root &0 siempre tiene un único arco, etiquetado como version_tree, hacia un vértice element con identicador &V0 con el cual representamos el estado del documento vacío. 2. Denotaremos cada vértice como &Vi, cada uno de los cuales representa un estado del documento. 3. Cada vértice element distinto de root (&0) del árbol de versionado tiene un arco de salida e E' A cuyo nombre name(e)=id y value(child(e))=v i D(id), es decir, cada vértice del árbol de versionado tiene un arco atributo que lo identica de forma única sobre el resto de los vértices del árbol de versionado. 4. Cada vértice distinto de root (&0) tiene un conjunto de arcos de salida etiquetados como version que representan la relación de derivación entre las distintas versiones del documento. La gura 5.3 ilustra grácamente el subgrafo version_tree de un grafo vxml que reproduce el grafo de derivación de la gura 5.1. Éste se encuentra constituido por un conjunto de vértices con valor &V i (como sucede para los vértices &V 0, &V 1 y &V 2 ) que representan las distintas instantáneas del documento. Cada vértice element contiene un arco de salida E A, usado como identicador único de versión (por ejemplo V 1 y V 2 ), y un conjunto de arcos de salida E E denominado version que representan la derivación que ha tenido el grafo XML.

127 Grafos vxml 109 Así, por ejemplo, desde el vértice &V 1 existe un arco de salida version hacía el vértice &V 2, indicando que esta versión ha surgido de modicar el estado V 1 del grafo XML, o, desde vértice &V 2 existen tres arcos de salida version (&V 3, &V 5 y &V 6 ) que representan cada una de las versiones alternativas del estado &V 2. Figura 5.3: Representación de un Grafo de Derivación mediante un Grafo XML Nótese que este árbol de versionado se puede enriquecer semánticamente añadiendo más información al mismo. Por ejemplo, se podrían añadir unos arcos a cada vértice que representen la información temporal (válida o transaccional) asociada a cada versión o incluso se podría almacenar para cada versión información de los cambios realizados Marcado de Versión: VersionStamp Nuestro siguiente paso será representar la validez de versionado de cada uno de los componentes del grafo XML. Como ya hemos mencionado en la sección anterior, no recurriremos a una técnica basada en tiempo para este objetivo sino que deniremos la validez a partir de las versiones representadas en el árbol de versionado; a esta técnica la hemos denominado Marcado de Versión o VersionStamp. La validez de versionado es un conjunto de identicadores de versión del árbol de versionado que hemos representado en la gura 5.2.b mediante una lista. Ahora analizaremos esta representación teniendo en cuenta el árbol de versionado. Un primer aspecto a considerar es si representamos la validez de un arco mediante el conjunto de versiones en las cuales es válido dicho arco (representación positiva) o mediante el conjunto de versiones en el árbol de versionado donde el arco no es válido (representación negativa). La gura 5.4 muestra ambas representaciones para el arco comprendido entre los vértices &5 y Spanish del grafo de nuestro ejemplo. Este arco, siguiendo los cambios de la gura 5.1, es válido en las versiones VV={V 1, V 2, V 5, V 6, V 7, V 8 }. En ambas soluciones, los círculos sólidos indican el conjunto de versiones que se utilizan para denir la validez, en la representación positiva es el conjunto de versiones en el que es válido mientras que en la negativa es el conjunto de versiones en el que no es válido. Obsérvese que ambas soluciones son igualmente aceptables pero el primer caso (positivo) nos permite representar la validez mediante un árbol (un grafo conexo) mientras que en el segundo (negativa) se utiliza un

128 110 Capítulo 5. Grafos vxml y Documentos vxml bosque (varios grafos conexos, concretamente en esta gura existirían tres grafos no conexos). Puesto que a priori parece más sencillo el manejo de un único grafo conexo, en lugar de varios, nosotros deniremos nuestra validez usando una representación positiva mediante una única componente conexa y este será el único tipo de validez de versionado que asociaremos a cada elemento como se verá posteriormente en la denición 5.2 de región de versionado. Figura 5.4: Representación Positiva y Negativa para la Validez de Versionado Para denir la región conexa asociada a la validez de versionado de un arco, podemos adoptar varias soluciones: 1. Una lista de identicadores de versión [Arévalo Rosado 03b] que representa en qué versiones el arco es válido. Por tanto, la validez de versionado entre los vértices &5 y Spanish tendría el siguiente valor VV={V 1, V 2, V 5, V 6, V 7, V 8 } en la representación positiva. 2. Una lista de intervalos lineales de versionado [Arévalo Rosado 03a] formada por un conjunto de pares [V i - V j ] que representa un camino en el árbol de versionado donde V i es el identicador de versión origen del camino y V j es el identicador de versión nal del camino. Mediante esta representación la validez de versionado para el arco entre los vértices &5 y Spanish sería VV= {[V 1 - V 7 ],[V 6 - V 8 ]} en la representación positiva. Ambas notaciones presentan el mismo problema, derivado de la necesidad de actualizar la validez de versionado de todos los arcos afectados en el grafo cuando surge una nueva versión. La generación de una nueva versión identicada como V 11 a partir de la versión V 8 nos obliga a actualizar la validez de versionado de todos los nodos que contengan la versión V 8, para reejar que el arco que era válido hasta V 8 ahora lo es hasta V 11. Obviamente esta situación implica un alto coste de reconstrucción para todos los arcos afectados sobre los cuales puede que no se haya realizado la operación. Esta reconstrucción de la validez se debe a que utilizamos un conjunto de representaciones lineales para describirla, cada una de ellas mediante un único nodo origen y un único nodo destino del árbol de versionado. Nos interesaría una representación más compacta y eciente para minimizar su actualización ante nuevas versiones. Si observamos la componente conexa de los ejemplos anteriores, se puede concluir que siempre está denida por un único vértice origen cuyo subárbol asociado puede tener huecos, siempre en forma de subárboles, que no pertenecen a la región de validez. Esta situación se puede representar mediante un único vértice, origen de la región conexa, y un conjunto de vértices que determinan las raíces de los subárboles que no pertenecen a la región. Por ejemplo, la validez de versionado ilustrada en la gura 5.4 se denotaría como VV= [V 1 - {V 3,

129 Grafos vxml 111 V 10 }], como se muestra grácamente en la gura 5.5 (caso segundo). Con esta representación garantizamos no tener que actualizar la validez de versionado de un arco que siga siendo válido en una nueva versión. Por tanto, para representar la validez de versionado usaremos una representación mixta, mezcla de las representaciones positiva y negativa descritas anteriormente, que denominaremos región de versionado. Esta técnica, obtenida de forma independiente, ha sido previamente denida en [Jiang 00, Salzberg 04] donde los autores denen una técnica de indexación para la gestión de versiones de documentos que dene la paginación en base a regiones de versionado que ellos denominan rangos de versionado. Para realizar esta denición usaremos el siguiente conjunto de notaciones. Sea un árbol de versión Vt=(V',E',&0) y sea v V' element, entonces denotaremos lo siguiente: Dado un x D(id), si v V' element / e E' A ;((parent(e)=v) (name(e)="id") (value(child(v))=x), denotaremos este vértice como Υ(x)=v. Si este vértice v existe para x, debe ser único y denotará el vértice identicado por x, o simplemente vértice de x. En general, usaremos el símbolo x para denotar valores y distinguirlos del uso de v para denotar vértices. (v)=descendant(v,vt) V' element como todos los vértices element descendientes para el vértice v. (v)=ancestor(v,vt) V' element como todos los vértices element ancestros de v. (v)=(descendant(v,vt) {v}) V' element como todos los vértices element descendientes de v, incluyéndose a si mismo. (v)=(ancestor(v,vt) {v}) V' element como todos los vértices element ancestros de v, incluyéndose a si mismo.,,, pueden también denirse sobre un conjunto de identicadores de versión: por ejemplo {v i I }= i I (v i ). Denición 5.2. Región de versionado: Dado un árbol de versionado Vt=(V',E',&0) una región de versionado es un par [start-end] donde el valor start es un identicador de versión que representa el nodo origen del área válida en el árbol de versionado (representación positiva) y end es un conjunto de identicadores de versión que indican cuándo deja de ser válida (representación negativa). Según lo anterior una región de versionado es una única componente conexa denida mediante el par [start-end] que debe cumplir las siguientes restricciones: 1. Υ(start) V' Element y x i end, Υ(x i ) V' Element. 2. [ x i end, Υ (x i ) (Υ (start))] [ x i,x j end, Υ(x j ) / (Υ (x i )), i j.] 3. Si end=ø entonces se representará por &V now, indicando de esta forma que esta región de versionado es válida para todos los descendientes en el árbol de versionado cuya área comienza por el identicador de versión del atributo start. 1 1 El estado now ha sido ampliamente estudiado en las bases de datos temporales [Cliord 97] y su objetivo es reejar que un determinado dato no ha cambiado su valor desde el instante temporal en que empezó a ser válido, lo que se denomina no changes until now. En las bases de datos temporales normalmente se reeja indicando que el objeto deja de ser válido en un valor temporal muy elevado (12/31/9999), de forma que

130 112 Capítulo 5. Grafos vxml y Documentos vxml es decir, todos los identicadores de versión que aparecen en [start-end] deben tener vértices en el grafo XML (propiedad 1). Además, todos los identicadores de versión incluidos en end deben tener sus vértices descendientes del vértice de start, y no son descendientes entre sí, es decir, están en ramas disjuntas desde start (propiedad 2). De este modo, una región de versionado se dene mediante un subconjunto de nodos del árbol de versionado dado que existe un único nodo origen y pueden existir varios nodos que determinan cuándo naliza la validez del arco para cada una de las ramas. Si consideramos estos valores del tipo IDREFS, denen un conjunto de arcos referencia que apuntan a los identicadores de versión. En la gura 5.5 se muestran varios ejemplos de región de versionado, validez de versionado, con el objetivo de claricar este concepto. Para cada uno de ellos se ilustra grácamente el árbol de versionado de partida y las versiones válidas de cada una de las regiones de versionado consideradas, enmarcadas mediante una línea cerrada. Se proponen los siguientes casos: 1. VV= [V 1 - {V 5 }]. Región que es válida para todas las versiones del árbol de versionado exceptuando la versión identicada por V 5 y sus descendientes (pues V 5 se encuentra en el atributo end y este hecho reeja que ha dejado ser válida en dicha versión). Más concretamente, la región de versionado está compuesta por todos los identicadores de versión que descienden del identicador de versión V 1, excepto los identicadores de versión que sean descendientes de V 5 (inclusive). VV={V 1, V 2, V 3, V 4, V 9, V 6, V 10 } tal y como se muestra mediante una línea cerrada en la gura en cuestión. 2. VV= [V 1 - {V 3, V 10 }]. Todas las versiones, a partir de V 1, que no sean descendientes de los identicadores de versión V 3 y V 10 (inclusive ellos mismos) forman parte de esta región de versionado, es decir, es válido en las versiones VV={V 1, V 2, V 5, V 7, V 6, V 8 }. Hay que destacar que en este caso el valor del atributo end se encuentra formado por dos valores, que constituyen dos vértices en el árbol de versionado donde el área ha dejado de ser válida. 3. VV= [V 2 - {V 4, V 5,V 8 }]. En el tercer caso, la región de versionado deja de ser válida en tres identicadores de versión {V 4, V 5, V 8 } a partir de la versión V 2. Por tanto, el arco asociado a esta región es válido para las siguientes versiones: {V 2, V 3, V 9, V 6,V 10 }. 4. VV= [V 3 - {V now }]. El último caso de la gura 5.5 nos permite representar una situación especial en la que el atributo end contiene el valor del identicador especial de versión V now. Como se ha expuesto anteriormente, cuando este valor se encuentra en la región de versionado signica que es válido para todos los descendientes del atributo start, es decir, que no ha existido ninguna versión descendiente de V 3 que haya afectado a esta región de versionado, siendo su validez {V 3, V 4, V 9 }. Nótese que si un arco e tiene asociada esa región de versionado, en el caso de añadirse alguna nueva versión al grafo XML que descienda de V 3 en la que siga siendo válido el arco e, entonces no es necesario actualizar esta región de versionado. Como hemos expuesto, para la integración de todas las versiones de un grafo XML en una misma estructura de grafo es necesario establecer la validez de cada arco del grafo resultante. Para ello cada arco tiene una nueva propiedad, representada como VV y denominada región cualquier tiempo incluido entre el comienzo del intervalo y dicho valor se encuentra dentro de este rango. Sin embargo, en nuestro caso, la validez se dene en base a un árbol de versionado y el estado now correspondería a un conjunto vacío para end, indicando que no existe versión alguna en la que haya dejado de ser válido. Para resaltar este hecho, usaremos la notación V now en lugar de la cadena vacía.

131 Grafos vxml 113 Figura 5.5: Ejemplos de Región de Versionado de versionado, que establece la validez de versionado de estos arcos, es decir, en qué versiones del árbol de versionado es válido. Esta nueva propiedad nos conduce a la denición de arco v-edge. Denición 5.3. v-edge o v-arco: Arco con una región de versionado asociada que representa su validez con respecto a un árbol de versionado. Nótese que este grafo integrador de versiones no es un grafo XML por las características mencionadas al nal de la sección anterior (arcos atributos con el mismo nombre, arcos ~data consecutivos y más de un vértice raiz). Esto nos conduce a denir un nuevo grafo para representar estas versiones que denominaremos grafo vxml tal y como se verá a continuación Grafo vxml A continuación deniremos el grafo vxml como una estructura que agrupa el grafo XML que representa al árbol de derivación y a la estructura de grafo que integra los grafos XML asociados a cada versión y que denominaremos versioned_doc. Denición 5.4. Grafo vxml. Un grafo vxml Dv=(V,E,root) es un grafo formado por un nodo raíz r oot, el cual tiene un único arco de salida etiquetado como v_document hacia un vértice &0. Desde dicho vértice existen dos arcos de salida denominados version_tree y versioned_doc que denen dos grafos con las siguientes características (grácamente en la gura 5.6):

132 114 Capítulo 5. Grafos vxml y Documentos vxml version_tree Vt=(V',E',&0) es un grafo XML donde &0 es la raíz de este árbol de versionado y tiene tanto vértices element como versiones representadas en el grafo, donde V' V y E' E del grafo vxml. [Denición 5.2] versioned_doc D=(V d, E v, &0) es un grafo donde &0 es la raíz del grafo y todos los arcos del grafo, e E v, son v-edge cuya propiedad V V e representa su validez de versionado respecto del árbol de versionado version_tree, es decir, dene en qué versiones del árbol de versionado el arco es válido. V=V' V d {root}, V' V d = {&0}y E=E' E v {v_document}, E' E v =. Además, versioned_doc tiene las siguientes propiedades: 1. Desde el vértice &1 se situarían cada una de las raíces de las versiones del grafo XML. 2. versioned_doc se puede considerar como un grafo XML con las siguientes particularidades: a) Para un mismo vértice element pueden existir dos arcos de tipo atributo etiquetados con el mismo nombre en cuyo caso sus regiones de validez asociadas son disjuntas. b) Pueden existir dos o más arcos de tipo data descendientes del mismo vértice element que sean consecutivos siendo sus regiones de versionado asociadas disjuntas entre sí. c) Card(outedges(&1)) puede tomar cualquier valor según el número de versiones del nodo raíz del documento. Todos los arcos descendientes de &1 tienen regiones de validez asociadas disjuntas. Nótese que esto no es cierto en general para el resto de vértices element pues un vértice puede tener varios vértices element hijos válidos en una misma versión. 3. El arco versioned_doc que une &0 y &1 tiene como región de versionado asociada VV versioned doc=[v 0 - {V now }] y &i (V d {&0}) se dene su región de versionado VV &i como la región de versionado de su arco de entrada. 4. Dado un vértice &i V d del grafo con su región de versionado asociada VV &i, se verica que para todo arco descendiente de &i, su región de versionado esta contenida en VV &i, es decir, &i V d, (V V &j V V &i, &j child(&i)). Observaciones: 1. Un grafo vxml vacío se encuentra formado por los vértices root, &0, &V 0, &1 junto con los arcos que los enlazan. Nótese que estos vértices y arcos son los únicos elementos del grafo que no pueden ser borrados ni actualizados por las operaciones de cambio. Además existe un vértice dentro del árbol de versionado, etiquetado como V 0, que representa la versión inicial (vacía) del mismo junto con un vértice especial V now con el comportamiento que se expondrá posteriormente. 2. Nótese que los grafos Vt y D tienen el mismo vértice origen &0, que en el caso de Vt tiene un único arco descendiente version_tree y mientras que para D tiene como único arco descendiente versioned_doc.

133 Grafos vxml A partir de la observación anterior, nos gustaría destacar que estos vértices tienen las propiedades: Card(inedges({&0, &V 0, &1}))=1), Card(outedges(root))=1), Card(outedges(&0))=2) y Card(outedges(&1)) puede ser mayor o igual de 1 dependiendo número de raíces que tenga el documento XML a lo largo de su historia. 4. Dado un grafo XML de partida (V 0 ), todos sus vértices y arcos se encuentran situados en el grafo vxml como descendientes del vértice &1, teniendo todos los arcos la nueva propiedad VV. Figura 5.6: Representación de un Grafo vxml vacío En la gura 5.6 se ilustra la representación gráca de un Grafo vxml vacío. Se puede comprobar que el vértice root tiene un arco de salida etiquetado como v_document hacia el vértice &0. Desde dicho vértice, existen dos arcos de salida (version_tree y versioned_doc) que contienen la información de las versiones y el grafo XML original. A continuación analizamos más proposiciones y deniciones relacionadas con esta estructura. Proposición 5.1. Las siguientes proposiciones son equivalentes a la propiedad 4 de la denición 5.4: La validez de versionado de cualquier arco e=(&i 1,&i 2 ) es un superconjunto de la unión de la validez de versionado de todos los arcos de salida del vértice e.&i 2 =child(e). Dado un arco e E v, no puede existir ningún arco descendiente de child(e) cuya región de versionado contenga alguna versión que no pertenezca a la región de versionado de e. Denición 5.5. Cierre de una región de versionado. Se dene el cierre de versionado de un vértice &i V d, y se denotará por V V &i, como la menor región de versionado VV que contiene a todas las regiones de versionado descendientes del vértice &i: V V &j V V &j = V V &i V V &i &j child(&i) &j child(&i) Ejemplo: En la gura 5.7 se muestra un ejemplo de cierre de versionado sobre un vértice etiquetado con el valor &5. Este vértice tiene dos arcos descendientes cuyas regiones de versionado son [V3 - {V now }] y [V6- {V8,V10}]} cuya validez se muestra en la gura con dos áreas de color azul y roja respectivamente. Como se observa grácamente en la gura el cierre

134 116 Capítulo 5. Grafos vxml y Documentos vxml Figura 5.7: Ejemplo de Cierre de Versionado de versionado del vértice &5 sería la región [V2- {V5}] pues es la menor región de versionado que contiene ambas regiones. Nótese que el cierre de varias regiones de versionado se puede construir siempre; bastaría añadir sólo los caminos que unen la raíz de cada región de versionado con el antecesor común a todas ellas. Con estas proposiciones podemos armar que la validez de versionado de cualquier arco e es un superconjunto de la unión de la validez de versionado de todos los arcos de salida de child(e), es decir, que dado un arco e E no puede existir ningún arco descendiente de e que sea válido en una versión no válida de e. Denominaremos duración de un vértice V (lifespan) a la unión de la validez de versionado de todos los arcos de salida para ese vértice, siendo la validez del vértice versioned_doc [V 0 - {V now }]. Denición 5.6. v-arcos incompatibles. Dos v-arcos A y B diremos que son incompatibles si tienen siempre regiones de versionado disjuntas: V V (A) V V (B) = Ø. Ejemplo de esta denición son todos los arcos descendientes de &1: e 1, e 2,...,e n que son incompatibles entre sí y representan los elementos raíces de versiones del documento. Estas arcos son siempre incompatibles dos a dos. Grácamente en la gura 5.8 se ilustra el grafo vxml resultante de representar los cambios realizados en la gura 5.1 al grafo XML de los restaurantes y cocineros. En él, podemos observar que cada arco del grafo vxml contiene, además del nombre, la región de versionado. Nótese que en este ejemplo el vértice de destino del arco doc en lugar de tener el identicador &1 tiene el identicador &2, pues el vértice &1 es usado por el sistema para el vértice destino del arco versioned_doc. Finalmente, imaginemos que un mismo arco de versionado ocurre intermitentemente en el árbol de versionado, es decir, es válido en dos regiones de versionado no-conexas. Esta situación se representa con nuestra técnica usando distintos arcos para cada una de las distintas regiones de versionado, replicando, de este modo, el arco tantas veces como regiones distintas existan. Se propone, como futura mejora de la presente tesis, denir la región de versionado como una unión nita de regiones de versionado, de manera similar a cómo se usan los elementos temporales [Tansel 93, Zaniolo 97, Snodgrass 95], lo que denominaríamos elemento de versionado.

135 Grafos vxml 117 Figura 5.8: Grafo vxml con múltiples Versiones

136 118 Capítulo 5. Grafos vxml y Documentos vxml 5.3. Representación de un Grafo vxml en un Documento XML: Documentos vxml En este apartado mostramos el proceso de transformación de un grafo vxml en un documento XML con todas sus versiones integradas, al cual hemos denominado documento vxml. Tal y como hemos indicado previamente un grafo vxml es una nueva estructura, de modo que los algoritmos de conversión de un grafo XML, descritos en el capítulo anterior, 4.1 no pueden usarse sobre el grafo vxml completo, pues obtendríamos un documento XML mal formado (atributos duplicados, contenidos no-válidos y anidamientos incorrectos). Comenzaremos analizando la situación inicial de un grafo vxml, es decir, su estado vacío (gura 5.6), el cual sí cumple con todas las propiedades y restricciones descritas para un grafo XML, de modo que sí pueden aplicarse los algoritmos XML. Así un documento vxml vacío se encuentra formado por los elementos v_document, version_tree y versioned_doc, tal y como se puede contemplar en la gura 5.9 que ilustra la estructura básica de un documento vxml. 1 <?xml version='1.0'> 2 <v_document> 3 <version_tree> 4 5 </version_tree> 6 <versioned_doc> 7 8 </versioned_doc> 9 </v_document> Figura 5.9: Estructura básica de un documento vxml. Documento vacío vxml. A continuación analizaremos por separado la conversión del grafo XML version_tree y del grafo versioned_doc Árbol de versionado En la denición 5.1 del presente capítulo expusimos que un árbol de versionado Vt=(V', E', &0) es un grafo XML donde &0 es la raíz del árbol de versionado y tiene tanto vértices element como versiones almacenadas en el documento. De este modo, el proceso de transformación realizado para un grafo XML puede ser aplicado a este sub-grafo version_tree (algoritmo 4.1), pues el conjunto de arcos y vértices que forman parte de él no incorpora características adicionales que obliguen a modicar el proceso. Los pasos a realizar son los siguientes: Cada vértice &V i + arco de salida version describe un elemento version el cual representa un estado o versión o instantánea del documento XML. Cada arco de salida id procedente de un vértice &V i representa un atributo identicador del elemento version. A nivel de XML existen dos posibles soluciones para este atributo: 1. Utilizar una identicación externa, es decir, asociar al documento vxml un documento XML-Schema y emplear el tipo xs:id. Con esta solución es el esquema quien establece las restricciones de unicidad y validez para el atributo id de modo que si existieran dos atributos con el mismo valor id, el procesador XML sintáctico

137 Representación de un Grafo vxml en un Documento XML: Documentos vxml 119 Figura 5.10: Árbol de Versionado en XML proporcionaría como resultado un documento no-valido. Esta solución obliga a tener siempre un documento esquema que garantice esta condición y además utilizar un analizador sintáctico con soporte de validación contra esquemas. 2. Utilizar una identicación interna: recientemente la organización W3C ha publicado una nueva recomendación [Veillard 05], donde se incluye el atributo xml:id que permite marcar elementos con identicadores únicos. Esta solución realmente consiste en declarar el tipo de un atributo como "ID" para que el analizador pueda validar: que el valor del atributo marcado como ID respete la forma léxica permitida, que el valor sea único dentro del documento XML y que cada elemento tenga como máximo un identicador único. En este caso es el propio analizador XML quien se encarga de comprobar que el documento está bien formado y vericar la unicidad del atributo xml:id sin necesidad de un esquema asociado. Nótese que: en este trabajo hemos decidido utilizar la solución interna para la representación del atributo id, es decir, usaremos el atributo xml:id para identicar cada una de las versiones incluidas en el documento vxml. En la gura 5.10 se ilustra la representación gráca y XML del árbol de versionado obtenido de aplicar este proceso de conversión sobre el grafo vxml de la gura 5.1. Nótese que el anidamiento de los elementos version del documento XML representa la derivación entre las distintas versiones. Así, por ejemplo desde la versión V 2 se han realizado tres versiones alternativas V 3, V 5 y V 6 que se han plasmado en el documento XML mediante tres elementos XML hijos del elemento version con identicador V Marcado con Región de Versionado En este apartado se analiza el proceso de transformación de los arcos históricos contenidos en un grafo vxml a un documento XML versionado, es decir, la transformación del subgrafo versioned_doc. Como hemos mencionado previamente, el algoritmo de conversión de un grafo XML a un documento XML no puede aplicarse sobre esta estructura pues generaría un documento XML mal formado (atributos duplicados y podría existir anidamiento incorrecto) debido a que este proceso de transformación desconoce cómo interpretar la validez de versionado asociada a cada arco del grafo vxml.

138 120 Capítulo 5. Grafos vxml y Documentos vxml Figura 5.11: Grafo vxml y su representación en grafo XML equivalente Para evitar este problema proponemos una solución que consiste en la generación de un grafo XML equivalente al grafo vxml donde no se produzca esta situación y de este modo los algoritmos sean aplicables. Este nuevo grafo XML intermedio se caracteriza por la existencia de dos nuevos arcos element: el arco v:attrib que representa a los arcos atributos y el arco v:data para los arcos ~data. Es decir, todo v-arco atributo del grafo vxml se transforma en un v-arco element v:attrib, el cual contiene la información de versionado del arco atributo origen. Este nuevo arco v:attrib enlaza a un nuevo vértice desde el cual se representa el nombre y el valor del atributo mediante dos arcos atributos de salida, tal y como se puede ver en la gura Por ejemplo el v-arco atributo cur se transforma en un arco v:attrib hacia un nuevo vértice &at8, cuya región de versionado es igual al arco origen [V 1 - {V 7, V 8, V 9 }]. Desde este nuevo vértice &at8 existen dos arcos atributos que contienen el nombre y el valor del atributo origen. Esta situación también se aplica a los arcos element con destino a un vértice data, creándose un nuevo v-arco v:data, con la información de versionado. De este modo estos dos nuevos arcos se transformarán en dos elementos XML en el proceso de conversión, v:attrib y v:data, evitando de este modo que el documento XML resultante no esté bien formado. Además, se ha decidido representar una región de versionado mediante dos atributos XML, denominados v:start y v:end. El primero de ellos, v:start, está denido en base al tipo de dato IDREF de XML, pues hace referencia exclusiva a un identicador de versión del árbol de versionado, mientras que el segundo de ellos, v:end, se ha denido en base al tipo de dato IDREFS de XML que nos permite representar un conjunto de identicadores de versión del árbol de versionado. De este modo todo elemento XML se encontrará formado por estos dos atributos. Teniendo en cuenta estas consideraciones, los nuevos arcos (v:attrib y v:data) y la repre-

139 Representación de un Grafo vxml en un Documento XML: Documentos vxml 121 sentación de la región de versionado mediante dos atributos, el proceso de transformación de un grafo vxml en un documento vxml será el siguiente si se contempla como un único paso: 1. Todo arco de entrada a un vértice element se traduce en un elemento XML cuyo nombre es la etiqueta del arco de entrada con los correspondientes atributos v:start y v:end que representan la región de versionado. 2. Todo arco element de entrada a un vértice data se transforma en un elemento hijo denominado v:data con sus correspondientes v:start y v:end, donde el valor del vértice se incluye como contenido del elemento. Esto nos va a permitir gestionar distintas versiones del contenido de un determinado elemento XML. 3. Todo arco atributo se transforma en un elemento hijo denominado v:attrib, con sus correspondientes v:start y v:end, donde el nombre y el valor del atributo son representados como atributos, denominados name y value de este elemento. Figura 5.12: Conversión de un grafo vxml a un documento vxml El resultado de aplicar este proceso de conversión sobre una parte del grafo vxml de la gura 5.8 se muestra en la gura 5.12, junto con su documento vxml equivalente. En este ejemplo podemos observar cada uno de los pasos especicados anteriormente. Por ejemplo un V-Arco element que une dos vértices element se transforma en su elemento XML equivalente junto con los dos atributos de versionado (v:start y v:end) como sucede para los arcos menú o price. En el caso de un arco element cuyo destino es un vértice data se crea un nuevo elemento XML denominado v:data, con sus atributos de versionado correspondientes. Podemos vericar este caso para los tres arcos ~data del vértice &6 que se convierten en tres elementos hijos v:data del elemento XML menú. Finalmente, cada V-Arco atributo se representa como un nuevo elemento XML v:attrib donde el nombre y el valor del atributo son propiedades de este nuevo elemento. Nótese que estos dos últimos elementos XML, v:attrib y v:data, no contienen un atributo idf, pues se pueden identicar a partir del elemento XML padre que lo contiene. En la gura 5.13 se muestra el documento vxml resultante de aplicar el proceso de conversión al grafo vxml de la gura 5.8. Nótese que el proceso de conversión de un documento

140 122 Capítulo 5. Grafos vxml y Documentos vxml vxml a un grafo vxml también requiere del uso de un grafo XML equivalente, formado por los arcos v:attrib y v:data que posteriormente serán representados en el grafo vxml destino por los v-arcos correspondiente. 1 <?xml version='1.0'?> 2 <v_document> 3 <version_tree> 4 <version xml:id='v1'> 5 <version xml:id='v2'> 6 <version xml:id='v3'> 7 <version xml:id='v4'/> 8 <version xml:id='v9'/> 9 </version> 10 <version xml:id='v5'> 11 <version xml:id='v7'/> 12 </version> 13 <version xml:id='v6'> 14 <version xml:id='v8'/> 15 <version xml:id='v10'/> 16 </version> 17 </version> 18 </version> 19 <version xml:id='now'/> 20 </version_tree> 21 <versioned_doc> 22 <doc idf='2' v:start='v1' v:end='now'> 23 <cook idf='3' v:start='v1' v:end='now'> 24 <v:attrib v:start='v1' v:end='now' name='id' value='c1'/> 25 <v:attrib v:start='v1' v:end='now' name='name' value='arzak'/> 26 </cook> 27 <rest idf='4' v:start='v1' v:end='v9'> 28 <v:attrib v:start='v1' v:end='v9' name='id' value='r1'/> 29 <v:isref v:start='v1' v:end='v9' name='cooks' value='c1'/> 30 <name idf='5' v:start='v1' v:end='now'> 31 <v:data v:start='v1' v:end='v5 V6 V9'>Seafood</v:data> 32 <v:data v:start='v5' v:end='now'>sea</v:data> 33 </name> 34 <menu idf='6' v:start='v1' v:end='v9'> 35 <v:data v:start='v1' v:end='v3 V10'>Spanish</v:data> 36 <v:data v:start='v3' v:end='v9'>italian</v:data> 37 <v:data v:start='v10' v:end='now'>french</v:data> 38 </menu> 39 <price idf='7' v:start='v1' v:end='v9'> 40 <v:attrib v:start='v1' v:end='v7 V8 V9' name='cur' value=/> 41 <v:attrib v:start='v7' v:end='now' name='cur' value='euro'/> 42 <v:data v:start='v1' v:end='v9'>15</v:data> 43 </price> 44 <street idf='8' v:start='v3' v:end='now'> 45 <v:data v:start='v4' v:end='now'>paris 10</v:data> 46 </street> 47 </rest> 48 </doc> 49 </versioned_doc> 50 </v_document> Figura 5.13: Documento vxml de Restaurante y Cocineros

141 Recuperación de Versiones Recuperación de Versiones Recuperar un estado concreto del grafo vxml o documento vxml es la operación que se realiza más asiduamente en cualquier sistema de versionado. En este apartado analizaremos esta operación de recuperación aplicada sobre los grafos vxml y documentos vxml Recuperación de Versiones (Grafos XML) a partir de un Grafo vxml Hasta ahora el termino validez se ha relacionado con el árbol de versionado, es decir, se ha denido el concepto de región de versionado y la forma en que esta región se asigna a un arco. En esta sección, se describe cómo vericar si una región de versionado de un grafo vxml pertenece a un determinado estado. El proceso natural para considerar que un arco es válido en una versión dada consiste en analizar qué versiones están incluidas en la región de versionado y comprobar si la versión dada pertenece a ella. Se ha determinado que esto ocurre si y sólo si: 1. La versión dada se encuentra entre los descendientes del identicador de versión start en el árbol de versionado, incluyéndose a si mismo. 2. La versión dada no se encuentra entre los descendientes de los identicadores de versión end en el árbol de versionado para todos los identicadores de versión contenidos en end (incluyéndose a si mismos). Para determinar si una región de versionado contiene a una versión dada puede utilizarse la siguiente proposición que representa al predicado belongto (que determina si una región de versionado contiene a una versión): Proposición 5.2. (belongto (VV,x)) Una región de versionado VV=[start-end] contiene un identicador de versión x D(id) si satisface que : (Υ(x) (start) (Υ(x) (end) )) A continuación exponemos varios ejemplos que nos permitan comprender mejor este proceso. Partiendo de las regiones de versionado expuestas en la gura 5.5 analizaremos si cada una de ellas es válida para la versión V4. 1. Sea VV= [V 1 - {V 5 }], (V 1 )={V 1, V 2, V 3, V 4, V 5, V 6, V 7, V 8, V 9, V 10 }, {V 5 } = {V 5, V 7 }, VV es válida para V 4 Υ(V 4 ) (V 1 ) (Υ(V 4 ) (V 5 ) ) Es válida. 2. Sea VV= [V 1 - {V 3, V 10 }], (V 1 )={V 1, V 2, V 3, V 4, V 5, V 6, V 7, V 8, V 9, V 10 }, {V 3, V 10 } = ( (V 3 ) (V 10 ) )={V 3, V 4, V 9, V 10 }, VV es válida para V 4 Υ(V 4 ) (V 1 ) (Υ(V 4 ) (V 3 ) ) No es válida. 3. Sea VV= [V 2 - {V 4, V 5,V 8 }], (V 2 )={ V 2, V 3, V 4, V 5, V 6, V 7, V 8, V 9, V 10 }, {V 4, V 5, V 8 } = { V 4, V 5, V 7, V 8 }, VV es válida para V 4 Υ(V 4 ) (V 2 ) (Υ(V 4 ) (V 4 ) ) No es válida. 4. Sea VV= [V 3 - {V now }], (V 3 )={ V 3, V 4, V 9 }, {V now } = φ, VV es válida para V 4 Υ(V 4 ) (V 1 ) (Υ(V 4 ) (V now ) ) Es válida.

142 124 Capítulo 5. Grafos vxml y Documentos vxml Figura 5.14: Ejemplos de Validez de Versionado Ejemplo En la gura 5.14 se ilustran grácamente los 4 casos mencionados anteriormente. En la gura se puede comprobar fácilmente que la primera y cuarta región de versionado son válidas en la versión V 4, pues el identicador de versión V 4 se encuentra entre los descendientes de start (V 1 y V 3 respectivamente) y no se encuentra entre los descendientes de end (V 5 y V now respectivamente). Por el contrario, la segunda y tercera región de versionado no son válidas para la versión V 4 pues, en ambos casos, dicha versión se encuentra entre los descendientes de end (V 3 y V 4 respectivamente). Denición 5.7. Grafo vxml bien formado. Un grafo vxml Dv=(V,E,root) es un grafo bien formado si el grafo XML asociado a cada una de las versiones representadas en el árbol de versionado es válido. El proceso para obtener el grafo XML asociado a una versión a partir de un grafo vxml se muestra en el algoritmo 5.1 donde se usa la función BelongTo denida anteriormente. El algoritmo comienza comprobando si el grafo vxml esta vacío (línea 2) en cuyo caso retorna como grafo XML de salida el grafo XML vacío y en caso contrario comienza el algoritmo de recuperación desde el vértice destino del arco versioned_doc. A continuación para cada v-arco e E del grafo vxml se verica si su región de versionado (e.vv) contiene la versión dada (línea 11 para los arcos atributos y línea 17 para arcos element) en cuyo caso se recuperaría su información asociada. En el caso que el arco sea válido y sea un arco element con descendientes se procede a su llamada recursiva. La complejidad de este proceso de recuperación, tal y como se muestra en este algoritmo, es de orden O(n x m x k) donde n es el número de vértices del subgrafo versioned_doc del grafo vxml, m es el número de vértices del árbol de versionado que debe obtenerse por cada arco procesado cuando se recuperan los descendientes de start y end (función vbelongto) y k es el número de identicadores de versión representados en end que deben dereferenciarse

143 Recuperación de Versiones 125 para k entre [1-m]. Como el atributo end en el peor de los casos puede estar constituido por m-1 identicadores de versión representaremos la complejidad como O (n x m 2 ). Algoritmo 5.1 Recuperación de una versión de un Grafo XML a partir de un grafo vxml vgraph2graph (Gv, v, G) //input: Gv: Grafo vxml //input: v: Identicador de versión a recuperar //output: G: Grafo XML //Complejidad: Orden O(n x m x m), n número de vértices que denen el grafo versioned_doc, m el número de versiones del árbol de versionado y m número de identicadores de versión en el atributo end. 1. begin 2. CreateXMLGraph(G) 2. if outedge(gv.&1)=ø //esta vacío? 3. then () 4. else 5. x=gv.&1; // Vértice &1 6. retrieve(gv, v, x, G, root); 7. end_if; 8. end; retrieve (Gv, v, x, G, n) //input: Gv: Grafo vxml //input: v: Identicador de versión a recuperar //input: x: Vértice Element de entrada. &1 //output: G: Grafo XML de salida //input n: Identicador de vértice de inicio del grafo XML de salida 9. begin 10. for each e in (outedges(x) E A ) do //Atributos para elemento x 11. if (belongto(e.vv,v)) then //Si el arco es válido 12. AddNode(G, string, value(e), name(e), E A, n, 0) //Se copia el atributo 13. endif; 14. end_for; 15. for m=1 to card((outedges(x) E E )) do //Elementos descendientes 16. e m = O(m, (outedges(x) E E )); 17. if (belongto(e m.vv,v) then //Si el arco es válido 18. if e m.name=~data then 19. AddNode(G, string, value(e), ~data, E E, n, pos(e m )) //Copia el ~data 20. else begin 21. AddNode(G, Element, value(x), name(e m ), E E, n, pos(e m )) //Copia Vértice 22. retrieve(gv, v,e m.v2, G, x); //Llamada recursiva 23. end; 24. end_if; 25. endif; 26. end_for; 27. end;

144 126 Capítulo 5. Grafos vxml y Documentos vxml Optimización en la Recuperación de Versiones (Grafos XML) a partir de un Grafo vxml La operación de recuperación mostrada en el apartado anterior, encargada de obtener la información válida asociada a una versión, se encuentra condicionada por el número de versiones que posea el árbol de versionado pues para cada región de versionado es necesario recuperar todos los descendientes de versión de los atributos v:start y v:end, lo que provoca que la complejidad de este algoritmo sea elevada. En este apartado se muestra una optimización a este proceso. El planteamiento del proceso anterior puede considerarse como el proceso lógico o natural para comprobar si una región de versionado contiene a una versión dada pues parece obvio que obtengamos las versiones que hay en una región y se compruebe si entre ellas se encuentra la versión dada. Sin embargo, como hemos comprobado este algoritmo es muy costoso computacionalmente y por este motivo debe buscarse un planteamiento que lo mejore. Analizando este proceso vemos que el cálculo de pertenencia se realiza sobre la región de versionado la cual varia por cada elemento que se consulta mientras que la versión dada es ja durante todo el proceso. La pregunta sería ¾se puede determinan la validez en base a la versión dada que no varía durante todo el proceso? Grácamente a partir de un grafo podemos comprobar que dada una versión, ésta se encuentra en una región de versionado si el valor del atributo start se encuentra en los antecesores de la versión dada, lo que quiere decir que ha derivado de ella, y que el conjunto de identicadores del atributo end no está entre este conjunto de antecesores, hecho que indica que no existe una versión anterior a la dada donde ha dejado de ser válida. De este modo este nuevo proceso de recuperación se establecería como sigue: En primer lugar se obtendría el conjunto de identicadores de versión de todas las versiones anteriores a la versión dada del árbol de versionado. Y en segundo lugar para cada región de versionado se comprobaría si el valor del atributo start se encuentra entre este conjunto de antecesores de versión, y ningún valor del atributo end se encuentra entre este conjunto de antecesores. Así, este proceso presenta una gran mejora pues en lugar de recuperar constantemente todos los descendientes de versión de los atributos start y end, sólo es necesario realizar el cálculo de los antecesores de la versión dada una única vez al principio del proceso. Para determinar si una versión pertenece a una región de versionado puede utilizarse la siguiente proposición que representa al predicado belongtoopt: Proposición 5.3. (belongtoopt (VV,X)) Sea un identicador de versión x D(id) donde X= (x) son los antecesores de versión de x inclusive el mismo, diremos que x pertenece a una región de versionado VV=[start-end] si: (Υ(start) X Υ(end) X ) A continuación exponemos varios ejemplos que nos permitan comprender mejor este nuevo proceso. Partiendo de las regiones de versionado expuestas en la gura 5.5 analizaremos si cada una de ellas es válida para la versión V 4. Sea X = (V 4 )={V 1, V 2, V 3, V 4 } entonces: 1. Sea VV= [V 1 - {V 5 }], V 4 pertenece a VV pues se cumple que Υ(V 1 ) X (Υ(V 5 ) X. 2. Sea VV= [V 1 - {V 3, V 10 }], V 4 no pertenece a VV pues no se cumple que Υ(V 3 ) X. 3. Sea VV= [V 2 - {V 4, V 5,V 8 }], V 4 no pertenece a VV pues no se cumple que Υ(V 4 ) X.

145 Recuperación de Versiones Sea VV= [V 3 - {V now }], V 4 pertenece a VV pues se cumple que Υ(V 3 ) X (Υ(V now ) X ). Ejemplo En la gura 5.15 se ilustra grácamente los mismos cuatro casos de la gura 5.5 usando el nuevo proceso de pertenencia. En ella vemos que en primer lugar se calcula los antecesores de la versión dada, siendo X = (V 4 )={V 1, V 2, V 3, V 4 }, y que posteriormente para determinar la validez únicamente debe comprobarse si este conjunto de antecesores contiene el valor del atributo start y no contiene ninguno de los valores del atributo end. Por ejemplo la versión V 4 es válida en la primera región de versionado [V 1 - {V 5 }] pues la versión V 1 se encuentra entre los antecesores de V 4 y V 5 no se encuentra entre estos antecesores. Figura 5.15: Ejemplos de Validez de Versionado en el proceso Optimizado Finalmente si aplicamos este nuevo proceso de pertenencia al algoritmo de recuperación mostrado en el algoritmo 5.1, con la modicación de calcular previamente los antecesores de la versión dada, la complejidad resultante es O(n x m) pues por cada arco del grafo vxml sólo es necesario comprobar las condiciones anteriormente expuestas sin tener que recuperar ningún descendiente, siendo n el número de vértices que tiene el grafo de entrada y m el número de identicadores de versión que puede tener el atributo end y que deben dereferenciarse. Nótese que durante el resto de la tesis denominaremos a este segundo proceso de recuperación de información válida como optimizado pues ha sido denido con posterioridad al planteamiento inicial Recuperación de Versiones (Documentos XML) a partir de un Documento vxml En este apartado veremos cómo realizar el proceso de recuperación de un estado concreto del árbol de versionado de un documento vxml. Para ello es necesario determinar si un elemento XML con información de versionado contiene a una versión dada. Tal y como se ha expuesto en el apartado anterior, se ha determinado que dada una etiqueta de versionado formada por una región de versionado, ésta es válida si y sólo si 1) la versión dada se encuentra entre los descendientes de v:start (incluido) y 2) la versión dada no se encuentra entre los descendientes de v:end (incluido).

146 128 Capítulo 5. Grafos vxml y Documentos vxml Para realizar esta operación de forma eciente en XML se ha utilizado la función proporcionada por XPath id(), la cual dereferencia el valor de los atributos v:start y v:end a los elementos version del árbol de versionado a los que hace referencia. Tras utilizar esta función, se pueden recuperar sus descendientes, mediante los ejes XPath, y vericar las dos condiciones anteriormente expuestas. Esta operación se analizará a nivel XML con mayor profundidad en el capítulo de consultas (8). En el caso del proceso optimizado, se usará nuevamente la función id() sobre la versión dada para así recuperar sus antecesores y posteriormente se comprobará si el valor del atributo start se encuentra entre estos antecesores y los valores del atributo end no. Esta operación se analizará a nivel XML con mayor profundidad en el capítulo de consultas (8) Conclusiones En este capítulo se ha propuesto un modelo de datos que mantiene toda la información disponible sobre la evolución de un grafo XML a lo largo del tiempo, denominado grafo vxml. Se ha extendido el modelo XML propuesto en el capítulo anterior representando el grafo de derivación del grafo XML (árbol de versionado) y añadiendo una nueva propiedad a los arcos del grafo que determina su validez dentro del grafo de derivación (marcado de versión). Finalmente, una vez expuesto este modelo a nivel teórico, se ha analizado su representación mediante un documento XML versionado bien formado (documentos vxml). La principal ventaja de la solución propuesta es la facilidad que presentan los documentos vxml para gestionar versiones no-lineales empleando únicamente tecnología XML. El siguiente paso será re-diseñar el modelo de versionado genérico expuesto en el capítulo 3, en este caso, para aplicarlo sobre una fuente de datos concreta (documentos XML). Para ello se analizará si la estructura y las operaciones básicas descritas en el modelo genérico se pueden abordar con el modelo de datos grafo vxml propuesto en este capítulo.

147 Capítulo 6 Modelo de Documentos XML Versionados: vdocxml Contenidos 6.1. Modelo de Datos de Documentos XML Versionados: vdocxml Crear un Documento vxml Obtener una Versión Borrar una Versión Añadir Versión Obtener Diferencias Primitivas para la Actualización de un Grafo vxml Primitivas para la Actualización de un Documento vxml Composición de Primitivas Inserción de una Versión Consultas sobre Documentos vdocxml Conclusiones Todos los capítulos anteriores nos han servido para introducir y analizar en profundidad cada uno de los elementos fundamentales que van a componer nuestro modelo de datos de documentos XML versionados. Establecimos como punto de partida la denición de un modelo de datos genérico denominado vdoc para documentos de versionado, donde se presentó su estructura y las operaciones que pueden realizarse sobre él. Nuestro siguiente paso fue modelar mediante un grafo XML el tipo concreto de documentos XML. Basándonos en la idea de grafo XML denimos una nueva estructura, grafo vxml, para representar en ella múltiples versiones de un grafo XML y terminamos representando esta estructura como un documento XML que almacene todas las versiones, denominado documento vxml. En este capítulo aplicaremos el modelo de versionado genérico vdoc a los documentos XML, llamando a este nuevo modelo vdocxml, y presentaremos una implementación mediante documentos vxml. Dado que un documento vxml es equivalente a un grafo vxml utilizaremos indistintamente ambos términos a lo largo del capítulo. En la sección 6.1 se revisa el modelo de datos de documentos de versionado genérico vdoc para su aplicación a documentos XML, modelo que denominaremos vdocxml. El objetivo

148 130 Capítulo 6. Modelo de Documentos XML Versionados: vdocxml será comprobar si un grafo vxml puede ser utilizado como una implementación de este modelo para lo que es necesario vericar si la estructura y las operaciones denidas sobre un vdoc se pueden llevar a cabo sobre un grafo vxml. En cuanto a la estructura comprobaremos que el grafo de derivación se puede establecer a partir del árbol de versionado y que la identicación de los documentos asociados a las versiones se regirá a partir de la función de recuperación de información válida. Además en este apartado revisaremos cada una de las operaciones básicas descritas en el modelo de versionado: crear el conjunto de documentos de versiones con la versión inicial (el documento vacío) y las operaciones de añadir, eliminar y obtener una versión. En la sección 6.2 se estudia exclusivamente la operación de inserción pues el resto de operaciones se habrán mostrado en el apartado anterior. La operación de inserción de un documento, integrándolo con el resto de versiones almacenadas en el grafo vxml, consistirá en añadir la nueva versión al árbol de versionado y en incorporar los nuevos vértices y arcos al grafo vxml, con su correspondiente región de versionado, así como en adaptar la validez de los arcos de los elementos borrados. Para llevar a cabo esta última operación, y puesto que un grafo XML evoluciona en base a las primitivas de cambio descritas en el capítulo 4, se utilizará una herramienta de diferencias que se encarga de obtener las operaciones XML realizadas sobre el documento original y que producen el grafo XML destino. Este conjunto de operaciones ejecutado de forma atómica constituye la operación de inserción de una nueva versión. En la sección 6.3 se describe brevemente los dos niveles de consultas que se pueden establecer para los documentos vdocxml, a nivel de versión o a nivel de elementos, es decir, el objeto de consulta puede ser el documento propiamente dicho o los elementos XML que los constituyen. En este apartado únicamente presentaremos el conjunto de estas consultas postponiendo al capítulo 8 una semántica más detallada junto a los detalles de su implementación Modelo de Datos de Documentos XML Versionados: vdocxml En el capítulo 3 expusimos un modelo general, vdoc, de gestión de versiones sobre un documento, independientemente del tipo de documento. Llegados a este punto el modelo debe ajustarse a la semántica inducida por el contenido de los documentos a versionar, que en nuestro caso serán los documentos XML. Para el desarrollo del modelo de versionado vdoc para documentos XML se puede optar principalmente por tres soluciones: 1) un sistema que almacene cada instantánea o versión del documento individualmente y mantenga la relación entre las versiones del documento, 2) utilizar alguna de las técnicas clásicas para la gestión de versiones basadas en diferencias textuales 3) utilizar alguna técnica XML que integre todas las versiones en un mismo documento. Tal y como se presenta en [Wang 08], donde se realiza una comparativa de estas opciones, la primera solución dispara enormemente el requerimiento de almacenamiento y la segunda no permite consultar los documentos versionados, lo que nos conduce a seleccionar la solución de integración de las versiones. El principal problema de esta última solución es cómo fundir el almacenamiento de todos los documentos reaprovechando los contenidos comunes a varias versiones del documento. En el capítulo anterior, mostramos un modelo de datos vxml que resuelve este problema; este modelo será utilizado en el presente capítulo para implementar el modelo de datos vdoc

149 Modelo de Datos de Documentos XML Versionados: vdocxml 131 aplicado a documentos XML, lo que hemos denominado vdocxml. Denición 6.1. vdocxml: Un documento vdocxml, VX, es un documento vxml que representa la terna vdoc=(g, D, ρ) según el modelo vdoc de la siguiente forma: Si consideramos el grafo vxml gv=(v', E', root) asociado al documento VX formado por los subgrafos version_tree y versioned_doc, entonces: 1. G: Version_Tree representa al grafo G que muestra la relación de derivación de versiones. 2. ρ: La biyección ρ, que permite identicar los documentos a partir de los vértices del árbol de versionado, se identica mediante la operación de recuperación de información válida de un grafo vxml (sección 5.4.1), que permite extraer un documento a partir de su versión. 3. D: El conjunto de documentos almacenados d i D se obtiene a partir de la biyección anterior. A partir de esta denición denotaremos indistintamente un documento vxml y su documento XML versionado vdocxml. Figura 6.1: Documento XML versionado vdocxml=(g, D, ρ)

150 132 Capítulo 6. Modelo de Documentos XML Versionados: vdocxml Ejemplo: Un ejemplo de documento XML versionado vdocxml se muestra en la gura 6.1. En el plano superior se muestra la representación abstracta según el modelo vdoc de un documento con varias versiones v i y en el plano intermedio se muestra la representación concreta en documentos XML. En un primer momento cada una de las versiones se asocia a un documento XML por separado y con el uso del modelo vxml se fusionan en un único documento. Finalmente en el plano inferior se muestra la asociación de cada representación XML con su grafo correspondiente. Así cada documento XML esta asociado a un grafo XML y todos se integran en el grafo vxml que corresponde al documento vxml del plano superior. Al igual que en el modelo vdoc denimos un álgebra de operaciones consistente en: Creación de un documento vdocxml Obtención de un documento Eliminación de una versión asociada a un documento Inserción de un nuevo documento A continuación estudiaremos las operaciones anteriores para el caso vdocxml, exceptuando la operación de inserción que será analizada en la siguiente sección Crear un Documento vxml Denición 6.2. Create(vDocXML). La operación de creación de un documento vdocxml devuelve el documento vxml asociado al grafo vxml vacío que contiene únicamente la versión inicial de cualquier documento. Por tanto esta operación se implementa mediante la generación de un grafo vxml vacío, constituido por un conjunto de vértices iniciales y sus arcos asociados (sección 5.2), tal y como se muestra grácamente en la gura 6.2. Precondiciones: Ø Postcondiciones: Se crea el objeto vdocxml=(g, D, ρ), donde: G=({root, &0, &1, &V 0 }, {(root, &0), (&0, &V 0 ), (&0, &1), V 0 ), D = {d 0 } y ρ : v 0 ρ(v 0 ) = d 0. Ejemplo: En la gura 6.2 se muestra la estructura de un documento XML versionado vdocxml después de aplicar la operación Create(vDocXML). En el lado derecho de dicha gura se ilustra la representación gráca del grafo vxml resultante. Observaciones: Figura 6.2: Creación de un documento XML versionado vdocxml

151 Modelo de Datos de Documentos XML Versionados: vdocxml 133 La operación de creación a partir de un grafo XML se materializa en base a la siguiente composición de primitivas: Create(vDoc, d i ) = Create(vDoc) + Insert(vDoc, d i ), donde la operación Insert se analiza en el siguiente apartado. La operación de creación de un documento XML versionado se puede generalizar de modo que se puede utilizar con un conjunto nito de documentos {d i } i I. Todos ellos han derivado directamente a partir del documento vacío de la siguiente forma: Create(vDoc, {d i } i I ) = Create(vDoc) + {Insert(vDoc, v 0, d i )} Obtener una Versión i I Denición 6.3. GetDoc(vDocXML, v i ). Dada una versión v i V de un documento XML versionado vdocxml=(g, D, ρ), la función GetDoc(vDocXML, v i ) devuelve el documento XML asociado a la versión v i V. Precondiciones: (v i V ). Postcondiciones: Se obtiene el documento ρ(v i ) = d i D con el proceso de recuperación de información válida mostrado en el algoritmo 5.1 del capítulo 5. Para ello se realiza un recorrido por el grafo de versionado y para cada arco (e) del subgrafo Versioned_doc se comprueba, mediante la llamada a la función belongto (e.vv, v i ), si contiene la versión (v i ) requerida Borrar una Versión Denición 6.4. Delete-leaf(vDocXML, v i ). Dada una versión hoja v i V, es decir una versión de la cual no se ha derivado aún ninguna otra, se eliminará dicha versión v i del documento versionado vdocxml=(g, D, ρ), borrando el documento asociado d i D. Precondiciones: (v i V ) (Is_Leaf(v i )). Postcondiciones: Se obtiene el nuevo estado vdocxml'=(g', D', ρ ) del documento XML versionado vdocxml=(g, D, ρ), donde: G = (V {v i }, E {(parent(v i ), v i )}, v 0 ), D = D {d i } y ρ ρ /v i. Observaciones: 1. La expresión ρ ρ /v i se utilizará para indicar la función ρ eliminando del conjunto inicial los elementos indicados en la parte inferior, en nuestro caso eliminando v i. El proceso de borrado de una versión de un grafo vxml se muestra en el algoritmo 6.1, recursivo, que recibe como entrada el grafo vxml y la versión a borrar (v) y genera como salida el grafo vxml actualizado. El algoritmo consistirá en comprobar si los atributos de versionado end o start contienen la versión dada, en cuyo caso, se procede a su eliminación. El algoritmo comienza comprobando si el grafo vxml está vacío para, a continuación, si no es así, y una vez eliminado el vértice de la versión que se desea borrar del árbol de versionado, proceder al borrado de todos los vértices asociados a dicha versión en el documento versionado. De este modo, recorre todos los arcos descendientes no-ordenados (E A ) y ordenados (E E ) para el vértice raíz recibido por parámetro (en su primera ejecución el vértice &1 del grafo vxml)

152 134 Capítulo 6. Modelo de Documentos XML Versionados: vdocxml Algoritmo 6.1 Algoritmo de Borrado de una Versión Hija en un Grafo XML Delete-Leaf (G, v) //input: G: Grafo vxml //input v: Versión a borrar //output: G: Grafo vxml actualizado 1. begin 2. if outedge(g.&1)=ø //¾está vacío? 3. then () 4. else 5. version_tree = version_tree - {v} 6. Delete-Info(G, v, G.&1); 7. end_if; 8. end Delete-Info (G, v, raiz) //input raiz: Vértice E E. 9. begin 10. for each e in (outedges(raiz) E A ) do 11. if (v e.vv.end) and (count(e.vv.end)>1) then //v contenida en end 12. e.vv.end - {v} 13. else if (v e.vv.end) and (count(e.vv.end)=1) then //v contenida en end 14. e.vv.end=vnow 15. else if (v e.vv.start) then //v contenida en start 16. DeleteDataNode(G, raiz.value, e.name, 0) //Borrado de vértice data 17. end for; 18. for i=1 to card((outedges(v) E E )) do 19. e i = O(i, (outedges(v) E E )); 20. if (v e.vv.end) and (count(e.vv.end)>1) then 21. e.vv.end = e.vv.end - {v} 22. else if (v e.vv.end) and (count(e.vv.end)=1) then 23. e i.vv.end=vnow 24. end if; 25. if name(e)!=~data then //Si no es E E, borrado recursivamente 26. Delete-Info(G, v, e i.v2) 27. end if; 28. if (v e.vv.start) then // 29. DeleteElementNode(G, raiz.value) //Borrado del vértice element 30. end if; 31. end for; 32. end; comprobando este hecho. Por una parte, si el atributo end incluye el identicador de versión dado debe eliminarse de dicho atributo, existiendo dos posibles situaciones: 1) contiene más de un identicador de versión, siendo necesario en este caso eliminar exclusivamente dicho identicador del valor del atributo end (línea 3) 2) si contiene únicamente el identicador de versión dado, su valor es sustituido por el identicador de versión V now (línea 5), indicando, de este modo, que no existe una versión en la cual el arco haya sido borrado.

153 Añadir Versión 135 Por otra parte si el atributo start incluye el identicador de versión dado debemos eliminar físicamente del grafo vxml la información asociada, pues ésta fue añadida en la versión que se desea borrar. En el caso de un arco atributo se llama a la primitiva DeleteDataNode (línea 7) que se encarga de borrar dicho arco junto con el vértice destino. En el caso de un arco ordenado (elemento o data), antes de proceder a borrar el arco y el vértice, se procesan recursivamente todos sus nodos descendientes con el objetivo de borrarlos físicamente. Una vez que no existe ningún descendiente, se procede a borrar el vértice actual junto con el arco de entrada mediante la llamada a la función DeleteElementNode (línea 20). Nótese que en este apartado únicamente hemos analizado el borrado de una versión hoja del grafo de versionado. Su generalización, es decir, el borrado de cualquier versión, podría tener dos posibles casos: uno que consistiera en eliminar la versión dada junto con todas sus descendientes en cuyo caso habría que realizar un proceso de borrado recursivo desde las versiones hojas descendientes hasta la dada, y la segunda opción sería únicamente el borrado de la versión dada en cuyo caso sería necesario utilizar la función UpdateParent del modelo de versionado vdoc, la cual al igual que resto de operaciones avanzadas del modelo vdoc, no ha sido abordada en la presente tesis Añadir Versión Esta operación, inserción de una versión, permite añadir al grafo vxml un nuevo documento que deriva de un estado representado en el árbol de versionado y de su documento asociado almacenado en el subgrafo versioned_doc. De este modo, la operación de inserción de un documento, integrándolo con el resto de versiones almacenadas en el documento vxml, consistirá en añadir el nuevo identicador de versión dado al árbol de versionado y en incorporar los nuevos vértices y arcos al grafo vxml, con su correspondiente región de versionado, y en adaptar la validez de los arcos de los elementos borrados. Actualmente el único mecanismo comentado en esta tesis para que un documento XML pueda evolucionar es mediante la aplicación de las primitivas de cambio estudiadas en los capítulos anteriores. Sin embargo, la operación de inserción en vdoc toma como parámetros el documento asociado a la versión de partida y el documento en que se deriva, por tanto será necesario el uso de una herramienta que permita compararlos y de esta forma detectar los elementos borrados y los insertados, que denominaremos diferencias. Estas diferencias se traducirán en un conjunto de primitivas de cambio XML que ejecutadas de forma atómica, como una transacción de cambio, sobre el documento inicial permitirán obtener el documento destino. Figura 6.3: Insertar Versión en un documento vdocxml Teniendo en cuenta todos estos aspectos en la gura 6.3 se ilustra el esquema de funcionamiento de la operación de inserción de un documento. Como hemos mencionado previamente, utilizamos una herramienta de diferencias que obtiene los cambios entre el documento asociado

154 136 Capítulo 6. Modelo de Documentos XML Versionados: vdocxml a la versión v i de partida y el documento destino d j, como una secuencia de operaciones XML. Nótese que estas operaciones de diferencias/primitivas se ejecutarán realmente sobre el grafo vxml debiendo, de este modo, adaptar las regiones de versionado de los elementos afectados. En primer lugar comenzaremos esta sección describiendo el proceso de obtención de diferencias. A continuación, para facilitar el estudio de la ejecución de una transacción de cambio, analizaremos la inserción de versiones generadas por una única primitiva. Posteriormente consideraremos la ejecución de un conjunto de ellas para obtener la inserción de una versión y nalmente se realizará la denición de la operación de inserción junto con su algoritmo Obtener Diferencias Denición 6.5. GetDi(vDocXML, v i, d j ). Dada una versión v i V de un documento XML versionado vdocxml=(g, D, ρ) y un documento d j, la función GetDi(vDocXML, v i, d j ) obtiene las diferencias XML existentes entre el documento ρ(v i ) = d i D y el documento d j. Precondiciones: (v i V ). Postcondiciones: Se obtiene una secuencia de operaciones de primitivas de cambio XML las cuales permiten obtener el documento d j D a partir del documento ρ(v i ) = d i D mediante la aplicación de dichas primitivas. Esta secuencia de operaciones se puede expresar de la forma GetDi(vDocXML, v i, d j )= P i = {DE, DA, DC} + {UA, UC} + {IE, IA, IC} En general si los documentos d i D se denen a partir de un conjunto de elementos, deniremos las diferencias de dos documentos d i y d j como el conjunto de elementos que deben borrarse de d i y los que a continuación deben insertarse, para obtener el documento d j. En nuestro caso particular estos elementos son elementos, atributos y contenido, de modo que la secuencia de diferencia estaría formada por un conjunto de operaciones de borrado sobre elementos, atributos y contenido y un conjunto de inserciones de estos componentes. Además hemos considerado los casos especiales de actualización de atributos y contenidos como una secuencia situada entre los borrados e inserciones. Como se verá en el capítulo de implementación (7) se ha utilizado la herramienta jxydi[jxydi 06] para la recuperación de las diferencias entre dos documentos XML Primitivas para la Actualización de un Grafo vxml En este apartado se analiza la inserción de un nuevo documento constituido por una única diferencia/primitiva. Como mencionamos anteriormente la inserción de un nuevo documento debe en primer lugar añadir la versión al árbol de versionado y posteriormente actualizar el subgrafo versioned_doc a partir del cambio realizado. De este modo en este apartado analizaremos este proceso de actualización de un grafo vxml, de modo que se garantice que las regiones de versionado de los arcos afectados siguen siendo válidas una vez añadida la nueva versión. En la tabla 6.1 se muestra de forma resumida este proceso de actualización para cada una de las primitivas descritas en 4.2. Más concretamente, a continuación ilustramos este proceso de adaptación, donde se ha utilizado la siguiente notación: V cur para representar el identicador de versión actual y V new el identicador de versión de la nueva versión del documento:

155 Añadir Versión 137 Tabla 6.1: Actualización de un V-Edge a partir de un cambio Operación Descripción Arco.start Arco.end AddNode Crea un vértice y su V-Arco de New version now entrada asociado DeleteElementNode Borra un vértice junto a su arco de Sin cambio New version entrada y todos sus descendientes. UpdateData Node Borra un vértice junto con su arco de entrada. Sin cambio New version Un V-Arco es creado con el nuevo New version Now valor DeleteDataNode Un vértice data es borrado junto Sin cambio New version con su arco de entrada. Figura 6.4: Ejemplo de Actualización de un Grafo vxml AddNode: Operación que añade un nuevo vértice junto con su arco de entrada en el grafo XML. En un grafo vxml se procede a la creación de un V-Arco, junto con el vértice asociado, donde la región de versionado asociada tiene los siguientes valores VV=[V new - V now ]. Nótese que la posición indicada en esta operación se establece teniendo en cuenta exclusivamente los arcos válidos para la versión V cur, es decir, un determinado vértice del grafo versioned_doc puede tener n arcos de salida donde solamente algunos de ellos son válidos para la versión a modicar de modo que el parámetro posición de esta primitiva sólo se determina en base a los arcos válidos de la versión a modicar.

156 138 Capítulo 6. Modelo de Documentos XML Versionados: vdocxml DeleteElementNode: En un grafo vxml requiere la actualización de la validez de versionado tanto del arco de entrada del vértice dado como de todos sus descendientes. Este proceso añade el nuevo identicador de versión V new al atributo end indicando, de este modo, que los arcos afectados han dejado de ser válidos en esta versión. Nótese que pueden existir dos posibles situaciones: 1) Si el atributo end contiene ya algún otro identicador de versión, sólo es necesario añadir el identicador V new a la lista de identicadores 2) Si el atributo end contiene el identicador V now, éste es sustituido por el nuevo identicador de versión. UpdateDataNode: Operación que actualiza el valor de un vértice data, es decir, el arco que enlaza con el valor actual deja de ser válido en la versión dada (añadiendo el identicador de la nueva versión al atributo end) y además es necesario generar un nuevo vértice con el nuevo valor cuyo arco tenga la región de versionado [V new - V now ]. DeleteDataNode: Elimina del grafo XML un vértice data. En un grafo vxml requiere de un borrado lógico del arco que une al vértice data, es decir, se añade el nuevo identicador de version al atributo end. En la gura 6.4 se muestran algunos ejemplos de actualización donde se han generado distintas versiones del grafo XML de restaurantes usado como ejemplo anteriormente. Así, por ejemplo, en la versión V 2 se ha añadido un nuevo atributo, por lo que la región de versionado del nuevo arco ha pasado a tener la validez [V 2 -V now ] o en la versión V 5 se ha actualizado el contenido asociado al vértice &4. Esta última operación genera un nuevo varco, para el nuevo valor, con la validez [V 5 -V now ] y adapta el varco actual a la validez [V 1 -V 5 ], tal y como se ilustra en dicha gura Primitivas para la Actualización de un Documento vxml En el apartado anterior analizamos los cambios que habría que realizar en las regiones de versionado sobre un grafo vxml. En este apartado estudiaremos este proceso de adaptación para el caso de un documento vxml. Así en la tabla 6.2 se muestra de forma resumida cómo debe adaptarse la validez de versionado de los elementos afectados dependiendo de la primitiva ejecutada en la transacción. De este modo, por cada operación se ilustra qué acción se desencadena en el documento vxml, así como la modicación de los valores de los atributos v:start y v:end de los elementos afectados. Con el objetivo de familiarizarnos mejor con este mecanismo hemos decidido enmarcar este proceso dentro de un ejemplo más completo. Para ello hemos seleccionado el mismo grafo de cambio del capítulo 5 sobre el grafo XML de restaurantes, pero esta vez aplicado a documentos XML, tal y como se presenta en la gura 6.5. A continuación se muestran las operaciones relizadas sobre el documento vxml, para obtener el mismo documento vxml mostrado en la gura 5.13: V 1 -> V 2, IA(6,cur, ): Añade un nuevo atributo (elemento v:attrib) para el elemento idf 6 con la región de versionado [V 2, {V now }]. V 2 -> V 3, UC(5,Italian,1) e IE(3,street,4): Estas dos operaciones se encargan de actualizar el contenido del elemento 5 y añadir un nuevo elemento en la posición 4 del

157 Añadir Versión 139 Tabla 6.2: Actualización de un Documento vxml Operación Descripción v:start v:end IE DE IA DA UA IC DC UC Crea un elemento XML con su región de versionado New version Vnow Borrado lógico de un elemento XML y todos sus descendientes. Sin cambio New version Añade un elemento v:attrib al documento vxml New version Vnow Elimina un atributo (v:attrib) del documento vxml Sin cambio New version Actualiza un atributo v:attrib Actual Sin cambio New version v:attrib Nuevo New version Vnow Añade un contenido a un elemento XML (v:data) New version Vnow Elimina el contenido (v:data) de un elemento XML Sin cambio New version Actualiza el contenido Contenido Actual Sin cambio New version Contenido Nuevo New version Vnow elemento con identicador 3. La primera operación provoca que el elemento v:data actual deje de ser válido en la versión V 3 (atributo v:end={v 3 }) y se genere un nuevo elemento v:data con el nuevo valor cuya validez sea VV=[V 3, {V now }]. La segunda operación añade un nuevo elemento XML con región de versionado VV=[V 3, {V now }] en la posición 4. V 3 -> V 4, IC(7,Paris 10,1): Añade el contenido París 10 al elemento XML creado en el apartado anterior. Esta operación conlleva la creación de un elemento XML v:data cuya validez es VV=[V 4, {V now }] y cuyo contenido es la información textual a añadir al elemento XML. V 2 -> V 5, UC(4, Sea,1): Primera versión alternativa de la versión V 2. Hay que actualizar la región de versionado del v:data actual como VV=[V 1, {V 5 }] y la creación de un elemento v:data para el nuevo contenido VV=[V 5, {V now }]. V 2 -> V 6, DC(4,1): Segunda versión alternativa de la versión V 2. Elimina el elemento v:data válido para la versión V 2 del elemento XML para el elemento 4. Nótese que actualmente existen dos versiones para el contenido del elemento 4 (sea y seafood), de modo que la primitiva debe seleccionar aquella que es válida para la versión V 2 (seafood). Como se trata de una operación de borrado se añade al atributo v:end el identicador de versión de la nueva versión V 6, VV=[V 1, {V 5 V 6 }]. V 5 -> V 7, UA(6,Cur, Euro): Actualiza el valor del atributo Cur al valor Euro. Al tratarse de una operación de actualización, el elemento v:attrib actual es borrado lógicamente ([V 2, {V 7 }]) mientras que el nuevo elemento v:attrib con el valor actualizado tiene la siguiente región de versionado VV=[V 7, {V now }].

158 140 Capítulo 6. Modelo de Documentos XML Versionados: vdocxml Figura 6.5: Cambios Ramicados en un Documento XML V 6 -> V 8, DA(4,Cur): Elimina el atributo Cur del elemento XML identicado por 4. Nótese que actualmente este elemento v:data tiene como validez de versionado VV=[V 2, {V 7 }], pues ha sido actualizado en la versión V 7, siendo su nueva validez VV=[V 2, {V 7 V 8 }]. V 3 -> V 9, DE(3): Elimina el elemento XML 3 junto con todos sus descendientes, es decir, en un grafo vxml supondría que todos los elementos XML descendientes, inclusives los v:data y v:attrib afectados, deben añadir al atributo end el valor V 9. V 6 -> V 10, UC(5,French,~data,1): Actualiza el contenido asociado al elemento 5. La región de versionado para el v:data quedaría con el valor VV=[V 1, {V 3 V 10 }] mientras que el nuevo elemento XML tendría la validez siguiente VV=[V 10, {V now }]. Nótese que la ejecución de estas primitivas se realiza en un documento vxml para una versión concreta, de modo que a la hora de ejecutar estas primitivas se tienen únicamente en cuenta aquellos componentes XML que son válidos para la versión V cur. Esta situación se puede

159 Añadir Versión 141 comprobar, por ejemplo, en la operación de inserción realizada en el paso de la versión V 2 a la versión V 3 donde la posición se determina no en base al número de elementos descendientes del elemento 3 sino en base a aquellos elementos válidos para la versión V 2 que son descendientes de Composición de Primitivas Cuando sobre un grafo XML o un documento XML se realizan cambios, la nueva versión no se genera exclusivamente como resultado de la ejecución de una primitiva individual sino a partir de un conjunto de ellas; a esto se le denomina composición de primitivas. Esta ejecución de primitivas se caracteriza por su secuencialidad, así la ejecución de una primitiva depende de las anteriores; además, debe ser atómica, como una transacción de cambio sobre el documento vxml, donde o se ejecuta por completo o no se realiza ninguna acción. A continuación analizaremos diversos factores que deben tenerse en cuenta para que el documento vxml siga estando bien formado una vez añadida la nueva versión. En primer lugar, el sistema de versionado debe disponer de una herramienta que garantice que no existen inconsistencias en la secuencia de primitivas. Para ello es necesario un algoritmo que analice los cambios a ejecutar y detecte las posibles anomalías, algoritmo similar a las herramientas de validación incremental usadas en [Guerrini 07]. Nos gustaría resaltar que esta situación no se producirá en nuestro sistema de versionado pues la herramienta de diferencias utilizada genera una secuencia atómica de cambios no inconsistentes. Esta secuencia establece en primer lugar las operaciones de borrado y actualización sobre el documento origen para posteriormente representar las operaciones de inserción sobre el documento destino. En segundo lugar, puesto que la transacción se realiza de forma secuencial, la ejecución de una determina primitiva P i debe tener en cuenta todas las primitivas anteriormente ejecutadas P j, j < i. Mediante un ejemplo reejaremos la problemática inducida por esta secuencialidad: supongamos que tenemos el grafo XML de restaurantes, en su representación vxml para la primera versión, y realizamos la siguiente transacción: DE (4) +IE(3, -, 2) + IE(3, -,2) siendo la secuencia de ejecución sobre el elemento XML rest tal y como se muestra a continuación (recordamos que el elemento XML rest tiene tres hijos descendientes en el siguiente orden: name, menu y price): La primera operación elimina el primer hijo descendiente de rest, name, estableciendo su validez en VV=[{V 1 }-{V 2 }]. A continuación se procede a la inserción de un nuevo elemento en la posición 2 para el elemento rest. Si aplicamos el proceso expuesto en el último párrafo de la anterior sección donde se expone que las primitivas se ejecutan en base a los elementos válidos para la versión actual (V 1 ), el elemento name, que ha sido borrado previamente, seguiría siendo válido para la versión V 1 y por tanto se insertaría entre los elementos name y menu cuando debería ir en entre los elementos menu y price. Finalmente se ejecuta una nueva inserción en la posición 2, existiendo el mismo problema que en el caso anterior donde no se tiene en cuenta ni el borrado ni la inserción anterior. Este problema se ha resuelto fácilmente en nuestra técnica pues debemos tener presente que según se van ejecutando las primitivas se van actualizando las regiones de versionado de los arcos afectados. Así, para el correcto funcionamiento de este proceso debemos establecer la validez de los elementos del grafo vxml en el proceso de actualización, en lugar de la versión

160 142 Capítulo 6. Modelo de Documentos XML Versionados: vdocxml actual como hemos expuesto anteriormente, en base a la nueva versión (V 2 ). De este modo, en el ejemplo anterior cuando se procede a ejecutar la segunda primitiva (insertar), vericaríamos qué elementos son válidos para V 2, comprobando que el primer elemento, name, ya no es válido y estableciendo su posición entre menu y price. Obviamente esta solución plantea el problema de una transacción no nalizada donde algunas regiones de versionado ya han sido actualizadas y el estado ha sido añadido al árbol de versionado. En este caso, al igual que en las bases de datos, se retornaría al documento vxml anterior. Hemos establecido este punto de retorno en base a un nuevo atributo en el árbol de versionado de modo que cuando empieza la transacción se establece un valor y cuando naliza se elimina dicho atributo. De este modo, antes de realizar la inserción de un nuevo documento se verica si el documento vxml es consistente, en base a este atributo, y en caso de no cumplir esta propiedad se procedería al borrado del estado inconsistente usando el algoritmo de borrado expuesto anteriormente. Algoritmo 6.2 Algoritmo de Inserción de un nuevo Documento AddVersion (Dv, v cur, v new, Doc) //input: Dv: Documento vdocxml //input V cur : Identicador de versión actual //input V new : Nuevo identicador de versión //input: Doc Documento XML modicado a partir de la versión GetDoc(Dv, V cur ) // output: Dv: Documento vdocxml actualizado begin 1. if (v=dv.checkintegrity())!=null) then 2. Delete-Leaf (DV, v) 3 else begin 4. di=getdi(getdoc(gv, V cur ),Doc) 5. start_transaction(); 6. version_tree= version_tree + {V new } 7. for each e in di 8. switch (e): 9. case (IE): IE(e.idf, e.name, e.pos) 10. break; 11. case (DE): DE(e.idf) 12. break; 13. case (IA): IA(e.idf, e.name, e.value) 14. break; end switch; 17. end for; 18. end_transaction(); 19. endif; end;

161 Consultas sobre Documentos vdocxml Inserción de una Versión Denición 6.6. Insert(vDocXML, v i, d j ). Añade una nueva versión al documento XML versionado vdocxml=(g, D, ρ), cuyo documento asociado es d j y que se ha derivado a partir de la versión v i. Precondiciones: (d j / D) (v i V ). Postcondiciones: Se obtiene el nuevo estado vdocxml'=(g', D', ρ ) del documento versionado vdocxml=(g, D, ρ). Esta operación se materializa mediante dos suboperaciones: ˆ Adición de la nueva versión al árbol de versionado: G = (V T {v j }, E {(v i, v j )}, v 0 ), D = D {d j } y ρ [ρ (v j ρ(v j ) = d j )]. ˆ Actualización del grafo vxml siguiendo las pautas descritas anteriormente por cada una de las operaciones obtenidas por la herramienta de diferencias. El proceso de inserción de un nuevo documento se ilustra en el algoritmo 6.2 donde comprobamos que se realiza en dos fases: 1) se añade la nueva versión al árbol de versionado y 2) ejecución de las primitivas de cambio XML obtenidas por la herramienta de diferencia. En este caso dependiendo de la diferencia obtenida se procede a la llamada de la primitiva en cuestión. En este algoritmo también hemos mostrado el concepto de transacción expuesto anteriormente de modo que cuando comienza el algoritmo se establece una marca en el documento vxml (línea 5) que reeja este hecho y es eliminada cuando naliza correctamente (línea 18). En el caso que la transacción no nalice correctamente, en la próxima inserción de una versión se detecta mediante la función Dv.checkIntegrity() y se corrige mediante la llamada al proceso de borrado de una versión Consultas sobre Documentos vdocxml Uno de los aspectos más importantes sobre todo modelo para la gestión de versiones es la facilidad que éste debe presentar para poder realizar consultas ecientes sobre los documentos versionados. Tal y como expusimos al principio de esta memoria se pueden establecer principalmente dos niveles: consultas sobre cada versión y consultas sobre los elementos. El modelo propuesto en esta tesis favorece ambos tipos de consultas como a continuación se analiza y posteriormente en el capítulo 8 se muestra a nivel práctico usando distintos lenguajes estándar de consultas XML. Por una parte consideramos las consultas sobre cada versión como aquellas que permiten obtener una versión del documento vdoc en relación con el resto de versiones, es decir, en este caso el objeto de consulta son los distintos documentos XML propiamente dichos. Dentro de este grupo se podrían establecer principalmente consultas como: obtener la información válida, documento XML, de una determinada versión ó la comparación de dos versiones de un documentos XML representadas en el documento vdoc. En este capítulo, sección 6.1.2, hemos ilustrado la consulta más habitual dentro de este nivel que consiste en recuperar la información válida de una determinada versión del documento. La operación de diferencias de versiones la estudiaremos a nivel práctico en el capítulo 8 de consultas. De otra parte, las consultas sobre los elementos debe permitirnos establecer consultas sobre los distintos elementos XML que forman parte de un documento vxml. Nótese que

162 144 Capítulo 6. Modelo de Documentos XML Versionados: vdocxml en el caso de las consultas sobre un elemento e de un documento XML no versionado, éstas siempre se realizan respecto del resto de elementos del documento, y los lenguajes estándar de consulta XML nos permite expresar una extensa gama de estas consultas utilizando los mecanismos de comparación y acceso que proporciona el uso de expresiones. En cambio, en la dimensión de versionado, un elemento e de un documento XML de una determinada versión, estará determinado por su identicador e/@idf y por el identicador/es de la versión del documento XML en el que se encuentra e/@vv. En este caso, al estar representado en un documento vxml no sólo se puede comparar con los elementos del documento XML asociado a dicha versión, sino que también podemos realizar otros tipos de consultas como: las relativas a otras versiones relacionadas de algún modo con la actual, por ejemplo determinar la region de versionado asociada al elemento, o las versiones que se derivan de la actual, y en segundo lugar las relativas al elemento e referido a otros elementos de otras versiones, por ejemplo, determinar la versión descendiente de la actual en la que el elemento e tenga el mayor número de hermanos. Esto abre un mundo de posibilidades para poder consultar estos documentos muy amplias, que vendrá determinado en cierta forma por el lenguaje de consulta XML utilizado. Por este motivo hemos decidido mostrar este tipo de consultas en el capítulo 8 usando lenguajes de consultas XML concretos. De este modo la dimensión de versionado permite considerar predicados de consulta sobre el elemento e respecto de su historia de versionado y los documentos de cada versión según la información que aparece reejada en el documento vdocxml. En dicho capítulo se explorarán algunas de estas operaciones de consulta, que representan una extensión del lenguaje de consulta XQuery para esta nueva dimensión, y que denominaremos vquery. En concreto se proponen las siguientes extensiones: Predicados sobre el versionado, que permitan plantear condiciones de recuperación sobre la dimensión de versionado. Operaciones de consultas sobre los elementos. De las que hemos destacado tres tipos habituales en el contexto de versionado: ˆ Evolución histórica de un determinado elemento e del documento XML, lo que se conoce en las base de datos temporales como proyección. Y que en nuestro caso, permitirá recuperar el conjunto de versiones en que es válido un elemento y los valores que toma en cada versión. ˆ Recuperación de la información de un elemento válido para una versión, conocido como instantánea de un elemento. ˆ Recuperación de los elementos válidos para un rango de versiones dado, que se denomina consultas por rangos. Operaciones de inserción, borrado y modicación sobre los elementos, referidos a una versión del documento Conclusiones En el capítulo 3 se propuso un modelo de versionado genérico, independiente de la semántica del documento a versionar, donde se estableció una estructura y un conjunto de funciones

163 Conclusiones 145 que nos ayudaban a mantener y gestionar las versiones existentes. En este capítulo hemos aplicado este modelo a un tipo de documento concreto, los documentos XML, y hemos presentado una implementación usando el modelo de datos vxml. Así, en los distintos apartados hemos demostrado como la estructura y las distintas operaciones del modelo vdoc se pueden trasladar al modelo vxml. El modelo nal obtenido al aplicar el modelo vdoc a los documentos XML lo hemos denominado vdocxml. Además hemos revisado cada una de las operaciones básicas del modelo vdoc para el caso de documentos XML, la creación de un documento vdocxml y las operaciones de obtener, borrar y añadir una versión. Nótese que en el capítulo 3, sobre el modelo de versionado genérico, se propusieron un conjunto de funciones avanzadas que ayudaban a mantener y gestionar las versiones existentes en un documento versionado. Estas funciones avanzadas no han sido implementadas en el modelo vdocxml y quedan como una de las propuestas de trabajo futuro. Finalmente, se ha descrito el conjunto de operaciones que permitirán realizar operaciones de consulta, inserción y borrado a nivel de elementos de un documento XML, extendiendo las operaciones habituales sobre un documento XML a la dimensión del conjunto de versiones disponibles para dicho documento. En los siguientes capítulos mostraremos la facilidad que ofrecen los documentos XML versionados para su consulta mediante distintos estándares XML y la implementación de un sistema de versionado, basado en el modelo vdocxml, usando para ello exclusivamente tecnología XML.

164 146 Capítulo 6. Modelo de Documentos XML Versionados: vdocxml

165 Módulo III Prototipos y Experimentación

166

167 Capítulo 7 Diseño de un Sistema de Versionado basado en vdocxml Contenidos 7.1. Diseño del Sistema Diseño Funcional del Sistema Diseño para la Gestión de Transacciones Diseño del Sistema Gestor Módulos XSLT Módulos XQuery Uso con Procesadores XQuery Extensión de una Base de Datos Nativa XML con Versionado Conclusiones En los capítulos previos hemos denido un modelo para la representación y gestión de versiones de documentos XML. Ahora abordaremos la validación del modelo mediante la construcción de un sistema gestor de vdocumentos y su posterior validación. Como principales características de este sistema podemos destacar el uso exclusivo de estándares XML y software abierto. En este capítulo 7 diseñaremos la arquitectura general del sistema, mientras que en el capítulo 8 mostraremos detalles de su construcción. Finalmente en el capítulo 9 se valida el sistema tanto a nivel de especicación y de rendimiento, mediante baterías de tests, como a nivel de desarrollo extendiéndolo con distintos interfaces de usuario. En la sección 7.1 se presenta un diseño genérico del sistema propuesto para la gestión de versiones de documentos de marcado XML. Además, se diseña la representación de una transacción para denir el gestor de transacciones del sistema. El sistema se basa en una arquitectura multicapa formada por tres componentes: la capa de presentación, en la que se desarrollarán las interfaces de usuario, el sistema gestor, núcleo de sistema, encargado real de la gestión de las versiones y, nalmente, la capa de datos, donde se almacenan todos los documentos, versionados o no, así como los cheros logs y de transacciones. Tras el diseño funcional del sistema global, esta sección termina analizando la gestión de Transacciones. Para ello se introduce el documento sigmod.xml que servirá de ejemplo a lo largo de este

168 150 Capítulo 7. Diseño de un Sistema de Versionado basado en vdocxml bloque de implementación y como base para las pruebas de rendimiento. A partir de un ejemplo, se diseña la estructura de datos, representada como un documento XML denominado documento XML transaccional, que permite representar los cambios realizados en una versión para obtener otra derivada. En nuestro caso, el documento XML transaccional se obtendrá a partir de una herramienta de diferencias XML denominada JXyDi [jxydi 06]. En la sección 7.2 se proponen dos técnicas de construcción del sistema gestor descrito en el apartado anterior. La primera de ellas usa hojas de estilo XSLT mientras que la segunda utiliza el lenguaje de programación XQuery. Usando esta última implementación, indicaremos cómo puede extenderse una base de datos nativa XML (en nuestro caso exist [Exist. 01]), con el modelo de versionado vdocxml. El sistema gestor de versiones servirá de conexión entre el nivel de aplicaciones y el de almacenamiento, y su diseño se presenta como un conjunto de módulos cuyo núcleo central es el módulo Version que proporciona la API pública para la gestión de versiones de documentos XML. En el siguiente capítulo se mostrará en detalle la programación de todos los módulos que se proponen en este diseño, destacando de entre todos el módulo vquery pues permite extender XQuery de forma que soporte consultas a nivel de elementos sobre documentos de versionado y consultas de rango que serán las operaciones que se utilicen para las baterías de test Diseño del Sistema En este apartado se presenta una arquitectura funcional genérica del sistema de versionado propuesto para la gestión de versiones de documentos de marcado XML. En primer lugar describiremos el funcionamiento del sistema para posteriormente abordar uno de los principales escollos de todo sistema de versionado: la gestión de transacciones. Como vimos en el apartado anterior a la hora de actualizar una versión, esta operación no se realiza exclusivamente en base a una primitiva sino en un conjunto de ellas que se ejecutan como una transacción. En el capítulo 6 describimos el funcionamiento de la transacción y en este apartado mostramos cómo se ha diseñado Diseño Funcional del Sistema El sistema propuesto se basa en una arquitectura multicapa formada por tres componentes: la capa de presentación, el sistema gestor y la capa de datos (gura 7.1). La capa de presentación se encarga de proporcionar a los usuarios el acceso, navegación, consulta y edición de los documentos tanto de marcado XML como de documentos XML versionados. Su objetivo será proporcionar al usuario nal una aplicación intuitiva y fácil de utilizar para el manejo de sus versiones. En general, incluiremos en esta capa, las aplicaciones de usuario que utilicen documentos versionados y cuya gestión se realice a través de las API que proporcione el sistema gestor de versiones. El sistema gestor de versiones es la capa intermedia encargada de gestionar las operaciones sobre versiones de documentos XML. La capa de datos se encarga de almacenar los documentos XML y documentos XML versionados así como de los cheros logs con los cambios realizados en cada una de las versiones de los documentos.

169 Diseño del Sistema 151 Figura 7.1: Arquitectura Genérica del Sistema de Versionado El funcionamiento del sistema propuesto, enumerado en la gura 7.1, es el siguiente: 1. Almacenamiento (1): El usuario proporciona al sistema los documentos XML y determinará cuales de ellos se van a encontrar sujetos a cambio. Es en este último caso cuando se convierte un documento XML a vxml con la incorporación de la información de versionado. 2. Actualización (2): Una vez que se han almacenado los documentos vxml en el repositorio, el usuario puede proceder a su actualización mediante las primitivas de cambio expuestas en el capítulo 4. Una vez ejecutadas las operaciones oportunas, que actualizan el documento vxml afectado, éstas se almacenan dentro del repositorio de registro de cambios (logs). 3. Consulta (3a, 3b): Los usuarios pueden recuperar la información almacenada en los documentos XML (3b), en los documentos vxml (3b) y en el chero de logs (3a). El paso segundo, sin duda alguna, es el más importante y crítico de todos ellos pues se encarga de actualizar el documento vxml. Hasta el momento el único mecanismo disponible para esta operación es especicando directamente qué operaciones de cambio queremos ejecutar. Obviamente esta solución no es factible y operativa para un sistema de versionado real de modo que hemos decidido utilizar en el sistema de versionado propuesto una herramienta de diferencias con el objetivo que el sistema sea más operativo. De este modo la herramienta detecta qué cambios se han realizado entre dos versiones de un mismo documento y posteriormente se actualiza el documento vxml a partir de los cambios obtenidos. Esta actualización, tal y como vimos en el capítulo 6, se basa en el concepto de transacción que es un conjunto de operaciones elementales ejecutadas como una unidad. Para conseguir

170 152 Capítulo 7. Diseño de un Sistema de Versionado basado en vdocxml Figura 7.2: Documento acm.xml y Esquema de documentos ACM este objetivo hemos representado cada una de las primitivas de cambio de un documento XML en formato XML de modo que las diferencias obtenidas se transforman directamente a esta plantilla de cambio que será lo que realmente ejecute el sistema de versionado, siguiendo las pautas de actualización de un documento vxml descritas en la sección Diseño para la Gestión de Transacciones En este apartado se muestra el formato de un documento XML de cambio para posteriormente exponer cómo se ha realizado la integración de una herramienta de diferencias en el sistema propuesto. Comenzamos el apartado mostrando el documento de trabajo que seguiremos como ejemplo en este bloque de desarrollo y experimentación del prototipo (capítulo 7, 8 y 9) con el objetivo de familiarizarnos con él Documento de Trabajo Sigmod.XML El documento de trabajo es el chero de registros de ACM en su formato XML (obtenido de [ACM 02] - noviembre 2002). Se ha optado por dicho chero, en lugar de utilizar el ejemplo simple de restaurantes seguido hasta ahora, porque proporciona todas las características que nos permitirán la evaluación de nuestra técnica: dispone de un tamaño relativamente grande, cuenta con una estructura ja y es fácilmente localizable en la red. Este chero será posteriormente usado para formalizar las consultas del capítulo 8 y analizar el rendimiento del sistema en el capítulo 9. La gura 7.2 muestra la representación gráca del esquema asociado al documento ACM junto con un pequeño ejemplo de documento XML basado en dicho esquema. Hemos decidido re-adaptar este documento a un caso concreto, más familiar para nosotros, que nos permita

171 Diseño del Sistema 153 comprender mejor los resultados de las consultas. Como se puede comprobar en dicha gura, un documento ACM se encuentra formado por un elemento raíz denominado SigmodRecord el cual tiene un elemento hijo issues. Este último puede contener uno o varios elementos issue formados por los elementos volume, number y articles, los cuales almacenan toda la información relevante sobre los autores de unas publicaciones. Figura 7.3: Documento acm.xml con Versiones. acm.vxml o sigmod.vxml La gura 7.3 muestra el documento vxml obtenido tras realizar una serie de modicaciones sobre el documento de partida. Algunos de los cambios realizados son: en la versión V 2 se ha añadido un nuevo elemento author, el valor del primer author se ha modicado en las versiones V 3 y V 10 y se ha borrado en V 9 o el atributo del segundo author, creado en V 2, se ha modicado en la versión V 5 y borrado en la versión V 9. En la versión V 9 se ha borrado el elemento identicado d1e9, borrando con ello todos sus descendientes. Nótese que este árbol de versionado coindice con el ejemplo del restaurante usado hasta ahora con el objetivo de no variar el grafo de derivación Documento XML Transaccional Como se ha comentado anteriormente, la creación de una nueva versión en el sistema propuesto se va a denir en base a una secuencia de primitivas de cambio (tabla 4.4) representadas en un documento XML con cambios, denominado documento XML transaccional. Tal y como sucede en las bases de datos con el concepto de transacción, un documento vxml es actualizado si y sólo si todos los cambios son ejecutados correctamente. En la gura 7.4 se muestra el esquema de un documento XML transaccional 1. En ella 1

172 154 Capítulo 7. Diseño de un Sistema de Versionado basado en vdocxml podemos comprobar que un documento XML transaccional se encuentra formado por una o varias versiones (etiqueta n_version) donde cada versión puede estar a su vez constituida por una única operación o por un conjunto de ellas. Nótese que cada uno de los parámetros de estas primitivas de cambio (tabla 4.4) se denen como atributos de los elementos XML asociados. Figura 7.4: Esquema de un Documento XML Transaccional En la gura 7.5 se muestra el documento XML transaccional equivalente al grafo de cambios descrito en el ejemplo ACM Sigmod (gura 7.3). El primer cambio representado en este documento es una operación de InsertarElemento (IE) para el nodo identicado por el path /*[1]/*[1]/*[1]/*[3]/*[1]/*[2] (d1e12) que añade un nuevo author para el elemento authors en la posición 2. En la siguiente versión denida en el documento XML transaccional (V 3 ) se actualiza el contenido del primer author del documento acm.xml. Y así sucesivamente para el resto del documento transaccional. Nos gustaría resaltar que los nodos sobre los cuales se aplica la primitiva del documento XML transaccional pueden especicarse bien mediante el camino en XPath hacia el nodo o bien mediante el identicador único de elemento. Nótese que en la tabla 4.4 establecimos que los nodos de estas primitivas se identicaban exclusivamente en base a su identicador, sin embargo hemos añadido esta otra posibilidad por la facilidad que aporta para su importación desde la herramienta de diferencias. De este modo, si la primitiva de cambio contiene un atributo path indica que la identicación del elemento se basa en su camino XPath mientras que si tiene un atributo idf la identicación se realiza en base a dicho valor. 1. nidf Si no se recibe, lo calcula el sistema de versionado 2. name. En la implementación del sistema, el elemento XML se representa como un hijo de la etiqueta IE

173 Diseño del Sistema <changes source ='/db/users/ljarevalo/acm.vxml'> 2 <n_version dim_now ='V1' new_v ='V2'> 3 <IE path ='/*[1]/*[1]/*[1]/*[3]/*[1]/*[2]' pos ='2'> 4 <author AuthorPosition ='3'/> 5 </IE> 6 </n_version> 7 <n_version dim_now ='V2' new_v ='V3'> 8 <UC path ='/*[1]/*[1]/*[1]/*[3]/*[1]/*[2]/*[1]' ctx ='Luis J. Arevalo' pos='1'/> 9 </n_version> 10 <n_version dim_now ='V3' new_v ='V4'> 11 <IC path ='/*[1]/*[1]/*[1]/*[3]/*[1]/*[2]/*[2]' ctx ='Antonio Polo' pos='1'/> 12 </n_version> 13 <n_version dim_now ='V2' new_v ='V5'> 14 <UA name ='AuthorPosition' value ='2' path ='/*[1]/*[1]/*[1]/*[3]/*[1]/*[2]/*[2]'/> 15 </n_version> 16 <n_version dim_now ='V2' new_v ='V6'> 17 <IA name ='alias' value ='Luigy' path ='/*[1]/*[1]/*[1]/*[3]/*[1]/*[2]/*[1]'/> 18 </n_version> 19 <n_version dim_now ='V5' new_v ='V7'> 20 <DC path ='/*[1]/*[1]/*[1]/*[3]/*[1]/*[1]' pos='1'/> 21 </n_version> 22 <n_version dim_now ='V6' new_v ='V8'> 23 <DA name ='alias' path ='/*[1]/*[1]/*[1]/*[3]/*[1]/*[2]/*[1]'/> 24 </n_version> 25 </changes> Figura 7.5: Documento XML Transaccional Integración de una Herramienta de Diferencias XML En el capítulo 2 expusimos las principales herramientas de diferencias XML y se analizó: la complejidad de computación del algoritmo usado, el tipo de algoritmo, el tamaño de memoria requerido, el chero delta generado, las operaciones que es capaz de realizar, etc. Partiendo de este estudio, hemos seleccionado como herramienta de diferencias JXyDi [jxydi 06] pues esta proporciona todas las características deseables de nuestro sistema: 1) maneja todo tipo de nodos XML y detecta operaciones como desplazamiento de nodos o actualizaciones, 2) está implementada en Java (pudiendo ser usada, como se verá posteriormente, para extender una base de datos nativa XML) y 3) las diferencias generadas en formato XML son fácilmente adaptables a nuestro formato XML transaccional mediante un script XQuery/XSLT. JXyDi [jxydi 06] es la implementación en Java de XyDi [Cobena 02]. El algoritmo, tal y como se expone en [Hedeler 08], consta de los siguientes pasos: Preprocesamiento: Se calcula el valor hash empezando desde los nodos hojas en base al contenido del mismo nodo y el valor hash de sus hijos. De manera similar a X- Di [Wang 03c], el valor hash de un nodo representa el subárbol entero de dicho nodo. Además del valor hash, se calcula un peso por cada nodo de la siguiente forma: para un nodo texto el peso es el tamaño de su contenido y para un nodo elemento el peso es la suma de todos los pesos de sus nodos hijos. Los distintos subárboles, representados por su nodo raíz, son insertados en una cola de prioridad en la que se clasican por su peso.

174 156 Capítulo 7. Diseño de un Sistema de Versionado basado en vdocxml Comparación (Matching): Comienza por el subárbol con más peso del documento destino (cuando hay varios subárboles con el mismo peso, el primero de la cola es el seleccionado). A continuación los nodos con el mismo valor de hash (que representan a todo el subárbol que cuelga de ese nodo) se identican en el documento origen. Si sólo hay un nodo en el documento origen con el mismo valor de hash, existe coincidencia. Si no hay nodos con el mismo valor de hash y se trata de un nodo elemento, sus hijos se insertan en la cola de prioridad (detectar movimientos). Si hay varios nodos con el mismo valor de hash, el nodo cuyo padre coincide con el padre del nodo del documento actualizado se selecciona. El siguiente paso después del proceso de coincidencia es una una fase de optimización en la cual los nodos coincidentes se usan para propagar la comparación hacia los nodos no-coincidentes. Durante esta fase, los nodos se consideran coincidentes si sus padres y / o hijos son coincidentes y tienen la misma etiqueta. La propagación de abajo hacia arriba de coincidentes está controlada por el peso de los correspondientes subárboles. Generación de los scripts: El script de cambios se genera a partir de la base de coincidentes. Aquellos nodos no-coincidentes del antiguo documento se etiquetan como eliminados mientras que los nodos no-coincidentes del nuevo documento se etiquetan como añadidos. Los nodos textuales que han cambiado su contenido se etiquetan como actualizaciones. Aquellos nodos coincidentes, sin tener los mismos padres, se marcan como elementos movidos. JXyDi también detecta movimientos de los nodos dentro de un mismo padre, es decir, cambios en el orden de los hermanos. jxydi utiliza el mismo formato de salida que XyDelta [Marian 01] que consiste en un único documento XML que contiene deltas completas posteriores (2.5.2). En la gura 7.6 se muestra la salida de aplicar la herramienta jxydi al grafo de cambios descrito en el ejemplo ACM Sigmod (gura 7.3). En ella podemos observar un conjunto de etiquetas, mostradas en la tabla 7.1, que describen las operaciones que se han realizado: inserted indica una operación de inserción, deleted para las operaciones de borrado y AttributeInserted, AttributeDeleted y AttributeUpdated para operaciones de cambio sobre los atributos. En el caso de una operación de actualización de contenido aparece un atributo update con valor yes que indica este hecho. Este script de salida, gura 7.6 en formato XyDelta, debe transformarse a nuestro formato de documento XML transaccional pues es éste último el que realmente ejecuta nuestro sistema de versionado. En la tabla 7.1 se muestra la equivalencia existente entre los componentes XML del documento jxydi con respecto a nuestro formato XML de cambios. Esta equivalencia de elementos se puede vericar si comparamos las guras 7.6 y 7.5 donde se ilustra la historia de operaciones de cambio respectivamente en formato jxydi como en formato XML transaccional. Así por ejemplo la operación de actualización de un atributo, AttributeUpdated en jxydi, ocurrida entre las versiones V 2 y V 5 se transforma en la operación UA en nuestro formato. Nótese que el algoritmo jxydi determina el elemento que ha cambiado en base a su camino XPath, reriéndose al documento origen en el caso de ser una operación de borrado o actualización (etiqueta deleted) o al documento destino si es una operación de inserción (inserted). Finalmente nos gustaría resaltar dos aspectos relacionados con esta conversión de jxydi: El principal inconveniente de esta herramienta es que es sensible a retornos de carro, hecho que provoca que dos documentos XML iguales, con distintos retornos de carro,

175 Diseño del Sistema <delta> <!--V1 -> V2--> 2 <Inserted pos ='0:1:1:5:1:3:2'/> 3 <Inserted pos ='0:1:1:5:1:3:3'> 4 <author AuthorPosition ='3'/> 5 </Inserted> 6 </delta> 7 <delta><!--v2 -> V3--> 8 <Deleted update ='yes' pos ='0:1:1:5:1:3:1:0'>Luis Arevalo</Deleted> 9 <Inserted update ='yes' pos ='0:1:1:5:1:3:1:0'>Luis J. Arevalo</Inserted> 10 </delta> 11 <delta><!--v3 -> V4--> 12 <Inserted pos ='0:1:1:5:1:3:3:0'>Antonio Polo</Inserted> 13 </delta> 14 <delta><!--v2 -> V5--> 15 <AttributeUpdated nv ='2' name ='AuthorPosition' ov ='3' pos ='0:1:1:5:1:3:3'/> 16 </delta> 17 <delta><!--v2 -> V6--> 18 <AttributeInserted name ='alias' value ='Luigy' pos ='0:1:1:5:1:3:1'/> 19 </delta> 20 <delta><!--v5 -> V7--> 21 <Deleted pos ='0:1:1:5:1:1:0'>Versionstamp</Deleted> 22 </delta> 23 <delta><!--v6 -> V8--> 24 <AttributeDeleted name ='alias' pos ='0:1:1:5:1:3:1'/> 25 </delta> Figura 7.6: Ejemplo de Documento jxydi Tabla 7.1: Correspondencia entre las etiquetas jxydi y nuestras primitivas de cambio Etiqueta jxydi <inserted pos=->node</inserted> <deleted pos=->node</deleted> <AttributeInserted name="attr" value="val" pos="-"/> <AttributeDeleted name="authorposition" pos="-"/> <AttributeUpdated nv="valupd" name="attr" ov="val" pos="-"/> <Inserted pos="-">ctx</inserted> <Deleted pos="-">ctx</deleted> <Deleted update="yes" pos="-">ctx1</deleted> <Inserted update="yes" pos="-">ctx2</inserted> Primitiva <IE idf=? pos=>node</ie> <DE idf=/> <IA idf= name= value=/> <DA idf= name=/> <UA idf= name= nv=/> <IC idf= ctx=/> <DC idf= ctx=/> <UC idf= ctx=/> sean bajo esta herramienta diferentes. Hemos evitado esta situación convirtiendo los documentos XML que se van a comparar en documentos XML normalizados. El último dígito de la etiqueta inserted especica la posición (atributo pos) en la cual se añade el elemento XML que se desea insertar, mientras que en el caso de las operaciones sobre el contenido de los elementos, el último dígito no computa, si no tratamos con elementos mixtos, pues indica la posición del texto. A partir de todo lo anterior, en la gura 7.7 se muestra el nuevo esquema de funcionamiento

176 158 Capítulo 7. Diseño de un Sistema de Versionado basado en vdocxml Figura 7.7: Esquema de Funcionamiento del Sistema de Versionado con Herramienta de Diferencia del sistema de versionado propuesto con la integración de la herramienta de diferencias jxydi. Partiremos siempre de una versión inicial del documento V 0 o de un documento XML previo y según se produzcan las distintas versiones, éstas se van integrando en el documento versionado. Para poder realizar esta integración, en primer lugar usaremos la herramienta de diferencias y posteriormente los elementos/atributos insertados o borrados son añadidos o eliminados lógicamente en el documento Diseño del Sistema Gestor En el apartado anterior mostramos el diseño funcional del sistema de versionado para la gestión de versiones de documentos XML. En este nuevo nivel de especicación indicamos las tecnologías que utilizaremos en la construcción de cada una de las capas y daremos un diseño más detallado del sistema gestor de versiones. En la gura 7.8 se ilustra cada una de los componentes del sistema de versionado desarrollado donde claramente se distinguen las tres capas que lo componen. Sin embargo en este caso, se incide sobre las herramientas tecnológicas que se usarán para el desarrollo de cada una de sus partes. En la capa de presentación se aprecia en el nivel inferior el uso de técnicas y herramientas orientadas a programación basada en servicios (servicios XML-RPC, servicios web o servlets XQuery), mientras que en el nivel superior se propone el uso de herramientas y técnicas que permitan construir un nivel de aplicaciones sobre estas capas de servicios (AJAX, JSP, XQuery). El diseño y desarrollo detallado de extensiones y aplicaciones en esta capa se abordará en el capítulo 9. Para el sistema gestor de versiones hemos realizado dos implementaciones que hemos denominado librerías de versionado tal y como se muestra en la gura 7.8. La primera de ellas utiliza hojas de estilos XSLT mientras que la segunda se ha desarrollado mediante un conjunto de funciones XQuery. La razón de la existencia de estas dos soluciones es que la implemen-

177 Diseño del Sistema Gestor 159 Figura 7.8: Sistema de Versionado tación XSLT fue desarrollada previamente por la facilidad que aporta este lenguaje para realizar transformaciones y su aplicación directa sobre un sistema de cheros en la capa de datos, posteriormente, con el objetivo de integrar nuestra técnica en una base de datos nativa XML, abordamos su implementación en XQuery. Nótese que la librería XQuery también puede ser usada directamente sobre una capa de datos basada en cheros aplicando un procesador XQuery sobre el sistema de cheros. Establecimos como objetivo primordial de estas implementaciones su amplia portabilidad, hecho que hemos conseguido usando únicamente estándares XML (XSLT, XPath y XQuery). Actualmente se ha vericado su funcionamiento en Saxon [Kay 01] y la base de datos nativa exist [Exist. 01]. Se ha seguido en la medida de lo posible la especicación del W3C sobre XSLT/XQuery y actualmente para su funcionamiento se necesitan dos características incluidas en la mayoría de los procesadores XML pero no en la W3C: soporte para el atributo xml:id, usado en nuestra técnica para representar la información histórica del documento y la función eval() que permite evaluar dinámicamente una cadena como expresión XPath/XQuery Módulos XSLT Hemos desarrollado un conjunto de hojas de estilo XSLT que permiten manejar versiones de documentos XML. Más concretamente las hojas de estilos implementadas son: 1. doc2vdoc.xslt: Documento XSLT que se encarga de convertir un documento XML en su documento vxml equivalente. Esta hoja de estilo recibe como parámetro el identicador de versión inicial del documento vxml. Para ello crea la estructura básica de un documento vxml (version_tree y versioned_doc) y transforma los elementos, atributos y contenido a su representación de documento XML versionado. 2. vdoc2doc.xslt: Hoja de estilo que se encarga de recuperar una determinada versión almacenada en un documento vxml. Esta operación se muestra en el siguiente capítulo en la consulta donde se puede comprobar que únicamente necesita como parámetro el identicador de versión a recuperar.

178 160 Capítulo 7. Diseño de un Sistema de Versionado basado en vdocxml 3. getversions.xslt: Devuelve una lista de identicadores de versión almacenada en un documento vxml. 4. di.xslt: Recupera las diferencias entre dos versiones representadas en un vxml. Nótese que en este caso no utilizamos la herramienta de diferencia jxydi para este proceso, sino que se utiliza la consulta de diferencia de la sección Obviamente, tal y como se expone en dicha sección, la salida generada no es tan completa como en el caso de jxydi. 5. cambios.xslt: Núcleo del sistema gestor de esta librería pues se encarga de actualizar un documento vxml a partir de un conjunto de primitivas de cambio. Como principal inconveniente de esta librería podemos destacar que necesita de una aplicación externa para actualizar un documento vxml. Esto se debe al propio funcionamiento inherente de un procesador XSLT que no es capaz de tratar dos documentos XML de entrada a la vez; uno para el procesamiento del documento XML transaccional que especica los cambios a realizar y a la par el procesamiento del documento vxml a actualizar. Además esta solución tiene un alto coste computacional, provocado también por el uso de hojas de estilo, pues la actualización de un documento vxml necesita la generación completa del documento de entrada por cada uno de los cambios ejecutados del documento XML transaccional. Esta situación nos condujo a buscar otra solución como fue la basada en módulos XQuery. Nótese que para el correcto funcionamiento de estas hojas de estilos como un sistema de versionado, éstas deben acompañarse de una interfaz gráca, que las haga más intuitivas, así como de un pequeño gestor que interactúe entre la capa de datos y de usuario. Este sistema de versionado se expondrá posteriormente cuando se analice la interfaz basada en servicios web Módulos XQuery También se ha desarrollado un conjunto de módulos XQuery que permiten manejar versiones de documentos XML y pueden ser utilizados tanto en procesadores XQuery como en bases de datos nativas XML con soporte a XQuery (XNDB). En la gura 7.9 se muestra la relación entre estos módulos y la arquitectura del sistema propuesto. A continuación describimos los siete módulos existentes, donde el módulo Version incluye la interfaz pública. Módulo vutil: Este módulo contiene aquellas operaciones básicas sobre documentos XML tales como vericar si el documento de entrada/salida es válido, la existencia de un nodo especicado en el documento, así como operaciones básicas sobre cadenas, fechas, valores aleatorios etc. Es usado por el resto de módulos. Módulo vstamp: Formado por todos los operadores de versionado descritos en la sección 8.2. Son usados principalmente por el módulo vquery para realizar las consultas. Módulo vquery : Dentro de este módulo se han incluido como funciones XQuery las consultas de versionado sobre documentos vxml que se van a describir en el capítulo 8, tales como consultas históricas, instantáneas, rangos, diferencias, etc. Módulo vupdate: Es uno de los módulos más importantes pues permite actualizar un documento XML versionado a partir de un conjunto de primitivas de cambio. Recibe

179 Diseño del Sistema Gestor 161 Figura 7.9: Arquitectura del Sistema XQuery y la interrelación entre los Módulos XQuery con respecto a la API pública de la tabla 7.2 un documento transaccional, denido como una secuencia de primitivas de cambio a realizar sobre una determinada versión y actualiza el documento vxml. Módulo vdi : Este módulo interacciona con la herramienta de diferencia, es decir, proporciona un conjunto de funciones para obtener las diferencias existentes entre dos versiones o entre versiones de un vdocumento. Módulo vconversion: Dentro de este módulo se incluyen aquellas operaciones que convierten un documento XML en otro documento XML. Por una parte, se encarga de convertir un documento XML a un vdocumento y viceversa (denominándose a estas operaciones doc2vdoc y vdoc2doc respectivamente) y, por otra, se han incluido aquellas operaciones que se encargan de transformar documentos externos XML de diferencias a nuestro formato XML transaccional con el objetivo de, posteriormente, poder actualizar un vdocumento. Módulo Version: Este módulo dene la API pública para la gestión de versiones de documentos XML, basándose para ello en el resto de los módulos descritos. Nótese que esta API implementa las funciones básicas de un vdocxml denida en el capítulo 6. En el Capítulo 8 se llevará a cabo un estudio más detallado de estos módulos, salvo el módulo Version, que analizamos en detalle a continuación. En la tabla 7.2 se muestra cada una de las primitivas que forman parte del módulo Version, especicando algunos aspectos como su entrada, sus características y su comportamiento. La interrelación de cada primitiva con respecto a los módulos anteriores se muestra en la gura

180 162 Capítulo 7. Diseño de un Sistema de Versionado basado en vdocxml 7.9 mediante un número comprendido entre 1 y 6, que se corresponde con la numeración de las primitivas. Nótese que no hemos incluido una primitiva especica para cada consulta pues son internas al sistema y se pueden acceder mediante el módulo vquery. Función 1. Version:doc2vdoc ($col, $doc, $alias, $time, $name_vdoc, $alias) 2. Version:vdoc2doc ($vdoc_uri, $version) Tabla 7.2: API del módulo Version Descripción El documento $doc localizado en la colección $col es transformado en un documento vxml. Necesita el tiempo de cuando la versión fue realizada $time, el nuevo nombre del documento $name_vdoc y un alias de la versión. Recupera la versión ($version) del vdocumento ($vdoc_uri) 3. Version:getVersions Recupera todas las versiones disponibles para un determinado ($vdoc_uri) documento XML versionado. 4. Version:vGetDi Obtiene las diferencias XML entre dos documentos XML. El ($vdoc_uri, documento resultante puede ser o bien en formato jxydi o en $vdoc2_uri) nuestro formato. 5. Version:vAdd Añade una nueva versión a la versión $dim_now de un vdocumento ($vdoc_uri, $Xml_Uri, $vdoc_uri a partir de un documento XML que es una $dim_now, $alias) actualización de dicha versión. 6. Version_vCheck() Comprueba la integridad de un vdocumento Debemos destacar los siguientes aspectos de esta API: La función vgetdi mostrada en la tabla obtiene las diferencias de dos documentos XML; sin embargo, también se ha implementado para comparar dos versiones de un documento vxml (vgetdi ($vdoc_uri, $version1, $version2)), o de un documento XML y un documento vxml+version (vgetdi ($Doc_uri, $vdoc_uri, $version1)). La operación de actualización vadd también puede llevarse a cabo indicando un documento XML de diferencia jxydi (Version:Transaction-jXyDi ($vdoc_uri, $doc_jxydi, $dim_now, $alias)) o un documento XML transaccional (Version:Transaction-Di ($vdoc_uri, $doc_xml_transac, $dim_now, $alias)) La operación vcheck verica si la representación histórica del vdocumento está bien formada y si todos los elementos del documento tienen un identicador único. Por medio del módulo Version se pueden llevar a cabo las operaciones típicas de cualquier sistema de versionado como: crear un documento XML versionado (doc2vdoc), recuperar una versión válida de un documento vxml (vdoc2doc), recuperar las versiones incluidas en un vxml (getversions), actualizar cualquier versión almacenada en un vdocument desde un documento XML actualizado (vadd) o recuperar las diferencias entre dos versiones (vgetdi ). Como mecanismo de control de traza y seguridad se ha diseñado un chero especial para cada usuario del sistema, denominado logs_changes.xml, que sirve para especicar el histórico de cambios realizados por dicho usuario, con el objetivo de poder restaurar un determinado documento en el caso de producirse una caída del sistema, poder analizar los cambios realizados por un determinado usuario, etc. La incorporación de este chero de logs en la base de datos ha

181 Diseño del Sistema Gestor 163 implicado utilizar algunas funciones XQuery propias de exist para conocer cuál es el usuario actual conectado (get-current-user()) y el directorio home de dicho usuario (get-user-home()). Finalmente, de las dos propuestas existentes de actualización XQuery (XUpdate y XQueryUpdate), hemos usado XUpdate en nuestro sistema de versionado, pues se encuentra incluido tanto en exist como en Saxon. La adaptación al otro lenguaje de actualización sólo necesitaría la implementación de un nuevo módulo XQuery que cambiaría a la nueva sintaxis las operaciones de actualización Uso con Procesadores XQuery Los módulos descritos previamente pueden ser usados con cualquier procesador XQuery para gestionar versiones de documentos XML como, por ejemplo, documentos XML omáticos o documentos XML grácos (SVG), etc. La utilización de estos módulos en un procesador XQuery requiere de los siguientes pasos: 1. Denir en el prólogo de la consulta XQuery el espacio de nombres v de la técnica versionstamp, usado en los atributos v:start y v:end y en los elementos v:data y v:attrib. Con la declaración de este espacio de nombres se establece un enlace entre el prejo y el espacio de nombres y permite utilizar dicho prejo en el cuerpo de la consulta (declare namespace v=' 2. Importar los módulos XQuery en la consulta. En XQuery, igual que en los lenguajes de programación clásicos, el código fuente se puede dividir en partes separadas (módulos) con el n de hacerlo más legible y manejable. Para incluir una librería o módulo de funciones XQuery sólo se necesita especicar, después del prólogo, mediante la palabra import 1) el módulo que se desea cargar 2) su espacio de nombres y 3) donde se encuentra. 3. Finalmente utilizar cualquiera de las funciones denidas en el módulo Version. Consulta 7.1 Llamada a la función vdoc2doc en XQuery 1 xquery version '1.0'; 2 declare namespace v=' 3 import module namespace Version=' 'Version.xqm' 4 Version:vdoc2doc('acm.vxml','V3') En la consulta 7.1 se muestra la estructura de una consulta XQuery para la ejecución de una función del módulo version (vdoc2doc). Tal y como acabamos de exponer, en primer lugar se incluye el espacio de nombres de versionstamp (línea 2), posteriormente se importa la librería de versionado (línea 3) y, nalmente, se procede a la llamada de la función requerida. En este caso se supone que el chero version.xqm (espacio de nombres Version) se encuentra en el mismo directorio donde se está ejecutando la consulta, pues no se indica ningún path a continuación de la palabra reservada at. Si se quisiera especicar un path concreto se realizaría mediante el siguiente formato at le://d:\query\version.xqm. Nótese que el resto de los módulos denidos en la librería se encuentran importados en el documento version.xqm o en aquellos módulos donde se realiza la llamada a sus funciones.

182 164 Capítulo 7. Diseño de un Sistema de Versionado basado en vdocxml Extensión de una Base de Datos Nativa XML con Versionado En los últimos años ha aparecido un gran número de bases de datos con soporte para documentos XML y algunas de ellas con soporte para XQuery. Existen principalmente dos tipos de bases de datos XML: 1) XML-Enabled, las cuales mapean los documentos XML en una base de datos relacional u objeto-relacional, 2) Bases de datos nativas XML (XNDB), que utilizan como unidad fundamental de almacenamiento estructuras especícas para documentos XML. Hemos decidido utilizar una XNDB pues con mayor probabilidad nos ofrecerá todas las características deseables en documentos XML: soporte para todos los lenguajes estándares de consultas XML, indexación basada en el anidamiento XML, etc. Un listado de bases de datos nativas junto con algunas características se encuentra en [Bourret 01]. Integrando los módulos XQuery en una XNDB algunas de las características deseables en un sistema de versionado como concurrencia, transacciones, bloqueo, indexación o usuarios serían directamente soportados por la XNDB. Esta situación nos animó para posibilitar el tratamiento de versiones de una XNDB de forma nativa. exist-db[exist. 01] es un sistema de gestión de bases de datos libre y de código abierto que almacena datos XML de acuerdo a un modelo de datos XML. Algunas de sus características son: soporte para distintos lenguajes de consultas XML, como XQuery, XPath y XSLT, indexación de documentos y soporte para la actualización de los datos y para multitud de protocolos como SOAP, XML-RPC, WebDav y REST; además, en la actualidad cumple el estándar XQuery en un 99.4 %. En el momento de escribir este trabajo, el soporte a nivel de usuario de transacciones es limitado aunque algunas características sí están habilitadas a nivel de administrador. Una de las principales características de exist es la gran facilidad que proporciona para su extensibilidad, es decir, se pueden añadir nuevas características a la base de datos, tanto usando el lenguaje de programación Java como mediante XQuery. En nuestro caso, para incorporar las características de versionado a exist han sido necesarias ambas aportaciones, pues, por una parte, para la integración de JXyDi [jxydi 06] en exist se ha tenido que realizar un adaptador JXydi para exist a nivel de Java y, por otra, los módulos se han desarrollado en XQuery. En primer lugar, para integrar los módulos XQuery, exist proporciona tres mecanismos: una URI, documentos binarios almacenados en la base de datos o incorporándolos en un directorio de la instalación de la base de datos. La primera solución fue desechada debido a la dependencia que se iba a establecer entre exist y la URI y que podrían ocasionar problemas de desconexión del servidor de la URI, problemas en la red, etc, de forma que la solución más factible ha sido integrar los módulos en exist (bien como documentos o en un directorio). Si los módulos se guardan en la base de datos, exist almacena los módulos en formato binario y solamente es necesario indicar la colección donde se encuentran los módulos para su utilización dentro de la sentencia de importación. Finalmente, en el último caso, se añaden los módulos dentro de un chero.jar congurado para su uso. En la consulta 7.2 se muestra la estructura de una consulta XQuery para la ejecución de una función del módulo version (vgetdi ) en exist. La única diferencia con respecto a la consulta anterior, quitando que se trata de una consulta distinta, es que la importación del módulo se realiza en base a una colección de la base de datos XML (línea 3). En segundo lugar, era necesario implementar un adaptador para una herramienta de diferencias con el objetivo de obtener las diferencias entre documentos XML. El principal problema que tuvimos fue integrar ambos modelos de datos, pues en el caso de jxydi se utiliza una

183 Conclusiones 165 Consulta 7.2 Llamada a la función vgetdi en XQuery (exist) 1 xquery version '1.0'; 2 declare namespace v=' 3 import module namespace Version=' at 'xmldb: 4 //db/version.xqm' 5 Version:vGetDiff('acm.vxml','acm.xml','V2') extensión al modelo de datos básico DOM mientras que en el caso de exist se usa el concepto de secuencia de nodos. En el del directorio extension/modules/src de exist se ha creado un directorio denominado jxydi con dos cheros: Compare.java con el código fuente del adaptador y XmlJXYDiModule.java que contiene la signatura del código usado. De forma resumida, la integración de esta extensión en exist requiere de los siguientes pasos: 1. Copiar los módulos XQuery en una base de datos exist. 2. Añadir el código fuente del adaptador Java al código de exist (extension/modules/src) así como el chero jxydi.jar en el directorio de librerías (lib/optional) 3. Incluir nuestro espacio de nombres en el chero de conguración de exist (conf.xml) 4. Recompilar exist para utilizar nuestra extensión de forma nativa. Como principal ventaja de esta implementación cabe destacar que los módulos pueden ser usados desde código Java embebido, por servicios web, consultas XQuery, etc., lo que nos aporta una gran portabilidad. Observaciones En enero de 2009 los desarrolladores de la bases de datos exist han realizado la implementación de una herramienta para la gestión de versiones de documentos XML basada en la aproximación DeltaXML, es decir, la obtención y representación de las diferencias XML de los cambios entre dos versiones de un mismo documento. Como hemos expuesto repetidamente esta solución tiene un coste computacional alto para la recuperación de una versión distinta de la actual así como imposibilita, sin restaurar todas las versiones del documento, conocer la historia de un determinado elemento XML Conclusiones Uno de los momentos más graticantes de todo investigador se produce cuando puede demostrar de forma práctica el modelo teórico propuesto, en nuestro caso, la implementación de un sistema de versionado usando la técnica de versionstamp propuesta en esta tesis. En este capítulo se presenta el diseño del sistema, mientras que en los dos próximos capítulos se mostrarán los detalles de programación y las pruebas realizadas sobre el mismo. Comenzamos el capítulo describiendo la arquitectura del sistema de versionado propuesto para posteriormente entrar en detalles de cómo ésta se ha llevado a cabo. Para ello se ha dado una descripción funcional, una especicación de las herramientas y técnicas para su desarrollo y, nalmente, el diseño modular del sistema gestor de versiones. Así hemos presentado la implementación de dos librerías, XSLT y XQuery, que permiten realizar la gestión de versiones de documentos XML, profundizando en la segunda de ellas por su gran portabilidad. De este

184 166 Capítulo 7. Diseño de un Sistema de Versionado basado en vdocxml modo se ha demostrado como ésta se puede usar en un procesador XQuery o integrar en una base de datos nativa XML para tener versionado ramicado de forma nativa en ella. En el siguiente capítulo se muestra el resto de los módulos de la implementación realizada en XQuery donde se hará un especial seguimiento al módulo vquery. Su implementación está basada en funciones de usuario XQuery, lo que permite extender este lenguaje para el soporte de consultas de versionado sobre documento vdocxml. Finalmente en el capítulo 9 se ilustra la experimentación llevada a cabo sobre esta implementación, distinguiéndose dos niveles: un nivel que analizará el rendimiento de las consultas más habituales y otro nivel práctico que consistirá en el desarrollo de distintos interfaces de versionado basados en la API pública de versionado.

185 Capítulo 8 Construcción del Sistema Gestor y de Consultas Contenidos 8.1. Representación de Tipos Básicos para las Consultas de Versionado Predicados de Versionado: vstamp Predicados de Versionado Predicados de Versionado en XQuery Consultas sobre vdocumentos: vxquery Proyección de Versionado Instantánea de Versionado Regiones de Versionado Actualización de un vdocumento: vupdate Validez en el Proceso de Actualización Inserción de Elementos Borrado de Elementos Actualización de Atributos Consultas de Diferencias: vdi Consultas de Diferencias en XQuery Consultas de diferencias en XSLT Conclusiones En el capítulo previo presentamos el diseño de nuestro sistema de versionado para documentos XML versionados. En particular, el bloque de diseño denominado Gestor de Versiones, se encontraba formado por un conjunto de módulos de los cuales el módulo Versión denía la API pública de versionado para ser usada como gestor de versiones. En este capítulo analizaremos los restantes módulos. Entre todos ellos haremos especial hincapié en el módulo vquery que nos permitirá extender el lenguaje XQuery, en base a funciones de usuario, para denir consultas de versionado sobre documentos vxml. En la sección 8.1 se muestra la representación en XQuery de los tipos básicos en nuestro modelo vdocxml. En especial los tipos que representan conjuntos de identicadores de versiones.

186 168 Capítulo 8. Construcción del Sistema Gestor y de Consultas En la sección 8.2 se presentan los predicados de versionado que se utilizarán en las consultas para poder comparar versiones del árbol de versionado. En primer lugar se denirán las distintas clases de predicados que hemos observado en nuestros documentos vxml y posteriormente se muestra su implementación usando el lenguaje XQuery. En la sección 8.3 se profundiza en las distintas consultas de recuperación que pueden realizarse sobre un documento XML versionado. De este modo, las consultas clásicas de los sistemas de información históricos, tales como proyecciones o instantáneas, se han redenido para el caso de documentos XML versionados. El módulo vquery extiende el lenguaje XQuery, en base a funciones de usuario, para denir consultas de versionado sobre documentos vxml. En particular, se destacarán las consultas de instantáneas de elementos y de rangos de versionado, pues se usarán en el próximo capítulo para realizar las pruebas de recuperación. La sección 8.4 versa sobre algunas de las operaciones de actualización aplicables a un documento XML versionado. Ya vimos con anterioridad, concretamente en el capítulo 6, cómo actualizar correctamente la información de versionado de un grafo vxml cuando se produce una operación de cambio por lo que, en este punto, nos centraremos en describir cómo se materializa esta actualización en el lenguaje de consulta XQuery sobre los vdocumentos. Estas operaciones se apoyan en el lenguaje XUpdate [Laux 00] para realizar las inserciones, borrados y actualizaciones de los documentos vxml. En la sección 8.5 se muestra la consulta de recuperación de diferencias entre dos versiones representadas en un documento vxml mediante distintos lenguajes de consulta XML. Así, en primer lugar utilizaremos el lenguaje XQuery para obtener las diferencias en formato XML y posteriormente, usando el lenguaje XSLT, obtendremos en formato más gráco (HTML) dichas diferencias. Por último, en el apartado de Conclusiones, se proporcionan de forma resumida las tablas con las operaciones desarrolladas en cada módulo Representación de Tipos Básicos para las Consultas de Versionado A la hora de realizar cualquier tipo de operación o consulta sobre nuestro modelo vdocxml en XQuery vamos a usar principalmente dos tipos de objetos: elementos versionados y conjuntos de identicadores de versión. El primero de ellos se corresponde con un elemento XML que tiene una región de versionado asociada y el segundo con una lista de identicadores de versión de un árbol de versionado. Nótese que precisamente una región de versionado es un tipo particular de conjunto de identicadores de versión que constituyen una región conexa del árbol de versionado y que, como sabemos, representamos mediante los atributos v:start y v:end. En general, las operaciones que vayamos a realizar sobre el espacio de versionado estarán referidas a conjuntos de versiones, cuyos elementos representaremos mediante los identicadores de versiones respectivos. Sin embargo, distinguiremos diferentes tipos de conjuntos de identicadores de versión según la relación inducida entre ellos por el árbol de versión. De esta forma, podemos pensar en simplemente un identicador ($v), un path o camino en el árbol de versionado ($pv), una región de versionado ($vv) o, nalmente, un conjunto cualquiera de identicadores de versiones en el árbol de versionado que no constituyan una región de versionado ($lv). Nótese que la representación de cada uno de ellos es diferente, por ejemplo $lv se representará mediante una lista de identicadores, mientras que $vv=($start, $end) se

187 Representación de Tipos Básicos para las Consultas de Versionado 169 representa mediante un identicador $start que indicará el vértice raíz de la región de versionado, y $end que indicará la lista de identicadores de versiones que delimitan los subárboles que no pertenecen a la región de versionado. En XQuery, la estructura de datos elemental que utilizaremos es la secuencia de identicadores de versión, y ese será el tipo básico que usaremos para representar cada uno de los conjuntos anteriores. Nótese que ello signica que cada secuencia de identicadores en XQuery se interpretará de acuerdo con la semántica asociada al tipo de conjunto de identicadores que representa, de acuerdo con la siguiente semántica: Conjunto de versiones ($lv): lista de identicadores de versión. $lv:=(v1, V2, V3, V4). Región de versionado ($vv): secuencia de identicadores de versión donde el primer valor $vv[1] es el valor del atributo start y el resto de valores $vv [ position() > 1] se corresponde con los identicadores del atributo end. Por ejemplo, $vv:=(v1, V5, V6, V9) se interpretará como $vv=($start, $end), donde $start={v1} y $end={v5, V6, V9}. Esta región de versionado referida al árbol de versionado del documento sigmod.vxml o también llamado acm.vxml mostrado en la Figura 7.3 del capítulo 7, está representando por el siguiente conjunto de versiones respecto de dicho árbol de versionado: $vv:=(v1, V5, V6, V9) = $lv:=(v1, V2, V3, V4). Path de versiones ($pv): Par de identicadores [origen,destino] que constituyen un camino del árbol de versionado. Por ejemplo $path := (V1 V7) respecto del citado ejemplo, será el conjunto $lv = {V1, V2, V5, V7} Versión ($v): un conjunto de versiones constituida por un único valor. $v:={v1}. Tabla 8.1: Conversión de Tipos de Conjuntos de Versionado Función evtovv($ev):$vv evtolv($ev):$lv vvtolv($vdoc_uri,$vv):$lv lvtovv($vdoc_uri,$lv):$vv Descripción De región en Elemento vxml a región de versionado De región en Elemento vxml a lista de versiones De región de versionado a lista de versiones De lista de versiones a región de versionado De este modo estos distintos tipos de datos permiten representar todos los posibles casos de conjuntos de versiones y debido a que todos se denen como una secuencia de valores en XQuery hemos establecido un conjunto de funciones de conversión entre estos tipos de datos tal y como se muestra en la tabla 8.1. Nótese que, en todos los casos es necesario disponer del árbol de versionado para interpretar los identicadores de versión. En algunos casos será preciso indicarlo de forma explícita, como sucede con $vv y $lv, que necesitan que se especique el árbol de versionado al cual hacen referencia los identicadores de versión; mientras que en otros casos, el árbol de versionado puede estar indicado de forma implícita, como sucede cuando nos reramos a $ev (elemento XML con una región de versionado asociada) pues su árbol de versionado estará accesible mediante su contexto. La tabla 8.2 recopila la notación que se utilizará a lo largo del capítulo en las consultas XQuery. Este pequeño resumen nos ayudará a entender más fácilmente la consulta pues a partir de los nombres de la variable será posible conocer sus tipos de datos y saber sobre qué contexto se puede aplicar.

188 170 Capítulo 8. Construcción del Sistema Gestor y de Consultas Tabla 8.2: Notación usada en las consultas XQuery Variable Signicado Ejemplo $node Apuntador a un nodo XML en un Documento <a><b/></a> XML $v Identicador de versión del árbol de versionado. $v:='v1' $vv Región de versionado {$v i} donde $vv[1]=start y $vv:=(v1, V5, V6, V9) $vv[position()>1]=end $ev Apuntador a un elemento XML con región de versionado asociada (v:start y v:end) de un <x v:start=v1 v:end=v5 V6 V9/> vdocxml $lv Lista de identicadores de versión del árbol de $lv:={v1, V2, V3, V4} versionado $path Par de identicadores [origen,destino] que constituyen un camino del árbol de versionado $path:=(v1 V7) => $lv={v1, V2, V5, V7} $Doc_uri Nombre de un chero XML 'acm.vxml' $dim_now Identicador de la versión actual 'V1' $new_v Identicador de la nueva versión 'V2' $idf Identicador único de un elemento XML 'd1e4' $number Valor numérico entero 3 $time Instante de tiempo en el formado AAAA-MM-DD. $days Valor numérico (días) Predicados de Versionado: vstamp A la hora de consultar un grafo XML es necesario denir previamente los operadores y predicados de versionado de que dispondrá nuestro modelo de datos para realizar comparaciones entre los estados representados en el árbol de versionado. Por ejemplo, a nivel temporal, en [Allen 83] se establecieron trece predicados temporales para la comparación entre dos intervalos temporales: antes (before), después (after), solapamiento (overlap), contiene (contains), etc. Estos predicados utilizan los operadores matemáticos <, <=, >, >= sobre datos temporales para determinar si un intervalo es mayor o menor que otro dado. Sin embargo, puesto que en nuestra solución la información histórica se dene en base a un árbol de derivación, hemos tenido que redenir estos operadores para su aplicación a nivel de versionado, hecho que analizaremos formalmente y en XQuery en este apartado Predicados de Versionado En el capítulo 5 introdujimos los operadores y a la hora de denir la región de versionado y de establecer si una versión pertenece a una región de versionado. A continuación recordaremos y ampliaremos estos operadores pues los utilizaremos para denir los predicados de versionado.

189 Predicados de Versionado: vstamp 171 Sea un árbol de versión Vt=(V',E',&0) y sea v V' element, entonces denotaremos lo siguiente: Dado un x D(id), si v V' element / e E' A ; ((parent(e)=v) (name(e)="id") (value(child(v))=x), denotaremos este vértice como Υ(x)=v. Si este vértice v existe para x, debe ser único y denotará el vértice identicado por x, o simplemente vértice de x. En general, usaremos el símbolo x para denotar valores y distinguirlos del uso de v para denotar vértices. (v)=descendant(v,vt) V' element como todos los vértices element descendientes para el vértice v. (v)=ancestor(v,vt) V' element como todos los vértices element ancestros de v. (v)=(descendant(v,vt) {v}) V' element como todos los vértices element descendientes de v, incluyéndose a si mismo. (v)=(ancestor(v,vt) {v}) V' element como todos los vértices element ancestros de v, incluyéndose a si mismo.,,, pueden también denirse sobre un conjunto de identicadores de versión: por ejemplo {v i I }= i I (v i ). Usando estos operadores hemos establecido tres tipos de predicados de versionado: 1. Predicados de comparación entre dos identicadores de versión (tabla 8.3). 2. Predicados de comparación de una versión con una región de versionado (tabla 8.4). 3. Predicados de comparación entre dos regiones de versionado (tabla 8.5). La notación empleada en dichas tablas es: VT representa al árbol de versionado, V i es un identicador de versión del VT y VR i es una región de versionado, donde VR is es el atributo start y VR ie es el atributo end. En la tabla 8.3 se muestran los predicados de versión que nos permiten comparar dos identicadores de versión de un árbol de versionado. Éstos se han denido en base a la relación de derivación existente entre ambos identicadores. En la tabla hemos omitido los predicados de negación con el objetivo de simplicarla y otros tipos de relaciones menos habituales o que se pueden deducir a partir de estas. Por ejemplo, diremos que una versión V i es anterior o menor ( ) a una versión V j si y sólo si V j es descendiente de la versión V i o V i precede a la versión V j como ocurre con las versiones V 1 y V 5 de la gura 7.3, donde el vértice &V 5 es descendiente del vértice &V 1 en el árbol de versionado. Tomando como base estos predicados, hemos establecido siete nuevos predicados de comparación Versión - Región de Versionado que nos permiten especicar las posibles relaciones entre una versión y una región de versionado (tabla 8.4). Por ejemplo, diremos que una versión es posterior o mayor a una región de versionado (descend (v, VR)) si y sólo si la versión dada desciende del atributo start de la región de versionado o por ejemplo el operador belongs determina si una versión pertenece a una región de versionado lo cual sucede si y sólo si se dan las dos siguientes condiciones: 1) la versión dada se encuentra entre los descendientes del atributo de versionado start inclusive el mismo y 2) la versión dada no se encuentra entre los descendientes de los valores del atributo de versionado end inclusive ellos mismos.

190 172 Capítulo 8. Construcción del Sistema Gestor y de Consultas Tabla 8.3: Predicados de Comparación entre dos versiones Predicados Simbología Signicado after v 1 v 2 v 1 es descendant de v 2 en VT after-self v 1 v 2 v 1 es descendent-self de v 2 en VT before v 1 v 2 v 1 es ancestor de v 2 en VT before-self v 1 v 2 v 1 es ancestor-self de v 2 en VT equal v 1 v 2 v 1= v 2 en VT parent parent(v 1,v 2) v 1 es parent de v 2 en VT child child (v 1,v 2) v 1 es child de v 2 en VT Tabla 8.4: Predicados de Comparación entre una Versión y una Región de Versionado Predicados Signicado vdescends(v,vr) v V R s vdescends-self(v,vr) v V R s vancestor(v,vr) v V R s vancestor-self(v,vr) v V R s vbelongto(vr,v) - vɛ VR (v V R s ) ( v i V R e, v v i ) vstarts(v,vr) v V R s vends(v,vr) v i V R e /v i v Generalización de las operaciones a conjunto: Nótese que los predicados anteriores,,, pueden generalizarse de forma que sirvan para comparar entre una versión y un conjunto de versiones. Diremos por ejemplo que una versión V i es anterior a un conjunto de versiones si y sólo si todos los identicadores de versión incluidos en la región de versionado son descendientes de la versión V i. Esta generalización se utilizará por ejemplo para comparar una versión con respecto al atributo end de una región de versionado (compuesto por una/varias versiones). De este modo, los predicados versión-región de versionado pueden generalizarse y, en lugar de realizar la comparación desde una región de versionado, aplicarse sobre un conjunto de versiones. El patrón usado para identicar estos predicados es el siguiente: para aquellos predicados que operan sobre dos identicadores de versión usaremos el propio nombre del predicado (before, after,..), para aquellos que comparan una versión con un conjunto de versiones se mantiene el nombre del predicado con el prejo v (vbelongto, vdescen,...) y nalmente para aquellos que comparan dos conjuntos de versiones se usará el nombre del predicado con el prejo vr. Finalmente en este último caso si el predicado se realiza sobre una lista de identicadores este hecho se reejará añadiendo al nal del predicado la palabra list (vrcontainslist) y en el caso del path (vrcontainspath). Finalmente, en la tabla 8.5, hemos utilizado los predicados anteriores para denir los predicados para comparar dos regiones de versionado. Nótese que al igual que en el caso anterior es posible también generalizar estos últimos predicados para comparar una región de versionado con un conjunto de versiones. Así por ejemplo además de comparar una región con otra región de versionado se podría comparar una región con respecto a una lista de identicadores de versionado o un par de identicadores de versión [v1-v2] que establecen un camino en el árbol de versionado. Obviamente esta situación es posible únicamente si uno de

191 Predicados de Versionado: vstamp 173 los dos operandos es una región de versionado pues, en otro caso, la existencia de conectividad introducida por la región de versionado se perdería y no sería posible realizar una comparación válida. Tabla 8.5: Predicados de Comparación de Regiones de Versionado Predicados Signicado Predicados Signicado vrbefore(vr 1, VR 2) v i V R 1e/V R 2s vi vroverlaps(vr 1,VR 2) V R 2sɛ V R 1 vrafter(vr 1, VR 2) v i V R 2e/V R 1s v i vrstarts(vr 1,VR 2) V R 2s V R 1s vrequals(vr 1,VR 2) (V R 2s V R 1s) vrnishes(vr 1,VR 2) (V R 2overlapsV R 1) (V R 2e = V R 1e) (V R 2e = V R 1e) vrcontains(vr 1,VR 2) v iɛv R 2, v iɛv R 1 vrmeets(vr 1,VR 2) v i V R 1e/v i V R 2s Predicados de Versionado en XQuery En el apartado anterior formalizamos los predicados de versionado que permiten comparar versiones en nuestro modelo de datos y determinamos que existían tres posibles clases: predicados de comparación de versiones, predicados de comparación versión - región de versionado y predicados de comparación entre regiones de versionado. Nótese que aunque esta clasicación se puede generalizar a cualquier tipo de conjunto de identicadores de versión (path o conjunto de versiones general), nosotros consideraremos conjuntos de versiones denidos mediante una región de versionado, pues será el tipo de conjunto más habitual en nuestras consultas. Estudiaremos ahora cómo realizar su implementación a través de funciones de usuario en el lenguaje de consulta XQuery. Los Predicados de versión permiten realizar la comparación entre dos identicadores de versión del árbol de versionado. Puesto que la comparación se hará en base a la relación existente entre ambas versiones, que están representadas en un fragmento XML (árbol de versionado), se pueden utilizar los ejes XPath para llevar a cabo dicha tarea. Por tanto, si deseamos conocer si una versión V i es anterior a otra versión V j, sólo es necesario comprobar si la versión V j es descendiente de V i en el árbol de versionado, según se estableció en la tabla 8.3. La implementación del operador before ( ) en XQuery se muestra en la consulta 8.1, junto con un ejemplo de uso que comprueba si la versión V 2 es mayor que V 4. Para que este desarrollo cobre sentido es necesario disponer del documento vxml, con su árbol de versionado, además de los dos identicadores de versión que se desean comparar. También es imprescindible utilizar la función id() de XPath para poder dereferenciar los dos identicadores de versión. La implementación del resto de predicados, utilizando XPath, se muestra en la tabla 8.6. Consulta 8.1 Predicado vstamp:before ( ) en XQuery 1 declare function vstamp:before($doc_uri, $v1,$v2) as xs:boolean{ 2 doc($doc_uri)/id($v1)/descendant::version/*[@xml:id=$v2] 3 }; Ejemplo de Uso vstamp:before('acm.vxml','v2','v4')

192 174 Capítulo 8. Construcción del Sistema Gestor y de Consultas Tabla 8.6: Predicados de Comparación entre dos versiones y su representación en XPath Predicados v 1 v 2 v 1 v 2 v 1 v 2 v 1 v 2 v 1 v 2 parent(v 1,v 2 ) child (v 1,v 2 ) Signicado id($v1)/descendant::version[@xml:id=$v2] id($v1)/descendant-orself::version[@xml:id=$v2] id($v1)/ancestor::version[@xml:id=$v2] id($v1)/ancestor-orself::version[@xml:id=$v2] id($v1)=id($v2) id($v1)/parent::version[@xml:id=$v2] id($v1)/child::version[@xml:id=$v2] La implementación de los predicados versión - región de versionado se ha realizado en base a funciones de usuario en XQuery, de modo que pueden ser usadas de forma transparente en las consultas de versionado. De este modo, para cada uno de los predicados de la tabla 8.4 se ha establecido su función XQuery correspondiente. En la consulta 8.2 se muestra el predicado (vbelongto) junto con un ejemplo de uso que comprueba si una versión pertenece a una región de versionado en XQuery. Como vimos en el apartado anterior, y en detalle en el capítulo 5, el predicado vbelongto se establece en base a dos condiciones: que la versión se encuentre entre los descendientes de start inclusive el mismo y no se encuentre entre los descendientes del conjunto de identicadores de end inclusive ellos mismos. Para realizar ambas comprobaciones se ha utilizado la función proporcionada por id() XPath que dereferencia el valor de los atributos start (línea 2) y end (línea 3) a los elementos del árbol de versionado a los que hace referencia para, posteriormente, extraer los descendientes (línea 2 y 3) que nos permitan vericar las dos condiciones anteriormente expuestas (línea 4). Esta consulta recibe como argumentos el documento vxml ($vdoc_uri), la región de versionado $vv dada y el identicador de versión ($v) que se desea saber si pertenece. Para este ejemplo de uso esta consulta devuelve el valor verdadero pues la versión v 2 pertenece a la región de versionado [v 1 - {v 3 v 6 }]. Consulta 8.2 Operator vstamp:vbelongto (ɛ) en XQuery 1 declare function vstamp:vbelongto($vdoc_uri,$vv,$v) as xs:boolean { 2 let $Dstart:=doc($vDoc_Uri)/id($vv)[1]/descendant-or-self::*/@xml:id 3 let $Dend:= doc($vdoc_uri)/id($vv[position()>1])/descendant-or-self::*/@xml:id 4 return (($Dstart=$v) and (not($dend=$v))) 5 }; Ejemplo de Uso let $vv:=('v1','v3','v6') 8 return vstamp:vbelongto('acm.vxml',$vv,'v2') Nótese que habitualmente usaremos estos predicados durante el recorrido de un documento vxml, para por ejemplo vericar si un elemento vxml contiene la versión dada, de modo que este predicado se puede establecer a partir de un elemento vxml. En este caso no es necesario el árbol de versionado pues éste se encuentra en el contexto del elemento XML procesado y donde la región de versionado se establece con los atributos v:start y v:end del elemento XML. La operación anterior vbelongto aplicada a un elemento vxml se muestra en

193 Predicados de Versionado: vstamp 175 la consulta 8.3 donde se ilustran dos posibles implementaciones: la primera de ellas utiliza la consulta anterior (línea 1-6), es decir, recibe un elemento vxml $ev que se transforma a una región de versionado $vv mediante la función eetovv y se procede a la llamada del predicado de la consulta anterior, consulta 8.2. La segunda ha sido especícamente diseñada para el trabajo sobre un elemento vxml $ev accediendo directamente a los atributos que forman la región de versionado v:start y v:end (líneas 7-11). Ambas consultas comprueban si la versión V 9 pertenece a la región de versionado asociada al author identicado por d1e13 ([v 1 - {v 9 }]), devolviendo en este caso el valor falso pues se borra este elemento en esa versión. Consulta 8.3 Operator vstamp:vbelongto (ɛ) en XQuery sobre velemento Implementación declare function vstamp:evtovv($ev) { 2 (xs:string($ev/@v:start),xs:string($ev/@v:end)) 3 }; 4 declare function vstamp:vbelongto($ev,$v) as xs:boolean { 5 vstamp:vbelongto('acm.vxml',vstamp:evtovv($ev),$v) //Llamada al operador }; Implementación declare function vstamp:vbelongto($ev,$v) as xs:boolean{ 8 let $Dstart:=$ev/id($ev/@v:start)/descendant-or-self::*/@xml:id 9 let $Dend:=$ev/id($ev/@v:end)/descendant-or-self::*/@xml:id 10 return (($Dstart=$v) and (not($dend=$v))) 11 }; Ejemplo de Uso vstamp:vbelongto(doc('acm.vxml')//author[@idf='d1e13'],'v9') Además de estas dos clases de predicados existen aquellos que nos permiten comparar regiones de versionado pudiéndose establecer una relación entre una región de versionado y un conjunto de versiones del árbol de versionado, que pueden ser a su vez: otra región de versionado, una lista de identicadores de versionado o un par de versiones [v1-v2] que establecen un camino en el árbol de versionado. La implementación de estos predicados en XQuery se ha realizado en base a funciones XQuery que permiten la comparación de secuencias de valores/nodos, pues en denitiva, en nuestro casos estas operaciones comprobarán la relación existente entre dos secuencias de identicadores de versiones. Se puede optar por dos posibles implementaciones: 1) utilizar los operadores every-some y satises de XQuery para vericar si un conjunto de nodos, identicadores de versión en nuestro caso, cumplen una o varias condiciones con respecto a otro conjunto de nodos o 2) utilizar los operadores intersect - except de XPath que trabajan sobre una secuencia de nodos. En la consulta 8.4 se muestra la implementación del operador vrcontains junto con un ejemplo de uso que determina si una región de versionado asociada a un elemento XML RV 1 contiene a otra región de versionado VV 2, lo cual sucede si y sólo si se cumple que todas las versiones en VV 2 se encuentran en RV 1. Para su implementación se han usado las funciones adicionales: evtolv que recupera la lista de identicadores de un elemento vxml y vvtolv que recupera la lista de identicadores contenidos en una región de versionado. De este modo, una vez se tienen ambas secuencia de identicadores se comprueba si su intersección devuelve RV 2 para determinar si una contiene a la otra. A continuación analizaremos, en mayor detalle, el funcionamiento de este predicado, vr- Contains, partiendo de la consulta anterior la cual recupera todos los elementos author que

194 176 Capítulo 8. Construcción del Sistema Gestor y de Consultas Consulta 8.4 Predicado vstamp:vrcontains en XQuery 1 declare function vstamp:eetolv($ev) { 2 let $lv:=( $ev/id($ev/@v:start)/descendant-or-self::* except ( 3 $ev/id($ev/@v:start)/descendant-or-self::* intersect 4 $ev/id($ev/@v:end)/descendant-or-self::* 5 )/@xml:id) 6 for $i in $lv (: return as sequence:) 7 return xs:string($i/@xml:id) 8 }; 9 declare function vstamp:vrcontains($ev1,$vv2) as xs:boolean { 10 let $lv1:=vstamp:eetolv($ev1) 11 let $lv2:=vstamp:vvtolv('acm.xml',$vv2) 12 return count($lv1 intersect $lv2)=count($lv2) 13 }; Ejemplo de Uso let $vv:=('v1','v5','v6','v9') 16 return vstamp:vrcontains(doc('acm.vxml')//author,$vv) contienen la región de versionado VV 2 =[V 1 -{V 5, V 6, V 9 }]. Author[1]: RV 1 =[V 1 -V 9 ] ˆ eetolv(rv 1 )={V 1, V 2, V 3, V 4, V 5, V 6, V 7, V 8, V 10 }=$lv1 ˆ vvtolv(vv 2 )={V 1, V 2, V 3, V 4 }=$lv2 ˆ RV 1 contains VV 2 count($lv1 intersect $lv2)=count($lv2); como count ({V 1, V 2, V 3, V 4 }) = count ({V 1, V 2, V 3, V 4 }), la región de versionado RV 1 contiene a VV 2. Author[2]: RV 1 =[V 2 -V 9 ] ˆ eetolv(rv 1 )={V 2, V 3, V 4, V 5, V 6, V 7, V 8, V 10 }=$lv1 ˆ vvtolv(vv 2 )={V 1, V 2, V 3, V 4 }=$lv2 ˆ RV 1 contains VV 2 count($lv1 intersect $lv2)=count($lv2); como count ({V 2, V 3, V 4 }) count ({V 1, V 2, V 3, V 4 }), la región de versionado RV 1 no contiene a VV 2. En la consulta 8.5 se ilustra la implementación del operador vrconstainslist en XQuery, el cual se encarga de vericar si una región de versionado dada contiene una lista de identicadores de versión. Nótese que no existe realmente mucha diferencia con el predicado anterior pues la operabilidad del predicado es la misma, la cual consiste en realizar la intersección de ambas listas de identicadores. De este modo el único cambiado se traduce en la llamada a las funciones de conversión oportunas para obtener las dos listas de identicadores. El resto de predicados de regiones de versionado han sido desarrollados siguiendo la misma metodología o utilizando los predicados XQuery some/every - satises. Con nes puramente prácticos hemos decidido agrupar los predicados de versionado en un mismo módulo denominado vstamp.

195 Consultas sobre vdocumentos: vxquery 177 Consulta 8.5 Predicado vstamp:vrcontainslist en XQuery 1 declare function vstamp:vrcontainslist($ev1,$lv) as xs:boolean { 2 let $lv1:=vstamp:eetolv($ev1) //Versiones en $ev1 3 let $lv2:=$ev1/id($lv)/self::* //Lista de versiones 4 return count($lv1 intersect $lv2)=count($lv2) 5 }; Ejemplo de Uso let $lv:=('v1','v2','v4','v8') 8 return vstamp:vrcontainslist(doc('acm.vxml')//author[@idf='d1e13'],$lv) 8.3. Consultas sobre vdocumentos: vxquery En este apartado se analiza un amplio conjunto de consultas que pueden realizarse sobre los documentos XML versionados. Hemos decidido incluir todas las consultas en un mismo módulo denominado vquery. Una de las principales ventajas de la técnica propuesta en esta tesis es la posibilidad de utilizar diversos lenguajes estándar de consulta XML para llevar a cabo estas consultas (principalmente XQuery y XSLT), tal y como se verá a lo largo de la sección. Estas consultas pueden ejecutarse en la siguiente dirección: De este modo en este apartado mostraremos la implementación de las consultas sobre los elementos de un documento vxml que denimos en el capítulo 6: proyección, instantánea y consultas por rangos. Además estas consultas serán usadas en la batería de tests para vericar la eciencia de la técnica propuesta en esta tesis Proyección de Versionado Para recuperar la historia completa de un nodo del documento basta aplicar la operación de proyección sobre dicho nodo. La implementación se ha realizado en base a una función de usuario XQuery denominada vhistory que se encarga justamente de realizar dicho proceso tal y como se muestra en la consulta 8.6. Consulta 8.6 Funcion vquery:vhistory. Proyección de Versionado en XQuery 1 declare function vquery:vhistory($ev as element()) { 2 element {name($ev)} { 3 for $x in $ev/v:data 4 return $x 5 } Ejemplo de Uso <result>{ 8 vquery:vhistory(doc('acm.vxml')//author[@idf='d1e13']) 9 }</result> El resultado de esta consulta se muestra en la gura 8.1 donde se ha decidido que la función vhistory recupere el nombre del elemento sobre el cual se quiere conocer su historia junto con todos los contenidos que ha tenido a lo largo de su historia. Nótese que la salida generada en esta consulta muestra la información recuperada en formato vxml, es decir, obtiene la información como v:data y con región de versionado, pero nos gustaría resaltar que podría generarse cualquier otro formato de salida cambiando ligeramente la consulta. Observando la salida podemos comprobar que el author de la consulta ha tenido tres valores distintos a lo largo de toda su historia.

196 178 Capítulo 8. Construcción del Sistema Gestor y de Consultas 1 <result> 2 <author> 3 <v:data v:start='v1' v:end='v3 V10'>Luis Arevalo</v:data> 4 <v:data v:start='v3' v:end='v9'>luis J. Arevalo</v:data> 5 <v:data v:start='v10' v:end='now'>luis Arevalo Rosado</v:data> 6 </author> 7 </result> Figura 8.1: Resultado de la operación de proyección sobre el author 'd1e13' Instantánea de Versionado El objetivo de esta operación es recuperar aquellos elementos del documento que son válidos para una determinada versión. Debemos recordar que, en nuestro caso, cada una de las etiquetas del documento se encuentran meta-marcadas con regiones de versionado de forma que, para recuperar un elemento XML válido o incluso el documento completo, es necesario determinar si para el elemento en cuestión la versión que se desea recuperar está incluida en su región de versionado asociada Instantánea de Elemento en XQuery En esta primera sección vamos a analizar esta operación en el lenguaje de consulta XQuery, es decir, estudiaremos cómo recuperar todos aquellos elementos XML de entre los que se especiquen que sean válidos para una determinada versión. Consulta 8.7 Función vquery:vsnapshot. Instantánea de Elemento en XQuery para V1 1 declare function vquery:vsnapshot($ev,$v)as element()* { 2 if (vstamp:vbelongto($ev,$v)) then 3 element {name($ev)} { 4 for $x in $ev/v:attrib[vstamp:vbelongto(.,$v)] 5 return attribute {$x/@name} {$x/@value}, 6 $ev/v:data[vstamp:vbelongto(.,$v)]/text(), 7 for $x in $ev/child::*[name(.)!='v:data' and name(.)!='v:attrib'] 8 return vquery:vsnapshot($x,$v) 9 } 10 else () 11 }; Ejemplo de Uso <result>{ 14 for $s in doc('acm.vxml')//author 15 return vquery:vsnapshot($s,'v1') 16 }</result> Para ello, hemos denido la función vsnapshot (consulta 8.7) que se apoya en el operador vbelongto denido anteriormente para determinar si un elemento es válido y recuperar su información válida. De este modo, si el elemento a procesar pertenece a la versión dada (línea 2), se recupera: 1) el elemento en cuestión (línea 3), 2) sus atributos válidos (línea 4, 5), 3) su contenido válido (línea 6) y 4) todos los elementos descendientes válidos (línea 7, 8). Nótese

197 Consultas sobre vdocumentos: vxquery 179 que los elementos descendientes válidos se recuperarán llamando recursivamente a la función vsnapshot. De este modo en la consulta 8.7 se muestra la función vquery:vsnapshot junto a un ejemplo de uso que recupera aquellos elementos author que son válidos para la versión V 1. En nuestro ejemplo concreto devolverá únicamente el primer elemento author, pues el segundo de ellos sólo es válido a partir de la versión V 2, tal y como se muestra en la gura <author AuthorPosition='1'> 2 Luis Arevalo 3 </author> Figura 8.2: Resultado de la consulta 8.7: Instantánea de un elemento XML Instantánea de Elemento en XPath En esta sección se muestra la operación del apartado anterior en el lenguaje XPath (consulta 8.8). Para ello sólo es necesario utilizar la función proporcionada por XPath, id(), para dereferenciar el valor de los atributos v:start y v:end y comprobar que las restricciones expuestas en el operador vbelongto se cumplen. Al igual que en la consulta anterior se obtendría únicamente el primer elemento author. Consulta 8.8 Instantánea de Elemento en XPath para V1 1 //author/v:data[not(id(./@v:end)/descendant-or-self::version/@xml:id='v1' and 2 (id(./@v:start)/descendant-or-self::version/@xml:id='v1')] Instantánea de Documento en XQuery Las consultas anteriores pueden devolver un determinado elemento del documento o incluso un conjunto de ellos (usando el constructor for) siempre y cuando se cumpla que pertenezcan a la versión solicitada. En este apartado mostramos la consulta que nos permite recuperar el documento válido para una determinada versión. Consulta 8.9 Función vquery:vdocsnapshot. Instantánea de Documento en XQuery para V1 1 declare function vquery:vdocsnapshot($vdoc_uri,$v)as element()* { 2 vquery:vsnapshot(doc($vdoc_uri)/v_document/versioned_doc/*,$v) 3 }; Ejemplo de Uso <result>{ 6 vquery:vdocsnapshot('acm.vxml','v1') 7 }</result> Para conseguir nuestro objetivo únicamente se debe llamar correctamente a la función vsnapshot denida anteriormente. De este modo se realiza la llamada con el elemento versioned_doc que contiene las raíces de todas las versiones del documento, recuperando aquella

198 180 Capítulo 8. Construcción del Sistema Gestor y de Consultas que es válida para la versión dada junto con toda su información válida. En la consulta 8.9 se muestra este proceso Instantánea Optimizada de Documento en XQuery Tal y como vimos en el capítulo 5 propusimos una función BelongTo optimizada debido a que la complejidad del algoritmo natural de pertenencia era computacionalmente alta. Este proceso natural, tal y como expusimos en el capítulo 5 y hemos comprobado en las secciones anteriores, requiere que por cada elemento XML, incluido v:data y v:attrib, del documento XML versionado se obtenga, mediante la función id(), la versión a la cual hacen referencia sus atributos de versionado y a continuación se recuperen todos sus descendientes y se veriquen las dos condiciones anteriores. Obviamente el coste computacional de la función id() no se puede reducir pues nuestra técnica se fundamenta en esta característica pero sí expusimos una mejora para evitar la constante recuperación de todos los descendientes de los atributos v:start y v:end, reduciendo la complejidad de O(n x m x k) a O(n x m) donde n es el número de elementos del documento, m el número de versiones y k=m el número de identicadores de versión en el atributo end. Consulta 8.10 Función vquery:vdoc2docopt. Instantánea de Documento Optimizada 1 declare function vstamp:belong_toopt($ev,$v) { 2 ($ev/id(@v:start)/@xml:id=$v/@xml:id and (not($ev/id(@v:end)/@xml:id=$v/@xml:id))) 3 }; 4 declare function vquery:vdocsnapshotopt($p,$v){ 5 if (vstamp:belong_tooptimizado($p,$v)) then element {name($p)} { 6 for $x in $p/v:attrib[vstamp:belong_tooptimizado(.,$v)] 7 return attribute {$x/@name} {$x/@value}, 8 $p/v:data[vstamp:belong_tooptimizado(.,$v)]/text(), 9 for $x in $p/child::*[local-name(.)!='data' and local-name(.)!='attrib'] 10 return f:vdocsnapshotopt($x,$v) 11 } else () 12 }; 13 declare function vquery:vdoc2docopt($vdoc_uri,$v ) { 14 let $vs:=doc($vdoc_uri)/descendant-or-self::*[@xml:id=$v]/ancestor-or-self::*[name(.) 15 ='version'] 16 return vquery:vdocsnapshotopt(doc($vdoc_uri)/v_document/*[2],$vs) 17 }; Ejemplo de Uso vquery:vdoc2docopt('acm.vxml','v1') En la consulta 8.10 puede observarse este nuevo proceso de recuperación en XQuery que consiste en: 1) obtener los identicadores de versión de todas las versiones anteriores a la versión dada en el árbol de versionado (línea 14) y 2) vericar que el valor del atributo v:start se encuentra entre ellas (hecho que representa que ha derivado de ella) y que el conjunto de identicadores del atributo v:end no está entre ellas (representando que no se ha eliminado en el camino) (línea 2). Como podemos comprobar en este caso se tienen que recuperar una única vez los antepasados de una versión (línea 14) y no constantemente. El resto de la consulta, desde la línea 4 a la 12, recupera la instantánea del documento para una determina versión, siendo este proceso igual que en la consulta 8.7.

199 Consultas sobre vdocumentos: vxquery 181 Consulta 8.11 Instantánea de Documento en XSLT 1 <xsl:stylesheet> 2 <xsl:param name='version'>v1</xsl:param> 3 <xsl:template match='*'> 4 <xsl:if test='not(id(./@v:end)//*/@xml:id=$version) and 5 (id(./@v:start)//*/@xml:id=$version)'> 6 <xsl:element name='{name(.)}'> 7 <xsl:for-each select='v:attrib[not(id(@v:end)//*/@xml:id= 8 $version) and (id(@v:start)//*/@xml:id=$version)]'> 9 <xsl:attribute name='{@name}'> 10 <xsl:value-of select='@value'/> 11 </xsl:attribute> 12 </xsl:for-each> 13 <xsl:for-each select='v:data[not(id(@v:end)//*/@xml:id= 14 $version) and (id(@v:start)//*/@xml:id=$version)]'> 15 <xsl:value-of select='normalize-space()'/> 16 </xsl:for-each>. 17 <xsl:apply-templates select='* except (v:attrib,v:data)'/> 18 </xsl:element> 19 </xsl:if> 20 </xsl:template> 21 <xsl:template match='v_document'> 22 <xsl:apply-templates select='* except version_tree'/> 23 </xsl:template> 24 <xsl:template match='versioned_doc'> 25 <xsl:apply-templates select='*'/> 26 </xsl:template> 27 </xsl:stylesheet> Instantánea de Documento en XSLT En este apartado se muestra la recuperación de un documento válido usando el lenguaje de transformación XSLT (consulta 8.11). El único parámetro de entrada de la hoja de estilo es la versión a recuperar (línea 2) y a continuación se procesa cada uno de los posibles nodos del documento vxml: elemento XML con región de versionado, elementos v:attrib y elementos v:data. La hoja de estilo empieza a procesar el documento vxml por el nodo versioned_doc y a partir de él verica si la región de versionado de cada elemento XML contiene a la versión dada (línea 4) y, si es así, recupera todos atributos válidos (línea 7) y contenido válido (línea 13) para dicho elemento. Para nalizar se procede a la llamada recursiva de los elementos descendientes mediante la instrucción <xsl:apply-templates> (línea 17) Regiones de Versionado Todas las consultas expuestas en el apartado anterior comprueban si una determinada versión cumple una condición con respecto a una región de versionado, siendo en el caso anterior, la condición evaluada la de validez. Sin embargo, en algunas ocasiones, resulta de gran utilidad poder analizar cómo interactúan los elementos versionados con un conjunto de versiones. Así por ejemplo, podríamos estar interesados en recuperar aquellos elementos XML que son válidos en las versiones {V 1, V 2, V 6 }. En este apartado nos centraremos en analizar este tipo de consulta, que hemos denominado consulta por rangos, utilizando XQuery para su formulación.

200 182 Capítulo 8. Construcción del Sistema Gestor y de Consultas Consultas por Rangos El objetivo de las consultas por rango es recuperar aquella información que cumple una determina condición entre dos conjuntos de versiones. Tal y como expusimos en la sección 2 de este capítulo podían existir distintos casos tales como: comparar dos regiones de versiones, una región de versionado con un conjunto de versiones, con una lista de identicadores de versionado o con un par de versiones [v1-v2] que establecen un camino en el árbol de versionado. Para cada uno de éstos analizamos distintos predicados tales como contener, anterior, igual, etc. En este apartado y usando estos predicados analizaremos la consulta de rango basada en el predicado contains aunque el uso del resto de predicado se haría de forma similar. Consulta 8.12 Función vquery:vrcontains. Recuperación por Rangos en XQuery 1 declare function vstamp:vrcontains($ev1,$vv2) as xs:boolean { 2 let $lv1:=vstamp:eetolv($ev1) 3 let $lv2:=vstamp:vvtolv('acm.vxml',$vv2) 4 return count($lv1 intersect $lv2)=count($lv2) 5 }; 6 declare function vquery:vrcontains($ev1,$vv2) as element()* { 7 if (vstamp:vrcontains($ev1,$vv2)) then $ev 8 else () 9 }; Ejemplo de Uso <result>{ 12 let $vv:=('v1','v5','v6','v9') 13 for $s in doc('acm.vxml')//author 14 return vquery:vrcontains($s,$vv) 15 }</result> En la consulta 8.12 se muestra el proceso de recuperación de aquellos elementos XML cuya región de versionado contiene a otra dada (contains) en XQuery. Para ello nos hemos ayudado del predicado de versionado contains (implementado en el apartado 8.2 como vstamp:vrcontains) que comprueba si v RV 2, v RV1 (línea 4). La consulta recupera aquellos elementos author cuya región de versionado contiene a la región [V 1 -{V 5 V 6 V 9 }]. Hemos decidido incluir en la consulta el predicado vrcontains para tener una visión más completa de la consulta en cuestión. Al tratarse del mismo ejemplo que el caso del predicado vrcontains, tal y como se explicó en este apartado, devolvería únicamente el primer elemento author pues el segundo empieza su ciclo de vida en la versión V 2 y por tanto no contiene la versión V 1. En la consulta 8.13 se ilustra la misma consulta anterior donde en lugar de comparar una región de versionado con otra se compara una región con respecto a un conjunto de identi- cadores de versión del árbol de versionado. La diferencia entre ambas consultas es mínima pues en denitiva sólo se diferencian en los parámetros de entrada que recibe. Recordemos, tal y como expusimos en el apartado 7.2, que los predicados en rango siempre realizan la comparación en base a una secuencia de identicadores de versión, de modo que, sólo dieren las consultas en las llamadas previas para la conversión del tipo de dato de rango recibido a esta secuencia de identicadores. En el primer caso se procedería a la llamada de la función evtolv y en el segundo caso no haría falta pues el parámetro de entrada ya es una lista de identicadores. Como hemos mencionado podría existir un último caso, comparación de una región con respecto a un camino del árbol de versionado, donde se utilizarían unas funciones

201 Consultas sobre vdocumentos: vxquery 183 de conversión para convertir este camino a una secuencia de identicadores. El resultado de esta consulta es el mismo que la anterior pues las versiones {V 1, V 2, V 4 } están incluidas en la región [V 1 -{V 5 V 6 V 9 }]. Consulta 8.13 Función vquery:vrcontainslist. Recuperación por Rangos en XQuery 1 declare function vquery:vrcontainslist($ev1,$lv) as element()* { 2 if (vstamp:vrcontains($ev1,$lv)) then $ev 3 else () 4 }; Ejemplo de Uso <result>{ 7 let $lv:=('v1','v2','v4') 8 for $s in doc('acm.vxml')//author 9 return vquery:vrcontainslist($,$lv) 10 }</result> Consultas Continuas En muchas ocasiones cuando se almacena la historia de un determinado objeto (elemento en nuestro caso) es necesario recuperar aquellos elementos que son válidos durante un conjunto de versiones, denominándose a estas consultas como consultas continuas. Así, en la consulta 8.14 se muestra el proceso de recuperación de aquellos autores del documento acm.vxml que son válidos durante al menos tres versiones en cualquiera de las ramas descendientes de su rango de versionado en XQuery. Para ello se ha utilizado una función de usuario denominada minduration que devuelve un valor entero con la duración mínima de dicho nodo en todas las ramas descendientes del árbol de versionado. De este modo, si la duración de validez por una rama es de 4 versiones y por otra rama no tiene n (y es superior a 4) esta función devolvería 4 como duración mínima y en este caso al ser superior a 3 se recuperaría dicho nodo. Consulta 8.14 Función vquery:continuous. Recuperación por Duración en XQuery 1 declare function f:minduringversion($e,$ev) { 2 let $end:=$ev/id($ev/@v:end) 3 return 4 if (empty($e/*) or ($end/@xml:id=$e/@xml:id)) 5 then 1 6 else min(f:minduringversion($e/*,$ev)) }; 8 declare function f:minduration($ev) { 9 f:minduringversion($ev/id($ev/@v:start),$ev) 10 }; Ejemplo de Uso <result>{ 13 for $s in doc('acm.vxml')//author 14 where f:minduration($s)>3 15 return $s 16 }</result> Usando esta función, u otras denidas como maxduration se podría formular un amplio conjunto de consultas como: recuperar aquellos elementos que han sido modicados inmediatamente después de ser insertados o aquellos elementos cuya duración está comprendida entre

202 184 Capítulo 8. Construcción del Sistema Gestor y de Consultas dos valores o aquellos elementos que tienen una duración máxima de n versiones, etc Actualización de un vdocumento: vupdate Las consultas anteriores conciben un documento vxml poblado con múltiples estados generados a lo largo del tiempo. En este apartado, y siguiendo las pautas marcadas en la sección 6.2, mostramos la implementación realizada en XQuery de algunas de las operaciones de actualización de un documento vxml mostradas en la tabla 6.2. La implementación de estas operaciones de inserción, borrado y actualización se apoya en el lenguaje XUpdate [Laux 00]. Hemos clasicado todas estas operaciones dentro de un mismo espacio de nombres denominado vupdate Validez en el Proceso de Actualización Como expusimos en el capítulo 6 (6.2.4), cuando sobre un documento XML se realizan cambios, la nueva versión no se lleva a cabo exclusivamente en base a la ejecución de una única primitiva sino a partir de un conjunto de ellas. La ejecución de este conjunto de primitivas se caracteriza por ser secuencial, es decir, que la ejecución de una primitiva depende de las operaciones anteriormente realizadas. Este hecho debe ser tenido en cuenta en el proceso de actualización de la región de versionado asociada a un elemento pues la ejecución de la anterior primitiva puede haber afectado a la ejecución actual. Tal y como también expusimos en dicho capítulo, este problema ha sido resuelto fácilmente con nuestra técnica. Para poder ejecutar cada una de las primitivas de cambio previamente se debe comprobar si el elemento XML a procesar es válido en el proceso de actualización. Determinamos mediante un ejemplo en dicho capítulo que la validez de los elementos del grafo vxml en el proceso de actualización, en lugar de realizarse en base a la versión actual como hemos expuesto anteriormente, debe hacerse en base a la nueva versión, pues ya se ha añadido previamente el nuevo identicador de versión. Por este motivo en todas las consultas que se muestran en este apartado en lugar de utilizar la función vbelongto usaremos la función vbelongtoupdate. Nótese que esta función vbelongtoupdate es igual que vbelongto (exceptuando por la particularidad que recibe el identicador de versión de la nueva versión), pero hemos decidido mantener el nombre vbelongtoupdate con el objetivo de claricar las consultas Inserción de Elementos Mediante esta operación se añade un nuevo elemento al documento XML versionado, lo que se traduce en un nuevo documento vxml que incluye el elemento insertado junto con su región de versionado, tal y como se ilustra en la consulta En primer lugar este algoritmo busca el elemento $idf padre (línea 2) para, posteriormente, utilizar la función vconversion:convert (línea 7) que adapta el elemento XML de entrada $xml (línea 13) a su representación vxml. Finalmente se procede a insertar el nodo creado como hijo descendiente del elemento idf en la posición $pos (línea 8), teniendo únicamente en cuenta los elementos válidos de la versión $new_v(vstamp:vbelongtoupdate). En el caso concreto de la consulta 8.15 se añade un elemento author en la primera posición del elemento padre d1e12 (Authors). Tal y como se expuso en la sección 6.2, los atributos de versionado de los nuevos

203 Actualización de un vdocumento: vupdate 185 Consulta 8.15 Función vquery:insertelement. Inserción de Elemento en XQuery 1 declare function vupdate:insertelement($file,$idf,$nodeins,$pos,$dim_now,$new_v) { 2 let $node:=doc($file)//*[./@idf=$idf] 3 return 4 if (empty($node)) 5 then <error>there is not a valid element </error> 6 else 7 let $b:=vconversion:convert($nodeins,$new_v) 8 return update insert $b preceding $node/*[name(.)!='v:data' and 9 name(.)!='v:attrib' and vstamp:vbelongtoupdate(.,$new_v)][$pos] 10 }; Ejemplo de Uso <result> { 13 let $xml:=<author AuthorPosition='3'></author> 14 return vupdate:insertelement('acm.vxml','d1e12',$xml,1,'v1','v2') 15 } </result> elementos creados toman los siguientes valores: v:start, el valor de la nueva versión versión y v:end, el valor especial now Borrado de Elementos Esta primitiva borra tanto el nodo proporcionado en la entrada como todo sus descendientes. Su implementación en XQuery requiere de una función recursiva que haga este proceso (consulta 8.16). La consulta comienza buscando el elemento XML origen a borrar (línea 2) para a continuación proceder al borrado recursivo de todos sus descendientes, incluyéndolo a él mismo (línea 6). Esta última operación actualiza los atributos de versionado del elemento en cuestión (línea 12), añadiendo el identicador de la nueva versión al atributo v:end, y de igual forma para sus atributos o contenido válidos (línea 16). Finalmente realiza la llamada recursiva de aquellos elementos válidos de la versión actual, $dim_now, (línea 17). En el caso concreto de la consulta mostrada se procede al borrado del elemento d1e9 (article) para la versión actual V 3 con identicador de nueva versión igual a V Actualización de Atributos Hemos decidido incluir en este apartado una operación sobre los atributos, concretamente, la operación de actualización que integra tanto una operación de borrado como una de inserción. En la consulta 8.17 se muestra la implementación de la primitiva actualización de un atributo XML. Nos gustaría recordar que un atributo se encuentra identicado por el elemento XML que lo contiene, de modo que el identicador idf recibido hace referencia al elemento XML padre. En primer lugar se procede a eliminar el atributo actual (línea 10) y posteriormente se añade el nuevo atributo al documento vxml (línea 13). Esta operación implica la generación de un nuevo elemento v:attrib en el elemento padre.

204 186 Capítulo 8. Construcción del Sistema Gestor y de Consultas Consulta 8.16 Función vquery:deleteelement. Borrado de Elemento en XQuery 1 declare function vupdate:deleteelement($file,$idf,$dim_now,$new_v) { 2 let $node:=doc($file)//*[./@idf=$idf] 3 return 4 if (empty($node)) 5 then <error>there is not a valid element </error> 6 else vupdate:deleterecursive($file,$node,$dim_now,$new_v) 7 }; 8 declare function vupdate:deleterecursive($file,$node,$dim_now,$new_v) { 9 if (empty($node)) 10 then () 11 else 12 vupdate:updateend($node,$dim_now,$new_v), 13 for $x in doc($file)//*[./@idf=$node/@idf]/child::*[vstamp:vbelongto(.,$new_v)] 14 return 15 if (name($node)='v:data' or name($node)='v:attrib') 16 then vupdate:updateend($node,$dim_now,$new_v) 17 else vupdate:deleterecursive($file,$x,$dim_now,$new_v) 18 }; Ejemplo de Uso <result> { 21 vupdate:deleteelement('acm.vxml','d1e9','v3','v9') 22 } </result> Consulta 8.17 Función vquery:updateattribute. Actualización de un Atributo en XQuery 1 declare function vupdate:deleteattribute($file,$idf,$name,$dim_now,$new_v) { 2 let $node:=doc($file)//*[./@idf=$idf] 3 let $data:=$node/v:attrib[./@name=$name and vstamp:vbelongto(.,$dim_now)] 4 return 5 if (empty($data)) 6 then <error>there is not a valid attribute data. </error> 7 else vupdate:updateend($data,$dim_now,$new_v) 8 }; 9 declare function vupdate:updateattribute($file,$idf,$name,$value,$dim_now,$new_v){ 10 if (empty(vupdate:deleteattribute($file,$idf,$name,$dim_now, $new_v))) 11 then 12 let $node:=doc($file)//*[./@idf=$idf] 13 return update insert <v:attrib v:start='{$new_v}' v:end='now' name='{$name}' 14 value='{$value}'/> preceding $node/*[1] 15 else false 16 }; Ejemplo de Uso <result>{ 19 vupdate:updateattribute('acm_v1.xml','d1e20','authorposition',2,'v2','v5') 20 }</result> 8.5. Consultas de Diferencias: vdi Una de las operaciones más habituales de todo sistema de versionado es la obtención de las diferencias existentes entre dos versiones del objeto versionado para así poder realizar análisis causales de su evolución y determinar cuál ha sido su comportamiento, así como poder predecir pautas o conductas futuras. En este apartado, y enfocado a los documentos XML versionados, expondremos esta consulta formulada usando distintos lenguajes de consulta XML. Así, en

205 Consultas de Diferencias: vdi 187 primer lugar utilizaremos el lenguaje XQuery para obtener las diferencias en un formato XML propio y, posteriormente, usando el lenguaje XSLT, obtendremos una representación más intuitiva y gráca (HTML) de las diferencias. Consulta 8.18 Función vdi:changes. Diferencias en XQuery 1 declare function vdiff:changes($ev,$v) as element()*{ 2 if (($ev/@v:start=$v)) 3 then <inserted>{$ev}</inserted> 4 else let $b2:=$ev/id($ev/@v:end)/@xml:id 5 return 6 if (($b2=$v)) 7 then <deleted>{$ev}</deleted> 8 else() 9 }; Ejemplo de Uso <result>{ 12 for $s in doc('acm.vxml')//author 13 return vquery:changes($s,'v2') 14 }</result> Consultas de Diferencias en XQuery En este primer caso hemos usado el lenguaje XQuery para formular esta consulta, la cual devuelve qué elementos, atributos y contenido ha sido añadido o eliminado de un documento vxml para la versión dada. En denitiva el algoritmo debe comprobar si la versión dada se encuentra en el atributo v:start o v:end de cada uno de los elementos del documento, representando, de este modo, que dicho nodo ha sido añadido o eliminado respectivamente de esta versión como se muestra en la consulta En la gura 8.3 se muestra el formato de salida de esta consulta. Se trata de un documento XML de formato propio indicando cuáles de los elementos del documento han sido añadidos (etiqueta inserted) y cuáles han sido borrados para la versión dada (etiqueta deleted). En el caso de la versión V 3 podemos comprobar que se ha eliminado el contenido asociado a una etiqueta que posteriormente ha sido insertado, lo que indica que se ha realizado una operación de actualización del contenido asociado a un elemento. Obviamente el formato de la salida puede enriquecerse con un mayor grado de información sobre las diferencias encontradas. 1 <result xmlns:v=' > 2 <deleted> 3 <v:data v:start='v1' v:end='v3 V10'>Luis Arevalo</v:data> 4 </deleted> 5 <inserted> 6 <v:data v:start='v3' v:end='v9'>luis J. Arevalo</v:data> 7 </inserted> 8 </result> Figura 8.3: Salida del Algoritmo de Diferencias en XQuery Además de la consulta anterior, y puesto que se mantiene constancia de cómo ha evolucionado el documento XML, podemos formular consultas más complejas. Así imaginemos, por ejemplo, que deseamos recuperar aquellas etiquetas que han cambiado durante n versiones

206 188 Capítulo 8. Construcción del Sistema Gestor y de Consultas anteriores/posteriores de una versión dada en cualquiera de sus ramas. En este caso hemos de- nido una consulta XQuery, changes_n_after, que dada una versión cualesquiera comprueba, para todos los nodos del documento, si se han añadido o borrado un cierto número predenido de versiones anteriores o posteriores a la versión dada. Esta función, mostrada en la consulta 8.19, recibe como parámetros una región de versionado, una versión y un número que indica el número de versiones posteriores y determina si cumple esta condición. Para ello sólo necesita vericar si el atributo v:start o v:end del nodo en cuestión contiene el ancestor[$number] or descendant[$number] de la versión dada. Consulta 8.19 Función vdi:changesafter. Diferencias en "n"versiones posteriores en XQuery 1 declare function vdiff:changes_n_versions_after($ev,$v,$n){ 2 let $b2:=$ev/id($ev/@v:end)/ancestor::version[$n] 3 return 4 if (($ev/@v:start=$v) and ($b2/@xml:id=$v)) 5 then $ev 6 else () 7 }; Ejemplo de Uso <result>{ 10 for $s in doc('acm.vxml')//author 11 return vdiff:changes_n_versions_after($s,'v2',2) 12 }</result> Consultas de diferencias en XSLT Un aspecto importante que cuida todo sistema de control de versiones es una generación visual, intuitiva y fácil de interpretar de las diferencias existentes entre dos versiones de un mismo objeto. Este es el objetivo real que se persigue en esta sección donde se ha utilizado una hoja de estilo XSLT (di.xslt) para generar un documento HTML que proporcione una salida visual del documento original junto con la información añadida o eliminada. En la consulta 8.20 se ilustra el documento XSLT donde se ha utilizado el mismo algoritmo de la sección anterior para obtener la información variable de un documento vxml, es decir, comprobar para cada uno de los nodos si el atributo v:start o v:end contiene la versión recibida. De este modo si el nodo actual es válido se recupera su información sin ningún formato especial (línea 18), mientras que si el atributo v:start contiene la versión dada la información es recuperada en un formato distinto (línea 36). Si por el contrario es el atributo v:end quien contiene la versión (línea 30), la información se obtiene en una representación de texto tachado indicando con este hecho su borrado en esta versión. Por motivos de espacio hemos decidido no incluir la consulta XSLT completa, mostrando únicamente el algoritmo para los elementos XML; se procederá de la misma forma para los atributos (v:attrib) y el contenido (v:data). Finalmente en la gura 8.4 se muestra la salida HTML de diferencias para el documento acm.vxml, al pasar de la versión V 2 a la V 3, donde comprobamos que se ha actualizado el contenido asociado al primer Author.

207 Consultas de Diferencias: vdi 189 Consulta 8.20 Consulta de Diferencias en XSLT 1 <xsl:stylesheet xmlns:xsl=' xmlns:v=' 2 unex.es' version='2.0'> 3 <xsl:param name='source'>v2</xsl:param> 4 <xsl:param name='target'>v3</xsl:param> 5 <xsl:template match='/'> 6 <html><head><style type='text/css'> 7.add {background-color:#ffff99;} 8.del {text-decoration: line-through;} 9 </style></head><body> 10 <xsl:apply-templates select='/v_document/*[2]/*[1]'/> 11 </body></html> 12 </xsl:template> 13 <xsl:template match='@*'> 14 <xsl:copy/> 15 </xsl:template> 16 <xsl:template match='*'> 17 <!-- Es valido para esta version--> 18 <xsl:if test='not(id(./@v:end)/descendant-or-self::version/@xml:id=$source) 19 and (id(./@v:start)/descendant-or-self::version/@xml:id=$source) 20 and not (id(@v:end)/@xml:id=$target)'> 21 <xsl:value-of select='concat('<',name(.))'/> 22 <xsl:apply-templates select='@* 23 <xsl:apply-templates select='v:attrib'/> 24 <xsl:text>'>'</xsl:text><br/> 25 <xsl:apply-templates select='v:data'/> 26 <xsl:apply-templates select='* except (v:attrib v:data)'/> 27 <xsl:value-of select='concat('<;/',name(.),'>')'/><br/> 28 </xsl:if> 29 <!-- El nodo se ha borrado--> 30 <xsl:if test='id(@v:end)/@xml:id=$target'> 31 <span class='del'> 32 <!-- igual que 17 al 23--> 33 </span> 34 </xsl:if> 35 <!-- El nodo se ha insertado--> 36 <xsl:if test='id(@v:start)/@xml:id=$target'> 37 <span class='add'> 38 <!-- igual que 17 al 23--> 39 </span> 40 </xsl:if> 41 </xsl:template> 42 <xsl:template match='v:data'> </xsl:template> 45 <xsl:template match='@v:start'/> 46 <xsl:template match='@v:end'/> 47 <xsl:template match='v:attrib'> </xsl:template> 50 </xsl:stylesheet>

208 190 Capítulo 8. Construcción del Sistema Gestor y de Consultas Figura 8.4: Salida HTML de Diferencias entre dos Versiones 8.6. Conclusiones En este capítulo se ha detallado la implementación de las diferentes operaciones de consulta sobre un documento vxml y que constituyen el núcleo del módulo gestor de versiones. Tabla 8.7: Funciones XQuery del módulo vstamp Funciones Parámetros Descripción getdescendant, getancestor, getdescendantself, getancestorself, getparent, getchild vgetstartdescen, vgetenddescen, vgetstartdescenself, vgetenddescenself Before, Before_Self, After, After_Self, Equal, parent, child descend, descend-self, ancestor, ancestor-self, belongto, starts, end vrbefore, vrafter, vrequals, vrduring, vrcontains, vrstarts, vrmeets ($vdoc_uri, $v):$lv ($ev):$lv ($vdoc_uri, $v1, $v2):boolean ($ev, $v): booelean ($ev1, $ev2):boolean Recupera la lista de identicadores de versión descendientes / anteriores/ padre/ hijos de la versión $v para el documento $vdoc_uri Recupera la lista de identicadores de versión descendientes / anteriores de los atributos v:start y v:end para la región $ev Determina si el identicador de versión $v1 es anterior-self, posterior-self, igual, padre o hijo del identicador $v2 para $vdoc_uri Determina si el identicador de versión $v descendiente-self/ anterior-self / pertenece, comienza o naliza de la región $ev Determina si la region de versionado $ev1 es anterior / posterior / igual / durante / contiene / comienza / meets de la región $ev2 En primer lugar hemos analizado la implementación de los predicados de versionado para comparar conjuntos de versiones asociadas a un árbol de versionado. A continuación se han

209 Conclusiones 191 estudiado las operaciones de versionado. Entre ellas se han destacado las operaciones que permiten recuperar la historia de un determinado elemento, la recuperación de la información válida asociada tanto a un nodo como al documento completo y, nalmente, las operaciones que permiten las consultas basadas en rangos, es decir, aquellas en las que se comparan varias versiones de un árbol de versionado. Este conjunto de consultas servirá como base para realizar las baterías de pruebas en el próximo capítulo. Dentro de este capítulo tampoco nos hemos olvidado de las operaciones de actualización de un documento vxml así como las consultas que permiten obtener las diferencias entre las distintas versiones de un documento vxml. En las siguientes tablas resumiremos el conjunto de funciones de versionado implementadas en XQuery que pueden ser usadas en una consulta XQuery. vstamp que incluye aquellas funciones que implementan operaciones relacionadas con los predicados de versionado (tabla 8.7), vquery con las distintas consultas establecidas sobre documentos vxml (tabla 8.8) y nalmente, vupdate que incluye aquellas operaciones que se encargan de actualizar un documento XML versionado (tabla 8.9). Tabla 8.8: Funciones XQuery del módulo vquery Funciones Parámetros Descripción vhistory ($ev) Recupera la historia de un elemento XML vsnapshot ($ev,$v):$ev Recupera un elemento XML si es válido vsnapshotopt ($ev,$v):$ev Recupera un elemento XML si es válido usando el algoritmo optimizado vdocsnapshot ($vdoc_uri,$v):docxml Recupera el documento XML asociado a la versión $v changes_version ($vdoc_uri,$v):docxml Lista de cambios realizados para la versión $v del documento $vdoc_uri velement ($vdoc_uri,$v,$lv) Crea un elemento vxml con la región de versionado [($v,{$lv}] exist_version ($vdoc_uri,$v):boolean Determina si existe el identicador de versión $v en el documento $vdoc_uri get_versions ($vdoc_uri):item() Devuelve la lista de identicador de versión del documento $vdoc_uri Tabla 8.9: Funciones XQuery del módulo vupdate Funciones Parámetros Descripción add_version ($vdoc_uri,$v,$new_v) Añade el identicador $new al árbol de versionado de $vdoc_uri como descendiente de $v next_version ($vdoc_uri,$v) Devuelve el siguiente identicador de versión para la versión $v de $vdoc_uri insertelement, deleteelement, deleterecursive, insertattribute, deleteattribute, vupdateattribute, insertcontent, deletecontent, updatecontent ($vdoc_uri, param, $v, $new_v) * Implementación en XQuery de las primitivas de cambio XML. Los parámetros dependen de la operación.

210 192 Capítulo 8. Construcción del Sistema Gestor y de Consultas

211 Capítulo 9 Experimentación del Sistema Contenidos 9.1. Pruebas de rendimiento Experimentos Resultados Optimización en las Consultas de Validez de Versionado Resultados con otros Estándares Conclusiones a los Resultados Experimentales Interfaces de Versionado Servicio Web Interfaz Web-XQuery para la Gestión de Versiones (Extensión a exist) Interfaz AJAX para la Gestión de Versiones Conclusiones En este capítulo ponemos de maniesto la experimentación llevada a cabo sobre nuestro sistema de versionado. Esta experimentación se ha realizado en dos niveles: por una parte a nivel de rendimiento para comprobar el comportamiento de nuestra técnica de versionado ramicado y por otra parte en el desarrollo de distintos interfaces de versionado que nos permiten experimentar con la API pública de versionado denida en capítulos previos. En la sección 9.1 se analiza el rendimiento del sistema propuesto comparándolo con un sistema de versionado temporal (lineal). Para ello se estudiará el tiempo de ejecución de las consultas más habituales estudiadas en el capítulo anterior así como nos servirá para vericar si la solución propuesta en esta tesis es viable. Debemos recordar que se han propuesto dos algoritmos para la recuperación de información válida, denominados proceso natural y optimizado, de modo que se será también en este apartado donde comprobaremos si el algoritmo optimizado tiene mejores resultados en la práctica tal y como sucede a nivel teórico. En la sección 9.2 se muestran distintos clientes construidos para interactuar con el sistema de versionado propuesto. El desarrollo de estos clientes se ha basado en los principios de simplicidad y amigabilidad de uso. La primera implementación, realizada en XQuery, extiende la interfaz proporcionada por exist para la administración de dicha base de datos. La segunda, desarrollada en Ajax, permite la edición de documentos XML versionados en un entorno de trabajo asíncrono, mientras que la última implementa un conjunto de servicios web con el objetivo de poder ser consumidos por terceros agentes.

212 194 Capítulo 9. Experimentación del Sistema 9.1. Pruebas de rendimiento En esta sección expondremos los distintos experimentos llevados a cabo para evaluar nuestra técnica de versionado. Más concretamente, en primer lugar detallaremos las características de los documentos usados en estos experimentos para a continuación evaluar algunas de la consultas expuestas en el capítulo 8 sobre documentos XML versionados. Para ello utilizaremos dos procesadores XQuery, Saxon [Kay 01] y exist [Exist. 01] y además compararemos nuestros resultados con respecto a una solución temporal, que denominaremos tstamp, en la cual no existe soporte para versionado ramicado. Al nal de esta sección ilustraremos dos optimizaciones realizadas para mejorar el comportamiento de nuestra técnica así como el rendimiento obtenido usando otros estándares de consulta como XSLT Experimentos Para llevar a cabo los experimentos hemos desarrollado una aplicación Java que genera versiones de un documento XML. En ella, las versiones se producen mediante la ejecución aleatoria de las primitivas de cambio mostradas en la tabla 4.4 sobre documentos XML, dando una mayor probabilidad de ejecución a la operación de inserción de un elemento XML (30 %). Una vez seleccionada la primitiva a ejecutar, se eligen, también de forma aleatoria, tanto la versión sobre la cual se va a realizar la operación como el elemento XML sobre el cual se produce el cambio. Los test se han llevado a cabo para versionado lineal (la última versión del documento es seleccionada para ser modicada) y para versionado ramicado (cualquier versión puede ser seleccionada) donde, en éste último caso, la elección de la versión se realiza de forma aleatoria según distintas probabilidades (20 %, 50 % y 80 %) de seleccionar una versión distinta de la actual. Las versiones generadas se obtuvieron mediante la ejecución de 5, 10 y 20 cambios por versión para 100, 60 y 30 versiones respectivamente, permitiéndonos evaluar nuestra técnica en los siguientes casos: un gran número de versiones con pocos cambios (100 versiones - 5 cambios por versión), un número medio de versiones con algunos cambios (60-10) y un número reducido de versiones con muchos cambios (30-20). El documento que se ha usado para realizar estos experimentos ha sido el documento de registros de ACM en su formato XML ([ACM 02]), donde se han utilizado diferentes tamaños del mismo documento (pequeño (S), medio (M) y largo (L)), con el objetivo de poder evaluar mejor nuestra técnica con documentos de diferentes tamaños. En la gura 9.1 se muestran algunas de las características de los documentos XML versionados generados. Así, en primer lugar (.a), se ilustra el tamaño, número de elementos XML, atributos y contenidos de cada uno de los cheros (small - medium - large) del documento XML original, así como estos mismos parámetros del documento vxml resultante en su primera versión (V 1 ). En este primer apartado podemos comprobar que nuestros documentos XML versionado son mayores en tamaño que el documento XML original pues se han añadido al documento original tanto los atributos de versionado como los elementos v:data y v:attrib. En la parte inferior de la gura 9.1.b se muestra el tamaño en bytes de los vdocumentos resultantes después de aplicar los cambios expuestos anteriormente, donde podemos observar que nuestros documentos son ligeramente mayores en tamaño que una solución temporal, pues se añaden nuevas metamarcas al documento XML versionado (v:attrib, v:data, v:start y v:end) que provocan este aumento.

213 Pruebas de rendimiento 195 Figura 9.1: a. Características de acm.xml y acm.vxml. b. Tamaño de los documentos vxml resultantes. La primera columna de esta gura se encuentra etiquetada como tstamp la cual hace referencia a una implementación propia basada en aspectos temporales similar a [Wang 04a] y que será usada para comparar nuestra solución con respecto a una solución temporal. Esta implementación consiste en añadir atributos temporales a cada elemento XML que determinen la validez temporal de cada uno de los elementos XML. Estos documentos se han generado a partir de los documentos XML versionados lineales, usando para ello una hoja de estilos XSLT que ha realizado este proceso de conversión. Nótese que los documentos XML con versionado ramicado no pueden ser adaptados a esta solución temporal pues como hemos expuesto repetidamente las soluciones temporales no pueden representar aspectos ramicados Resultados El ordenador usado para la realización de las medidas mostradas en esta sección es un Pentium Quad Core 2,4 Ghz con 2GB de memoria, 360 GB IDE de disco duro con Ubuntu 8.04 como sistema operativo. El tiempo de recuperación que se ha medido se reere al tiempo de ejecución en una aplicación cliente, sin tener en cuenta el tiempo de carga del documento XML en memoria así como cualquier tiempo de transmisión. Hemos decidido analizar nuestra técnica usando dos procesadores XQuery: por un lado un procesador Java bajo consola (Saxon [Kay 01]) caracterizado por un modelo de datos XML muy compacto y rápido con soporte para XQuery y XSLT2 y, por otro lado, una base de datos nativa XML (exist [Exist. 01]) que incorpora características, no contempladas en Saxon, tales como serialización, concurrencia, usuarios, etc. En este último caso, exist ha sido congurada con una cache de 24MB para los datos y con un máximo de memoria Java de 512 MB. A partir de todos los datos anteriores, hemos decidido medir las consultas más habituales de todo sistema de versionado, es decir, la recuperación de la información válida contenida en un documento vxml. Así, hemos analizado las medidas en las siguientes consultas: Q1: Instantánea de elemento XML en XQuery (consulta 8.2). Obtiene todos los elementos author válidos para una versión dada. El tiempo de recuperación de esta consulta será la media de la recuperación de todas las versiones contenidas en el documento vxml.

214 196 Capítulo 9. Experimentación del Sistema Q2: Instantánea de documento XML en XQuery (consulta 8.9).Recupera el estado del documento para una versión dada. El tiempo de recuperación de esta consulta será la media para todas las versiones contenidas en un documento XML con versiones. Q3: Consultas de rango en XQuery (consulta 8.12). Recupera todos los elementos author que contiene un conjunto de versiones especicadas mediante una lista de versiones. El tiempo de recuperación será la recuperación de un conjunto de versiones, entre 2-5, escogidas aleatoriamente entre todas las versiones contenidas en un documento XML versionado Resultados en exist En las guras 9.2, 9.3 y 9.4 se muestra el tiempo de recuperación obtenido (medido en ms) usando la solución TimeStamp (tstamp) y VersionStamp (vstamp) para las consultas anteriormente mencionadas en la base de datos exist. Figura 9.2: Tiempo de Recuperación en exist de Q1 En relación al tiempo de recuperación de la consulta Q1, gura 9.2, podemos determinar que nuestra solución tiene un comportamiento menos eciente que la solución tstamp (temporal sin versionado ramicado) como se puede comprobar para cada uno de los casos considerados en esta gráca. Esto se debe a que la solución temporal utiliza los operadores <= y >= para vericar si un tiempo pertenece a un intervalo de tiempo y, por tanto, su condición se puede fácilmente especicar en la expresión XPath, mientras que en nuestra técnica, se tiene que recuperar todo el conjunto de identicadores de versión contenidos en una región de versionado (función id() XPath) y vericar las condiciones expuestas en la consulta 8.2 (comprobar que la versión dada está entre los descendientes de v:start y no está entre los descendientes de v:end). De este modo, el coste computacional de nuestra consulta de versionado lo establece la función vbelongto la cual tiene una complejidad de O (m 2 ) lo que provoca este comportamiento menos eciente. Analizando con mayor profundidad esta gura destaca igualmente la diferencia existente entre la ejecución de esta consulta en un marco de versionado lineal (serie vstamp Lineal)

215 Pruebas de rendimiento 197 frente a un marco de versionado ramicado (vstamp20 %, vstamp50 % y vstamp80 %). Por ejemplo para el caso S100/5 la consulta tarda entorno a 1200ms en un versionado lineal mientras que únicamente necesita entorno a 200ms para el caso de una ramicación de un 80 %. Esta diferencia se produce en el resto de casos considerados en la consulta agravándose según el tamaño del documento es mayor. Esta situación se debe a que en el proceso de validez, en el caso de versionado lineal, es necesario obtener un mayor número de descendientes de las versiones representadas en los atributos v:start y v:end pues existe únicamente una rama en el árbol de versionado mientras que el caso de ramicación sólo se obtiene los descendientes de la rama especicada en estos atributos. Esta factor se pone también de maniesto dentro de los distintos tipos de ramicación considerados: 20 %, 50 % y 80 %. Así por ejemplo podemos comprobar en el caso de M100/5 que los tiempos obtenidos son 1100ms, 800ms y 500ms respectivamente. Además en esta gura también resalta el incremento del tiempo de recuperación según aumenta el tamaño del documento. Esto se debe a que es necesario dereferenciar (función id() de XPath) un mayor número de elementos del documento. Esta situación se comprueba en la mayor diferencia existente entre la solución temporal y nuestra solución según crece el documento. De este modo podemos resumir, a partir de esta gura, que la consulta Q1 depende en gran medida de: 1. El número de ramas que tenga el documento. 2. El tamaño del documento. Estos dos factores se evidenciaron a nivel teórico en el capítulo 5 (sección 5.4.1) donde se constató que la complejidad del algoritmo de recuperación de información válida de todo el grafo era computacionalmente alto O (n x m x k) donde n es el número de nodos XML del documento vdocxml, m el número de versiones integradas en el documento vdocxml y k=m el número de identicadores del atributo end que deben dereferenciarse. Por este motivo también en el capítulo 5 se propuso un algoritmo optimizado, que vericaremos posteriormente en el apartado Optimización en las consultas (9.1.3), si éste mejora el rendimiento de esta operación, teniendo en cuenta que su complejidad es O(n x m). Nos gustaría resaltar que hemos decidido seguir denominando a este segundo algoritmo de pertenencia como optimizado, cuando realmente es el que usa nuestro sistema de versionado, pues ha sido denido con posterioridad al planteamiento inicial. Con respecto a Q2, gura 9.3, comprobamos que también se ponen de maniesto los dos factores mencionados en la consulta anterior, los cuales se agravan en este caso, tanto a nivel temporal como de versionado, pues en lugar de recuperar un subconjunto de elementos XML del documento vxml se necesita procesar todos los elementos válidos para la versión dada. Además si comparamos el tiempo obtenido de ambas consultas observamos que el tiempo resultante en Q2 se dispara considerablemente llegando a los 39 segundos en los documentos L100/5 en un versionado lineal. Esto se debe a que el algoritmo de recuperación en XQuery de todo un documento XML válido es recursivo, lo que incrementa considerablemente este tiempo de recuperación pues cuanto mayor es el documento a consultar mayor es mayor la pila de llamada recursiva del algoritmo como el documento XML generado por la consulta en memoria. Este tamaño ha sido tan signicativo que para los documentos XML versionados largo ha sido necesario cambiar el tamaño de los fragmentos XML generados por las consultas XQuery en exist pues producía una excepción de desbordamiento de memoria. Como

216 198 Capítulo 9. Experimentación del Sistema Figura 9.3: Tiempo de Recuperación en exist de Q2 se verá posteriormente usando la solución optimizada el tiempo resultante de esta consulta será muy próximo a la solución temporal. Además, también mostraremos posteriormente, que esta operación usando un lenguaje de consulta no recursivo, XSLT, el tiempo se reducirá enormemente. Figura 9.4: Tiempo de Recuperación en exist de Q3 Finalmente, los resultados obtenidos para la consulta Q3 se muestran en la gura 9.4. Estos valores nos conrman que los resultados de las consultas por rangos, como esperábamos, son peores que una consulta basada en una única versión. Debemos tener presente, tal y como vimos en el capítulo 8 de consultas, que la operación de rango necesita recuperar por cada región de versionado todos sus identicadores de versión asociados para a continuación realizar la comparación entre la región de versionado dada y la región que se esta procesando. Tal y como vimos en el capítulo 8 esta comparación se realiza en XQuery mediante el operador intersección de secuencia y obviamente este proceso tiene un alto coste computacional como se muestra en esta gura. Podemos comprobar que en este caso la diferencia entre un

217 Pruebas de rendimiento 199 entorno lineal y ramicado no es tan alta pues aunque el conjunto de identicadores puede ser mayor en el caso de lineal, en ambos casos, la operación de intersección condiciona este resultado. Finalmente uno de los trabajos futuros será encontrar algún mecanismo para mejorar el rendimiento de esta consulta Resultados en Saxon Hemos decidido medir el tiempo de ejecución de estas consultas usando otro procesador XQuery con el objetivo de comprobar si se obtiene el mismo comportamiento (Saxon [Kay 01]). Nos gustaría resaltar que el objetivo de este apartado no es comparar ambos procesadores XQuery sino comprobar el comportamiento de nuestra consulta en ambos procesadores. De todos modos, esta apartado también analizará las posibles causas de un mejor comportamiento de uno con respecto al otro. (a) Q1. Instantánea de Elemento en XQuery (b) Q2. Instantánea de Documento en XQuery Figura 9.5: Tiempo de Recuperación de Q1 y Q2 en Saxon En la gura 9.5 se ilustra el tiempo de recuperación obtenido (medido en ms) usando la solución TimeStamp (tstamp) y VersionStamp (vstamp) para las consultas Q1 y Q2 en Saxon. A partir de ellas podemos armar que nuestra solución, al igual que en las medidas realizadas sobre exist, tiene un comportamiento menos eciente que la solución temporal debido a los dos factores mencionados anteriormente. De la misma manera que en exist en aquellos documentos con un mayor número de ramas o mayor tamaño, nuestra solución es menos eciente pues tiene que dereferenciar un mayor número de elementos XML hacia el árbol de versionado. En este caso nos gustaría resaltar la gran diferencia existente entre el tiempo de recuperación obtenido entre exist y Saxon. Así por ejemplo la consulta Q2 en el peor de los casos en exist tarda 39 segundos mientras que la misma consulta en Saxon únicamente requiere de 1,4 segundos. Esta situación, tal y como describe el creador del procesador Saxon en [Kay 08], se puede deber a diversos factores como: utiliza un modelo más compacto (TinyTree) para la representación en memoria de los documentos XML pensada para el tratamiento de ujos XML, utiliza algoritmos de optimización de consultas sobre los ejes XPath, reescribe las consultas XQuery para su mejor comportamiento y utiliza una técnica denominada Pull/Push

218 200 Capítulo 9. Experimentación del Sistema Pipelining que mejora la entrada y salida de los datos optimizando la cache de estos documentos. Además, como también se expone en este trabajo, Saxon es más rápido que una XNDB porque no se preocupa de temas de serialización, ni persistencia de los índices ni concurrencia o usuarios, de modo, como se expone en el trabajo de lo único que se debe preocupar es de procesar y ejecutar el ujo XML de entrada lo más ecientemente posible. A parte de estas características hemos observado el esplendido funcionamiento de la memoria cache de Saxon sobre los documentos XML versionados pues en muchas ocasiones el tiempo de recuperación es casi nulo gracias a esta característica Optimización en las Consultas de Validez de Versionado A partir del apartado previo podemos concluir que las consultas de versionado anteriores sobre los vdocumentos son menos ecientes que las soluciones temporales, pues se necesita dereferenciar los atributos v:start y v:end y recuperar sus descendientes para establecer la validez de los elementos XML. En este apartado mostramos dos optimizaciones realizadas para mejorar el comportamiento de estas operaciones Optimización basada en el Camino de Antecesores En el capítulo 5, sección 5.4.2, se propuso una función BelongTo que mejoraba la complejidad del proceso de recuperación de información válida, pasando de O(n x m 2 ) a O(n x m). En este apartado vericaremos si realmente a nivel práctico se evidencia esta mejora. Esta mejora consiste en evitar uno de los principales problemas expuesto en el apartado anterior, evitar la constante recuperación de todos los descendientes de los atributos v:start y v:end puesto que mejorar el comportamiento de la consulta en base de la función id() no es posible pues nuestra técnica se fundamenta en esta característica. Figura 9.6: Tiempo de Recuperación Optimizado en consulta de Q1 en exist En la gura 9.6 se muestra el tiempo de ejecución de la consulta Q1 usando este nuevo proceso. En ella podemos comprobar que, mediante su uso, dicho tiempo se reduce cuantiosamente si lo comparamos con la consulta Q1 mostrada anteriormente. En este gura se incluye el tiempo anterior de la consulta Q1 en los casos lineal (vstamp) y ramicado 80 % (vstamp 80 %) junto con los resultados obtenidos en este nuevo proceso (Optim).

219 Pruebas de rendimiento 201 A partir de la gura podemos constatar que la reducción de complejidad expuesta en el capítulo 5 a nivel teórico también se cumple a nivel práctico. Observando los resultados comprobamos que en cualquiera de los casos, tanto lineal como ramicado, el tiempo se ha reducido notablemente. Por ejemplo si analizamos el caso en el cual Q1 tiene su peor rendimiento, lineal L100/5 - documentos grandes con muchas versiones, se ha reducido de 8,7 segundos a 0,45 segundos usando esta solución. Si comparamos los datos obtenidos con respecto a la solución temporal observamos que sus valores están muy próximos, casi iguales. Este hecho nos permite armar que la solución propuesta en este trabajo es ecaz para la gestión de versiones de documento XML, teniendo en cuenta que, en nuestro caso tenemos soporte para versionado ramicado. Figura 9.7: Tiempo de Recuperación Optimizado en consulta de Q2 en exist En la gura 9.7 se muestra el tiempo de ejecución de la consulta Q2 donde también se maniesta la reducción del tiempo de recuperación. Por ejemplo el tiempo de recuperación en el caso lineal L100/5 se ha reducido de 39 segundos a 3,9 segundos usando esta solución. Como dijimos anteriormente tanto la solución temporal como la nuestra a la hora de recuperar un documento válido en XQuery tiene un tiempo alto de recuperación debido al tipo de algoritmo usado, recursivo. En XSLT este tiempo se reducirá considerablemente. Nos gustaría destacar que esta solución depende ligeramente del tipo de ramicación pues en el caso de la solución lineal el tiempo sigue siendo algo superior a las soluciones ramicadas. Esto se debe a que la lista de antecesores de la versión dada es mayor Optimización basada en el Almacenamiento de los Descendientes En este segundo caso se ha mejorado esta consulta añadiendo información adicional al documento XML versionado para evitar la constante recuperación de los descendientes de los atributos v:start y v:end. Esta optimización consiste en almacenar en cada elemento version del árbol de versionado sus descendientes, es decir, cada elemento version tiene un nuevo atributo denominado descen que almacena sus descendientes tal y como se muestra en la gura 9.8. Esta información adicional almacenada en el árbol de versionado nos ha llevado a denominar esta mejora como índice pues se añade información al sistema para acelerar el proceso de consulta similar a los índices. A partir de estos atributos, hemos determinado que una versión pertenece a una

220 202 Capítulo 9. Experimentación del Sistema 1 <?xml version='1.0' encoding='utf-8'?> 2 <v_document> 3 <version_tree> 4 <version xml:id='v1' descen='v2,v3,v4,v5,v6,v7v,v8,v9,v10'> 5 <version xml:id='v2' descen='v3,v4,v5,v6,v7v,v8,v9,v10'> 6 <version xml:id='v3' descen='v4,v9'> 7 <version xml:id='v4' descen=> 8 <version xml:id='v9' descen=> 9 </version> 10 <version xml:id='v5' descen='v7'> 11 <version xml:id='v7' descen=> 12 </version> 13 <version xml:id='v6' descen='v8,v10'> 14 <version xml:id='v8' descen=> 15 <version xml:id='v10' descen=> 16 </version> 17 </version> 18 </version> 19 <version xml:id='now' descen=/> 20 </version_tree> 21 <versioned_doc> 22 <SigmodRecord xmlns:v=' idf='d1e1' v:start='v1' v: 23 end='now'> </SigmodRecord> 26 </versioned_doc> 27 </v_document> Figura 9.8: Documento acm.vxml Optimizado región de versionado si el atributo descen del identicador de versión de v:start contiene la versión dada y que el atributo descen de el/los identicador/es de versión v:end no contiene la versión dada tal y como se muestra en la consulta 9.1. Figura 9.9: Tiempo de Recuperación Optimizada basada en Índices (Q2) en exist En la gura 9.9 se muestra el tiempo de ejecución de la consulta optimizada donde se puede claramente comprobar que, mediante su uso, dicho tiempo se reduce considerablemente y en

221 Pruebas de rendimiento 203 Consulta 9.1 Consulta vdoc2doc optimizada 1 xquery version '1.0'; 2 declare namespace f='f.ns'; 3 declare namespace v=' 4 declare function vquery:vdocsnapshotopt($ev,$v)as element()* { 5 if (not ($ev/id(@v:end)[contains(./@descen,$v)]) and 6 contains($ev/id(@v:start)/@descen,$v)) then 7 element {name($ev)} { 8 for $x in $ev/v:attrib[contains(id(@v:start)/@descen,$v) 9 and not (id(@v:end)/self::*[contains(./@descen,$v)]) ] 10 return attribute {$x/@name} {$x/@value} 11, 12 $ev/v:data[contains(id(@v:start)/@descen,$v) and 13 not (id(@v:end)/self::*[contains(./@descen,$v)])]/text() 14, 15 for $x in $ev/child::*[name(.)!='v:data' and name(.)!='v:attrib'] 16 return vquery:vdocsnapshotopt($x,$v) 17 } 18 else () 19 }; Ejemplo de Uso <result>{ 22 f:vdocsnapshotopt(doc('acm.vxml')/*[1]/*[2],'v1,'))) 23 }</result> algunos casos es muy similar a la solución temporal. En aquellos casos donde nuestra solución tenía su peor rendimiento (documentos grandes o con muchas versiones) éste se ha reducido enormemente. Por ejemplo el tiempo de recuperación en el caso lineal L100/5 se ha reducido de 39 segundos a 4 segundos usando la solución optimizada, estando en algunas ocasiones muy próxima al tiempo de recuperación de la solución temporal Nótese que en este caso la mejora es casi independiente del número de versiones que contenga el documento y de la ramicación, pues los descendientes de los atributos v:start y v:end se encuentran almacenados como un atributo y exist los incluye en los índices y por tanto se consigue una ligera mejora con respecto a la solución optimizada basada en consulta Resultados con otros Estándares Una de las principales ventajas de la solución propuesta en esta tesis es que los documentos XML versionados pueden ser consultados usando distintos lenguajes estándar XML de consulta como XPath o XSLT tal y como se mostró en el capítulo de consultas. En esta sección se analiza el tiempo de recuperación de la instantánea de un documento usando XSLT (consulta 8.11). En la gura 9.10 se muestra el tiempo de recuperación obtenido (medido en ms) usando la solución TimeStamp (tstamp), VersionStamp (vstamp), VersionStamp Optimizado basado en índices (Optim) y XSLT para la consulta de documento válido sobre la base de datos exist. Podemos comprobar que el tiempo de recuperación en XQuery, aun usando la solución optimizada, es mucho mayor que la solución XSLT. Así por ejemplo en L100/5 lineal el tiempo de recuperación en XQuery es 39 segundos en el caso de no usar el algoritmo optimizado, 4 segundos usando el proceso optimizado y tan sólo de 1,6 segundos en el caso de utilizar XSLT. Esto se debe, como hemos expuesto anteriormente, a que el tipo de algoritmo usado en XQuery es recursivo generando una pila bastante considerable de llamada. Es por este motivo

222 204 Capítulo 9. Experimentación del Sistema Figura 9.10: Tiempo de Recuperación en XSLT que hemos decidido utilizar la solución XSLT en el sistema de versionado propuesto en los apartados anteriores cuando esta operación es requerida Conclusiones a los Resultados Experimentales En esta sección hemos mostrado los distintos experimentos llevados a cabo para vericar el rendimiento del modelo de versionado. Los resultados obtenidos se encuentran muy próximos a los obtenidos para representaciones XML temporales, por lo que nuestro modelo permite extender de forma eciente el versionado lineal a un versionado ramicado de documentos XML. Así, se ha mostrado el buen resultado obtenido por nuestro modelo usando el algoritmo optimizado para la recuperación de información válida donde el tiempo de recuperación resultante se encuentra muy cercano a la solución temporal. Además debemos tener presente que nuestro modelo ofrece ciertas ventajas de las que carece la solución temporal: 1) es capaz de representar y manejar versionado ramicado y 2) tal y como se verá posteriormente también permite las consultas basadas en el eje temporal (Anexo A). En cuanto a las consultas por rangos hemos comprobado que su tiempo de recuperación es más elevado debido a que necesita comparar conjuntos de identicadores de versión. Como trabajo futuro se propone encontrar algún mecanismo para mejorar este tipo de consultas. Finalmente, en esta tesis hemos decidido no analizar el rendimiento de las operaciones de actualización de un documento vxml pues no van a ser costosas en tiempo. Debemos tener presente que la creación de una nueva versión se produce a partir de un conjunto de operaciones denidas en un documento XML, de modo que el tiempo de actualización será el tiempo de búsqueda del nodo afectado (basado en un camino de localización XPath) más el tiempo de ejecución de la operación XUpdate asociada, igual que cualquier operación XUpdate sobre un documento XML Interfaces de Versionado Llegados a este punto, y una vez que hemos expuesto la arquitectura del sistema de versionado así como se ha abordado su implementación, mostraremos las distintas interfaces de

223 Interfaces de Versionado 205 versionado que hemos desarrollado para facilitar la gestión de versiones de documentos XML. Los objetivos que hemos establecido son: simplicidad y uso intuitivo de cara al usuario nal. Figura 9.11: Capas del Sistema de Versionado e Interfaces En el gráco 9.11 se muestra el mapa global de capas desarrolladas sobre exist, incluyendo el versionado y las capas suyas propias. Como podemos ver en la imagen, la parte izquierda corresponde a la situación original de la base de datos exist. En la parte derecha podemos ver como sobre XQuery nativo aparece una nueva capa que proporciona el versionado de documentos (módulos XQuery) y nalmente sobre la capa de versionado podemos distinguir las distintas interfaces creadas: SOAvXML [de Sande Villaroel 08]: En el proyecto SOAvXML se crearon dos aplicaciones clientes: una implementada con XQuery que extendía la interfaz web de exist que se encuentra comunicada directamente con los módulos de versionado, y otra creada en JSP que consumía servicios web (creado en este mismo proyecto) que se comunicaban con los módulos de versionado. vedi [López 08]: En el proyecto vedi se desarrolló un conjunto de servicios utilizando el protocolo XML-RPC, de tipo asíncrono, que permiten que nuestra aplicación, desarrollada en AJAX, se comunique con los módulos de versionado. Este proyecto ha tenido su continuación en [Moreno 09] donde se han añadido nuevas características al editor. A continuación profundizaremos en cada una de estas interfaces Servicio Web Esta interfaz se desarrolla dentro del proyecto SOAvXML [de Sande Villaroel 08] y el objetivo es proporcionar una herramienta altamente portable para la gestión de versiones de documentos XML. Para conseguir este objetivo se propuso una arquitectura SOA que permite, por una parte, acceder a toda la funcionalidad proporcionada por exist, administrar y utilizar una base de datos exist a través de servicios Web y, por otra parte, acceder a los módulos de versionado implementados. Este conjunto de servicios web constituyen lo que denominamos la API de versionado basada en servicios web. Esta API está desarrollada en Java, haciendo uso de las librerías AXIS que ofrece la Apache Software Foundation[Bambusi 00], las cuales se han desplegado en el servidor de aplicaciones

224 206 Capítulo 9. Experimentación del Sistema Tomcat 5.5. En la tabla 9.1 se muestra el conjunto de servicios, agrupados por clases, junto con una breve descripción de su cometido. Por ejemplo dentro de la clase conversión se agrupan aquellas funcionalidades que permiten convertir un documento XML a vxml y viceversa. Tabla 9.1: Servicios Web de Versionado Clase Servicio Web Descripción Conversion doc2vdoc Genera un documento vxml a partir de un documento XML Conversion vdoc2doc Recupera un determinado estado de un documento vxml Get getdocs/vdocs Recupera una lista con los documentos XML/vXML para un determinado usuario. Get getversions Recupera las versiones disponibles para un documento vxml Get getinfo Proporciona información de los servicios web Query getquery Ejecuta una determina consulta Changes Primitive Ejecuta una primitiva de cambio Changes exectrans Ejecuta un documento XML transaccional Changes exec_randontrans Ejecuta un documento XML transaccional con primitivas aleatorias Manage uploadxml/ VXML Sube un documento XML/vXML al repositorio Manage deletexml/ VXML Elimina un documento XML/vXML del repositorio Di GetDi Obtiene las diferencias entre dos versiones Esta interfaz fue la primera de todas las expuestas en este apartado en desarrollarse y, en un primer instante, se utilizó la implementación disponible de módulos de versionado, basada en módulos XSLT. Como principales ventajas de esta interfaz podemos destacar su portabilidad pues nuestra propuesta, al estar desarrollada sobre Servicios Web, favorece la reutilización por parte de clientes potenciales, posibilitando, incluso, el desarrollo de nuevos clientes más complejos. De este modo estos servicios web pueden utilizarse en dos entornos de trabajo: por una parte, por programadores, mediante la utilización de la API descrita en la tabla 9.1, para desarrollar un sistema de versionado más complejo y, por otra parte, por usuarios nales para realizar la gestión de sus documentos. En este último caso hemos desarrollado un cliente JSP para facilitar la interacción entre los usuarios nales y los servicios web, de modo que de una forma más amigable e intuitiva se puedan realizar las tareas más habituales en un sistema de versionado, ocultando al usuario nal toda la implementación subyacente. Sin embargo, esta implementación presenta los siguientes inconvenientes: por una parte, al utilizar como sistema de repositorio el sistema de cheros del sistema operativo, algunos mecanismos habituales como la gestión de la seguridad de los usuarios, el bloqueo de cheros, las indexaciones en los documentos, etc., se tienen que realizar en los propios servicios web (una mayor complejidad) y por otra parte, como hemos expuesto en el apartado de módulos de versionado XSLT, esta implementación tiene un alto coste computacional en las actualizaciones de los documentos vxml. Fue este motivo el que nos condujo a utilizar como repositorio una base de datos nativa XML, optando además por la implementación de los módulos en

225 Interfaces de Versionado 207 XQuery. Estos mismos servicios web se re-implementaron para utilizar esta nueva tecnología y, aprovechando los conocimientos sobre XQuery adquiridos previamente, dieron lugar a nuevas interfaces Interfaz Web-XQuery para la Gestión de Versiones (Extensión a exist) exist proporciona distintos clientes grácos para acceder a la base de datos, tanto a nivel de consulta, mediante una interfaz web denominada sandbox, como a nivel de administración: aplicación cliente java, aplicación web, así como un conjunto de protocolos y API como REST, WebDav, RPC y SOAP para estos nes. En este apartado describimos el cliente gráco que permite interoperar fácilmente con el sistema de versionado con la particularidad de que, por una parte, oculta toda la perspectiva de versionalidad en el sistema y, por otra, preserva en mayor medida la interfaz actual. Para ello hemos extendido la interfaz web de exist, que está implementada por completo en XQuery, adaptándolo a la gestión de versiones por la sencillez, amigabilidad y facilidad que presenta este cliente [de Sande Villaroel 08]. Disponible en la siguiente dirección URL: is/v_exist. En la gura 9.12 se muestra una captura de la interfaz Web de exist junto con la nueva extensión, donde se puede comprobar la aparición de un nuevo menú en el lado izquierdo denominado Browse vcollections especíco de nuestra extensión. Una vez que se accede al sistema, con la consecuente autenticación, dependiendo del tipo de documento XML del repositorio con el que se vaya a trabajar, especicado con una etiqueta junto al nombre del documento (Doc o vdoc), se pueden realizar diferentes acciones sobre los documentos (columna action de la interfaz). Con el objetivo de no recargar la interfaz en exceso se ha decidido utilizar distintos iconos para presentar las posibles acciones a realizar. De este modo, en el caso de que se seleccione un documento XML las principales acciones son: edición (icono amarillo), o su conversión a un vdocumento (color azul), usándose para esta última acción la operación doc2vdoc del módulo Version. Nótese que el proceso de conversión también se puede realizar durante la fase de subida de un documento al sistema, marcando solamente la casilla vupload de la interfaz. En el caso de que se elija un documento XML versionado, se pueden realizar varias acciones, como se muestra en la gura anterior. En primer lugar hay que elegir la versión sobre la que trabajar en el desplegable de versiones disponibles y, posteriormente, seleccionar un icono. El color verde indica la acción de recuperar una determinada versión del documento, es decir, dada una versión de un vdocumento se recupera la instantánea de dicha versión. Mediante el color amarillo se entra en el proceso de edición de una determinada versión permitiéndonos, una vez realizados los cambios en la versión, o bien actualizar a una nueva versión del documento o bien salvar los cambios realizados para una posterior actualización (se genera un chero XML transaccional). Finalmente, mediante el último icono, rojo, se puede realizar el proceso de actualización de un vdocumento a partir de un documento XML transaccional salvado con anterioridad o procedente de un chero local del disco duro Interfaz AJAX para la Gestión de Versiones Esta interfaz se desarrolla dentro del proyecto vedi [López 08] y surge para crear una capa intermedia, entre el usuario nal del sistema de versionado y la técnica de versionado versionstamp, de manejo más intuitivo y amigable que el entorno del apartado anterior.

226 208 Capítulo 9. Experimentación del Sistema Figura 9.12: Administrador Web para la Gestión de versiones Para ello hemos decidido simular el editor en línea GoogleDoc pues nos parece un editor altamente intuitivo y fácil de utilizar, adaptándolo a nuestras necesidades de versionado ( Esta interfaz se ha llevado a cabo mediante las siguientes tecnologías: Ajax como framework de desarrollo y XML-RPC como capa de comunicación entre la aplicación y la base de datos exist. Ajax, acrónimo en inglés de Asynchronous JavaScript And XML, es una técnica de desarrollo Web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De este modo se pueden realizar cambios sobre las páginas sin necesidad de recargarlas, lo que permite aumentar la velocidad, interactividad y el grado en el que el diseño facilita el manejo de la aplicación. Entre los diversos framework de desarrollo en AJAX seleccionamos Google Web Toolkit pues es uno de los más aanzados y permite desarrollar el código dividiéndolo en dos partes: código de la parte cliente y código de la parte servidor. Por otro lado, XML-RPC es un protocolo de llamada a procedimiento remoto que utiliza XML para codicar los datos y HTTP como protocolo de transmisión de mensajes. Fue creado por Dave Winer de la empresa UserLand Software en asociación con Microsoft en el año Es un protocolo que fue diseñado para ser lo más sencillo posible, pero permite transmitir, procesar y devolver complejas estructuras de datos. La elección de XML-RPC se debió a que encontramos una librería que permitía la conexión con la base de datos y lo hacía a través del protocolo XML-RPC desde AJAX. La arquitectura desarrollada mediante esta interfaz es la siguiente (mostrada en la gura 9.13.a): Una capa de aplicación con la que interactúan los usuarios nales, desarrollada en AJAX (mostrada en la gura 9.13.b). Se trata de una interfaz con pestañas, ventanas y tablas, cuyo n es facilitar al usuario la gestión de cheros y colecciones, así como la edición tanto de documentos XML como de versiones de documentos vxml.

227 Interfaces de Versionado 209 Una capa de interacción con la base de datos desarrollada utilizando el protocolo XML- RPC como protocolo de comunicación con exist. Se trataría de una especie de Servlet que recibe peticiones de la aplicación cliente y realiza la llamada oportuna a los módulos XQuery de versionado. La capa de almacenamiento que actúa de repositorio (exist). Figura 9.13: a) Esquema de Funcionamiento b) Aplicación Ajax para la Gestión de versiones En la gura 9.13.b se muestra una captura de la interfaz Ajax desarrollada. Como podemos observar en la gura la ventana de edición de documentos vxml cuenta con los siguientes componentes: información del árbol de versiones (obtenido de la información almacenada en el elemento version_tree del documento vxml), una tabla de propiedades para la versión que esté seleccionada (atributos de cada versión), el editor de texto de la versión requerida y la barra de tareas con las distintas funcionalidades que se pueden realizar: salvar la versión modicada, almacenarla como chero independiente y auto-guardar. Este proyecto ha tenido su continuación en [Moreno 09] donde se le ha añadido al editor nuevas características como: obtener las diferencias entre dos versiones en formato visual y XML, consultas XQuery desde el veditor o la internacionalización del editor. La principal dicultad encontrada en el desarrollo de esta interfaz es la comunicación entre la capa de aplicación (asíncrona) y la capa de interacción con la base de datos y exist (síncrona). Esta situación ocurre, por ejemplo, cuando se invoca a un servicio que obtiene el contenido de un chero XML y tras ello se quiere llamar a un método que lo añada a un componente gráco. En este entorno no se puede mostrar directamente la información, pues probablemente el método para presentar el chero se ejecute antes de que el servicio asíncrono complete su función.