Procesamiento de Documentos XML Dirigido por...

Title— Language-Oriented Processing of XML Documents in

e-Learning Environments

Abstract— This paper proposes the use of attribute grammars

in order to systematize the processing of XML documents in

e-Learning environments. For this purpose, it presents XLOP

(XML Language-Oriented Processing), an XML processing

environment based on this technique. It also illustrates how

XLOP is used in two different e-Learning contexts: language-

driven production of educational applications, and processing of

metadata documents for reusable learning objects.

Index Terms— XML processing, Socratic Tutorial, Learning

Objects, Metadata, Attribute Grammar

I. INTRODUCTION

ML es el formato de representación e intercambio básico utilizado en la práctica totalidad de los escenarios de

e-Learning. Como ejemplo representativo de la importancia que cobra XML en el dominio de e-Learning puede examinarse cualquiera de los actuales esfuerzos estandarizadores, donde, aparte de proponerse modelos de información para representar aspectos relevantes de los sistemas e-Learning (e.g., evaluaciones, diseños educativos, o perfiles de estudiante), también se proponen vinculaciones de dichos modelos con vocabularios XML específicos [5]. Por lo tanto, la implantación práctica de cualquier solución e-Learning implicará, desde el punto de vista tecnológico, una fuerte componente de procesamiento de documentación XML. De esta forma, el disponer de mecanismos que faciliten el desarrollo de dicha componente de procesamiento se convierte en un factor clave de dicha implantación.

XLOP (XML Language-Oriented Processing) es un entorno que utiliza gramáticas de atributos para describir cómo procesar documentos XML marcados con un determinado vocabulario. Las gramáticas de atributos son un formalismo declarativo ampliamente utilizado en la descripción de la sintaxis, las restricciones contextuales (semántica estática), y

A.Sarasa es miembro del Departamento de Sistemas Informáticos

y Computación de la Universidad Complutense de Madrid. Email: [email protected]. J.L.Sierra y A.Fernández-Valmayor son miembros del Departamento de Ingeniería del Software e Inteligencia Artificial de la Universidad Complutense de Madrid. Email: {jlsierra,Alfredo}@fdi.ucm.es

DOI (Digital Object Identifier) Pendiente

la traducción de los lenguajes informáticos [8][9]. De esta forma, XLOP sigue un paradigma dirigido por lenguajes en el desarrollo de los programas de procesamiento de documentos XML [3]. De acuerdo con este paradigma, dichos programas se entienden como procesadores de lenguaje, y el proceso de desarrollo en sí se entiende como el proceso de construcción y mantenimiento de dichos procesadores. De hecho, utilizando XLOP es posible generar automáticamente tales procesadores a partir de especificaciones de alto nivel expresadas como gramáticas de atributos.

XLOP se ha diseñado para ser integrado con Java. Efectivamente, las funciones semánticas que se utilizan en las gramáticas de atributos XLOP se implementan como métodos en Java. De esta forma, XLOP ofrece una flexibilidad comparable a la de los marcos de procesamiento genéricos para XML (e.g., SAX, DOM, StAX, etc.) [3], y, al mismo tiempo, un nivel de usabilidad comparable al de enfoques específicos (e.g., los ofrecidos por lenguajes de transformación como XSLT) [3]. De hecho, XLOP permite estructurar las aplicaciones de proceso de XML en dos capas perfectamente diferenciadas: - Una capa de lógica específica de la aplicación, que

incluye la maquinaria necesaria para soportar la funcionalidad de dicha aplicación (e.g., un marco de aplicación para la representación interna de un tutor inteligente, o un conjunto de clases para el procesamiento de metadatos).

- Una capa lingüística de procesamiento XML dirigido por

la sintaxis. Esta capa se especifica como una gramática de atributos, especificación que se traduce automáticamente a una implementación ejecutable mediante un generador XLOP.

La conexión entre ambas capas se realiza mediante una clase semántica, que implementa en Java las funciones semánticas utilizadas en la gramática de atributos XLOP, y que media entre las dos capas anteriores. De esta forma, el modelo de desarrollo dirigido por lenguajes de XLOP propugna la separación explícita de estas dos capas, así como facilita el desarrollo y el mantenimiento de la capa lingüística, ya que ésta se especifica a un nivel mucho más alto que el conseguido con una implementación directa en Java o en cualquier otro lenguaje de programación. De hecho, el formalismo de las gramáticas de atributos es también de más

Procesamiento de Documentos XML Dirigido por Lenguajes en Entornos de E-Learning

Antonio Sarasa-Cabezuelo, José-Luis Sierra-Rodríguez, y Alfredo Fernández-Valmayor

X

IEEE-RITA Vol. 4, Núm. 3, Ago. 2009 175

ISSN 1932-8540 © IEEE

alto nivel que una descripción basada en esquemas de

traducción [1], del tipo de los soportados por otros enfoques al procesamiento de XML dirigido por lenguajes (e.g., ANTXR [19], un entorno construido sobre la herramienta ANTLR, y RelaxNGCC [7], una extensión del lenguaje de esquema

documental RelaxNG utilizada para especificar esquemas de traducción y que permite la generación automática de traductores recursivos descendentes [1]).

En este artículo se describe el entorno XLOP, haciendo énfasis en su lenguaje de especificación, así como en su aplicación al procesamiento de XML en entornos de e-Learning. Para ello, en la sección II se comienza describiendo el entorno en sí. En la sección III se ejemplifica el uso del entorno en el desarrollo de un traductor para <e-Tutor>, un sistema para la producción de tutoriales

socráticos. En la sección IV se ejemplifica su uso en la comprobación de restricciones sobre documentos de metadatos en Chasqui, un sistema para la creación de repositorios de objetos de aprendizaje en dominios especializados. Por último, en la sección V se resumen las conclusiones obtenidas, así como se esbozan algunas líneas de trabajo futuro. Este trabajo es una versión extendida de [11].

II. EL ENTORNO XLOP

A. Gramáticas de Atributos

XLOP se basa en el formalismo de las gramáticas de atributos. Este formalismo fue propuesto por Donald E. Knuth a finales de los sesenta como un mecanismo para añadir semántica a los lenguajes incontextuales [8][9]. Una gramática de atributos consta de: - Una gramática incontextual que caracteriza la sintaxis

estructural del lenguaje mediante un conjunto de reglas

sintácticas o producciones.

- Un conjunto de atributos semánticos añadidos a los símbolos de la citada gramática. Estos atributos pueden ser de dos tipos: atributos sintetizados y atributos heredados. Los atributos toman valores en los nodos de los árboles sintácticos impuestos por la gramática incontextual sobre las sentencias. Los valores de los atributos sintetizados representan la semántica de los fragmentos de sentencia que penden de los nodos, mientras que los de los atributos heredados representan información de contexto. Los atributos sintetizados en un nodo se computan a partir de los sintetizados de sus hijos y de los propios atributos heredados del nodo. Por su

parte, los atributos heredados se computan a partir de los sintetizados de los hermanos y de los heredados del padre.

- Un conjunto de ecuaciones semánticas para cada producción. Estas ecuaciones indican cómo computar los valores de los atributos sintetizados de la cabeza y de los atributos heredados de los símbolos del cuerpo. Para ello aplican funciones semánticas sobre los atributos utilizados en dicho cómputo.

El axioma de la gramática también puede tener atributos heredados. Así mismo, los terminales también pueden tener atributos sintetizados, que se denominan atributos léxicos. Los valores de estos atributos se fijarán externamente (e.g., los atributos léxicos se fijarán durante el análisis léxico).

Durante la preparación de una gramática de atributos no es necesario especificar explícitamente en qué orden tienen que aplicarse las ecuaciones semánticas para encontrar los valores de los atributos en los árboles sintácticos (es decir, para evaluar dichos atributos). De esta forma, las gramáticas de atributos son mecanismos descriptivos de más alto nivel que los esquemas de traducción soportados por las herramientas típicas de construcción de procesadores de lenguaje (e.g., JavaCC, ANTLR, YACC, o CUP), en los que sí es necesario explicitar el orden de ejecución de las acciones semánticas. Por el contrario, en una gramática de atributos el orden de evaluación se deriva de las dependencias entre los atributos introducidas por las ecuaciones semánticas. El método de evaluación en sí puede ser estático o dinámico. Los métodos estáticos analizan la gramática durante la generación del evaluador para encontrar un orden de evaluación que funciona para cualquier sentencia. Por su parte, los métodos dinámicos deciden el orden de evaluación para cada sentencia particular. En XLOP se adopta un método de evaluación dinámica, ya que los métodos dinámicos aceptan una clase más amplia de gramáticas de atributos que los estáticos, aún a consta de una ligera pérdida de eficiencia.

B. El Lenguaje de Especificación de XLOP

El lenguaje de especificación de XLOP es un metalenguaje

para describir gramáticas de atributos para lenguajes de marcado definidos mediante XML. La Figura 1 muestra la sintaxis de este lenguaje.

La gramática incontextual subyacente a una especificación XLOP representa la estructura lógica de un tipo de documentos XML (los detalles de más bajo nivel relativos a la estructura física del documento se ignoran, ya que estos serán tratados por entornos de análisis de XML convencionales [3]).

SpecXLOP::= {Regla}+ Regla ::= +oTerminal ‘::=’ { ElementoSintactico }* '{' { Ecuacion }* '}' ElementoSintactico ::= +oTerminal | #pcdata | ElementoXML ElementoXML ::= EtiquetaApertura { ElementoSintactico }* EtiquetaCierre | EtiquetaElmVacio

Ecuacion ::= ReferenciaAtributo '=' ExpresionSemantica ExpresionSemantica ::= Funcion '(' (ExpresionSemantica { , ExpresionSemantica }*)? ')' | ReferenciaAtributo

ReferenciaAtributo ::= Atributo of ( +oTerminal | #pcdata | EtiquetaApertura) ( '(' +umeroOcurrencia ')' )?

Figura 1. Sintaxis del lenguaje de especificación de XLOP.

176 IEEE-RITA Vol. 4, Núm. 3, Ago. 2009

ISSN 1932-8540 © IEEE

Como puede observarse en la Figura 1, las gramáticas XLOP pueden incluir los siguientes tipos de símbolos terminales: - El símbolo #pcdata . Este símbolo denota un fragmento

de contenido textual en el documento procesado.

- Etiquetas de apertura (e.g., <Tutorial> ) y de cierre (e.g., </Tutorial> ). Estas etiquetas dependerán del lenguaje particular que se está procesando, y deberán, así mismo, ser convenientemente anidadas.

Así mismo, las gramáticas XLOP pueden contener los símbolos no terminales que se consideren necesarios para representar de manera apropiada el resto de la estructura lógica del lenguaje de marcado a procesar.

En lo que se refiere a los atributos léxicos, el símbolo #pcdata soporta únicamente un atributo léxico: text . El valor de este atributo será el contenido textual particular representado por el símbolo. Las etiquetas de apertura pueden tener también atributos léxicos, que se denominarán atributos

de elemento, y que se corresponderán con los atributos que se especifican explícitamente en los elementos del documento. Por último, los símbolos no terminales pueden tener atributos sintetizados y heredados arbitrarios. En XLOP no es preciso distinguir explícitamente qué atributos son los sintetizados y cuáles los heredados, sino que este hecho se infiere del uso de los mismos en las ecuaciones. Por último, obsérvese que en la referencia a los atributos, que se lleva a cabo utilizando una notación del tipo atributo of refSímbolo, es posible utilizar un número de orden a fin de desambiguar el símbolo concreto al que pertenece el atributo, cuando éste aparezca más de una vez en la producción.

Finalmente, es importante notar que el lenguaje XLOP no proporciona mecanismos para definir las funciones semánticas utilizadas en las ecuaciones. Dichas funciones deberán ser definidas externamente, como métodos de la clase semántica.

C. El Generador en XLOP

XLOP incluye un generador que, tomando como entrada una gramática descrita en el lenguaje de especificación de XLOP, produce una implementación del procesador asociado escrita en CUP [2]. CUP es un sistema de generación de

traductores para Java que soporta gramáticas LALR(1), la clase de gramáticas más expresiva para la que es posible generar analizadores sintácticos compactos y eficientes. En la implementación CUP generada, la evaluación de atributos se

embebe en el proceso de análisis sintáctico mediante un mecanismo de ejecución retardada, según el cuál la evaluación de las ecuaciones semánticas se hace depender de la disponibilidad de valores para los atributos que intervienen en las expresiones semánticas correspondientes (véase [12] para más detalles del mecanismo).

La ejecución de los procesadores generados requiere, además, la clase semántica que implementa las funciones semánticas, los componentes que conforman la lógica específica de la aplicación, y también una serie de clases de conveniencia que configuran el entorno de ejecución XLOP. Entre éstas últimas destaca la implementación de un analizador léxico genérico que transforma el recorrido de la estructura lógica de los documentos (en orden documental) en la secuencia de componentes léxicos esperada por el procesador generado. Este componente conecta con un marco estándar de análisis de documentos XML basado en SAX (un API para el procesamiento al vuelo de documentos XML) [3]. El componente en sí y la estrategia de interconexión con el parser SAX son análogos a los descritos en [10]. La Figura 2 resume la cadena de generación implementada en XLOP.

III. PRODUCCIÓN DIRIGIDA POR LENGUAJES DE APLICACIONES

EDUCATIVAS: <E-TUTOR>

A. Generación de tutoriales con <e-Tutor>

En esta sección se ejemplifica el uso de XLOP en el desarrollo de una versión simplificada de <e-Tutor> [13][14][16][17], un sistema para el desarrollo de tutores socráticos basado en los trabajos seminales de Alfred Bork y su equipo durante los ochenta [4]. Este tipo de sistemas fue muy popular durante las dos últimas décadas del siglo pasado, y, a pesar de las críticas recibidas acerca de su idoneidad pedagógica y de la dificultad de su producción y mantenimiento, aún hoy existe una comunidad muy activa trabajando en estos temas, así como iniciativas tan interesantes como las descritas en [20]. Así mismo, el funcionamiento de este tipo de sistemas está en la base de los mecanismos de adaptación de las últimas versiones de especificaciones e-Learning tan relevantes como QTI [6]. En cualquier caso, el papel jugado por <e-Tutor> no es tanto pedagógico como tecnológico, a fin de permitir experimentar con distintos métodos, técnicas y herramientas de producción y mantenimiento de aplicaciones e-Learning (e.g., desarrollo

Generador

XLOP

Especificación XLOP

Implementación en CUP

Generador CUP

Implementación en Java

javac

Implementación en JVM

Clase semántica y entorno de ejecución XLOP

java

Procesador

Documento XML a Procesar

Figura 2. Cadena de generación en XLOP

Brasilia

Río de Janeiro

¿Cuál es la capital de Brasil?

Otra

¡Eso es! Vamos con otra pregunta ¡No! Esa es dónde

los carnavales ;)

Piensa en el nombre del país …

¡No! La respuesta correcta es Brasilia

Prueba con otra…

¡No! Piensa en el nombre del país…

(1) (2)

(1)

(1) (2)

Figura 3. Fragmento de un tutorial socrático

SARASA-CABEZUELO et al.: PROCESAMIENTO DE DOCS. XML DIRIGIDO POR LENGUAJES 177

ISSN 1932-8540 © IEEE

documental, siguiendo un enfoque precursor de XLOP [17], desarrollo de aplicaciones web educativas dirigido por lenguajes [13][14], o prototipado rápido de lenguajes de modelado educativo [16]).

<e-Tutor> interpreta descripciones de tutoriales en los cuáles el estudiante se somete a problemas, para los cuáles construye soluciones a través de un diálogo socrático (maestro – discípulo). El sistema analiza las respuestas del

estudiante a las preguntas planteadas, proporciona al mismo una realimentación apropiada, y decide el próximo paso a llevar a cabo en el proceso de aprendizaje. La realimentación dada se puede adaptar a distintos itinerarios de aprendizaje. En el caso más general el proceso de adaptación podría depender de la historia completa de la interacción del estudiante con el sistema, aunque en <e-Tutor> se adopta un mecanismo simple basado en contadores, al estilo de los trabajos de Bork. El sistema asocia contadores a cada posible respuesta de cada pregunta. Cada vez que el estudiante da una respuesta, incrementa el contador asociado. De esta forma, la realimentación y el siguiente paso a dar pueden depender del valor de dichos contadores. La Figura 3 muestra esquemáticamente un ejemplo de este tipo de tutorial. Las cajas con esquinas redondeadas representan puntos de

respuesta, donde el alumno debe proporcionar una respuesta a la pregunta realizada. Dichos puntos de respuesta están conectados con potenciales respuestas, que se encierran en una caja compartimentada. Las cajas sombreadas representan las realimentaciones. El flujo de aprendizaje se representa mediante flechas. Las etiquetas numéricas en las flechas que unen compartimentos de respuestas con realimentaciones indican los valores que deben tomar los contadores para que las flechas sean aplicables.

<e-Tutor> incluye un lenguaje de marcado basado en XML para describir tutoriales como documentos XML, que, debidamente procesados, permiten ejecutar dichos tutoriales. La DTD de la Figura 4 muestra una versión simplificada de

dicho lenguaje XML (la simplificación omite detalles estructurales y presentacionales irrelevantes; véase [17] para una versión más detallada). La Figura 5 muestra una representación XML del fragmento de tutorial de la Figura 3. A continuación se describe brevemente la refactorización de <e-Tutor> utilizando XLOP.

B. La Capa de Lógica Específica de la Aplicación

La Figura 6 muestra las principales componentes (clases e interfaces) que configuran esta capa, así como sus interrelaciones. Estos componentes constituyen un marco de aplicación para la representación de tutoriales. Dado que en este artículo se está presentando una versión simplificada de

<!ELEMENT Tutorial (Start,(Speech|Question|Answer|Feedback)+, End)> <!ELEMENT Start EMPTY> <!ATTLIST Start next IDREF #REQUIRED> <!ELEMENT Speech ( #PCDATA)> <!ATTLIST Speech id ID #IMPLIED next IDREF #REQUIRED> <!ELEMENT Question ( #PCDATA)> <!ATTLIST Question id ID #REQUIRED> <!ELEMENT Answer ( #PCDATA)> <!ATTLIST Answer id ID #REQUIRED forQuestion IDREF #REQUIRED default (yes|no) "yes"> <!ELEMENT Feedback EMPTY> <!ATTLIST Feedback counter NMTOKEN #REQUIRED forAnswer IDREF #REQUIRED speech IDREF #REQUIRED> <!ELEMENT End EMPTY> <!ATTLIST End id ID #REQUIRED>

Figura 4. DTD para el lenguaje de <e-Tutor>.

<Tutorial> <Start next="..."/>

... <Question id="q1"> ¿Cuál es la capital de Brasil </Question> <Answer id="a11" forQuestion="q1"> Brasilia </Answer> <Answer id="a12" forQuestion="q1"> Río de Janeiro </Answer> <Answer id="a13" forQuestion="q1" default="yes"/> <Feedback counter="1" forAnswer="a11" speech="s1"/> <Feedback counter="1" forAnswer="a12" speech="s2"/> <Feedback counter="2" forAnswer="a12" speech="s4"/> <Feedback counter="1" forAnswer="a13" speech="s5"/> <Feedback counter="2" forAnswer="a13" speech="s4"/> <Speech id="s1" next="..."> ¡Eso es! Vamos con otra pregunta </Speech> <Speech id="s2" next="s3"> ¡No! Esa es dónde los carnavales ;) </Speech> <Speech id="s3" next="q1"> Piensa en el nombre del país... </Speech> <Speech id="s4" next="s5"> ¡No! La respuesta correcta es Brasilia </Speech> <Speech id="s5" next="..."> Prueba con otra... </Speech> <Speech id="s6" next="q1"> ¡No! Piensa en el nombre del país... </Speech>

... <End id="..."/> </Tutorial>

Figura 5. Codificación XML del fragmento de tutorial de la Figura 3

TElement

<<interface>>

Speech Question

feedback

Answer

for*

speech

End

for

*

Tutorial

*start

next

0..1

Figura 6. Esbozo de la capa de lógica específica de la aplicación en <e-Tutor>


ISSN 1932-8540 © IEEE

<e-Tutor>, este marco es una versión simplificada del más detallado descrito en [17].

C. La Capa Lingüística

La capa lingüística queda definida por la especificación XLOP que se muestra en la Figura 7. Dicha capa lingüística traduce descripciones XML de tutoriales en instanciaciones del marco de aplicación de la Figura 6.

La gramática incontextual subyacente representa el mismo lenguaje de marcas expresado por la DTD de la Figura 4. La diferencia es que esta gramática incontextual impone una estructura bien definida sobre los contenidos de los elementos (más concretamente, especifica la secuencia de elementos del tutorial mediante un no terminal TElements , y utiliza recursión a izquierdas en las producciones que definen dicho no terminal, ya que este tipo de recursión es tratada de forma muy eficiente por los analizadores LR subyacentes a la implementación de XLOP). Mientras que dicha estructura no es relevante a nivel de la validación genérica de un documento XML con respecto a su DTD o su esquema, la estructura en sí es fundamental para añadir significado al lenguaje.

Por su parte, la traducción se concibe en dos etapas: una etapa de creación de los componentes del tutorial, y otra etapa de enlace de dichos componentes. De esta forma: - La etapa de creación se lleva a cabo asociando un atributo

sintetizado unlinkedTutorial con TElements (la secuencia de elementos del tutorial). Este atributo se utiliza para construir un tutorial en el que los elementos aún no están conectados. Cada elemento en sí se sintetiza mediante un atributo element en TElement (categoría sintáctica que representa cada elemento individual).

- La etapa de conexión supone propagar el tutorial no conectado a lo largo de la secuencia de elementos. Esto se consigue asociando un atributo heredado finalUnlinkedTutorialh con TElements . Así mismo, esta etapa supone también sintetizar el tutorial final, conectando cada elemento al resto. Esto se consigue asociando un atributo sintetizado tutorial con

TElements , así como con Tutorial (éste representará el tutorial finalmente construido).

D. La Clase Semántica

Por último, es necesario proporcionar la clase Java que implementa las funciones semánticas utilizadas en la especificación XLOP. En el caso de <e-Tutor>, dichas funciones instanciarán clases del marco de aplicación, e invocarán a métodos sobre los objetos resultantes para conectar los mismos. La Figura 8 esboza un fragmento de dicha clase, en el que se detalla la implementación de la función semántica link . Nótese que, aunque desde un punto de vista estrictamente formal las funciones semánticas deberían estar libres de efectos laterales, en esta especificación particular los valores de los atributos de entrada a las funciones destructivas, como link , no volverán a utilizarse, lo que permite modificar destructivamente los valores (objetos Java) a los que se refieren.

IV. PROCESAMIENTO DIRIGIDO POR LENGUAJES DE

DOCUMENTOS DE METADATOS: CHASQUI

A. Restricciones sobre metadatos en Chasqui

En esta sección se ilustra el uso de XLOP para soportar un procesamiento no trivial de documentos de metadatos de objetos de aprendizaje en Chasqui. Chasqui es una plataforma

Tutorial ::= <Tutorial> <Start/> TElements <End/> </Tutorial> { finalUnlinkedTutorialh of TElements = addStartAnd End(next of <Start>, id of <End>, unlinkedTutorial of TElements) tutorial of Tutorial = tutorial of TElements } TElements ::= TElements TElement { unlinkedTutorial of TElements(0) = addElement(ele ment of TElement, unlinkedTutorial of TElements(1)) finalUnlinkedTutorialh of TElements(1) = finalUnl inkedTutorialh of TElements(0) tutorial of TElements(0) = link(element of TEleme nt,tutorial of TElements(1)) } TElements ::= TElement { unlinkedTutorial of TElements = addElement(elemen t of TElement,newTutorial()) tutorial of TElements(0) = link(element of TEleme nt,finalUnlinkedTutorialh of TElements) } TElement ::= <Speech> #pcdata </Speech> { element of TElement = newSpeech(id of <Speech>,ne xt of <Speech>,text of #pcdata) } TElement ::= <Question> #pcdata </Question> { element of TElement = newQuestion(id of <Question >,next of <Question>,text of #pcdata) } TElement ::= <Answer> #pcdata </Answer> { element of TElement = newAnswer(id of <Answer>,f orQuestion of <Answer>,default of <Answer>, text of #pcdata) } TElement ::= <Feedback/> { element of TElement = newFeedback(counter of <Fe edback>,forAnswer of <Feedback>, speech of <Fee dback>) }

Figura 7. Especificación XLOP de la capa lingüística de <e-Tutor>.

public class TSemClass { ... public Tutorial link(TElement e,Tutorial t) { String idnext = e.idNext(); if (idnext != null) e.setNext(t.get(idnext)); return t; } ... }

Figura 8. Fragmento de la clase semántica para <e-Tutor> que muestra la

implementación de la función semántica link .


ISSN 1932-8540 © IEEE

e-Learning que ha evolucionado a partir de varios sistemas web utilizados en la virtualización de dos museos universitarios con fines educativos en la Universidad Complutense (Museo de Historia de la Informática García

Santesmases y Museo de Arqueología y Etnología Antonio

Ballesteros) [18]. Actualmente es un sistema independiente de dominios concretos y reutilizable en toda experiencia

e-Learning que involucre la creación y uso educativo de repositorios de objetos de aprendizaje.

Los objetos de aprendizaje en Chasqui tienen asociados documentos XML de metadatos que describen la asignación de valores a ítems de metadatos

1 organizados jerárquicamente.

Tales ítems no están predeterminados a priori, sino que se crean de manera colaborativa, conforme se añaden nuevos objetos al repositorio, en un enfoque próximo a las tendencias emergentes en etiquetado colaborativo en el contexto de los escenarios Web X.0 (véase [15] para más detalles).

A fin de evitar detalles que nos aparten del principal propósito de este trabajo, en la discusión que sigue omitiremos la naturaleza jerárquica de los ítems de metadatos en Chasqui. De esta forma, la DTD que se muestra en la Figura 9 describe (una versión simplificada de) el lenguaje de marcado utilizado en Chasqui para estructurar los documentos de metadatos. De acuerdo con este lenguaje, cada ítem de metadatos posee un nombre (Name) y un valor (Value ). Los documentos en sí son secuencias de estos ítems. La Figura 10 muestra un ejemplo de documento de metadatos.

El carácter abierto y evolutivo de los metadatos en Chasqui hace necesario introducir algunos mecanismos de control a fin

1En Chasqui los ítems de metadatos se denominan atributos. No obstante, en

este trabajo evitaremos tal denominación para evitar confusiones.

de garantizar la calidad y consistencia de los documentos de metadatos. Para tal fin, los instructores que lideran la construcción del repositorio de objetos de aprendizaje pueden imponer restricciones sobre los documentos asociados con los objetos que se añaden al repositorio. De esta forma, cuando los alumnos añadan nuevos objetos, el sistema podrá chequear dichas restricciones, así como avisar a dichos alumnos de las potenciales violaciones de las mismas.

En Chasqui las restricciones que pueden formularse involucran un repertorio completo de asertos básicos, que pueden combinarse utilizando los operadores booleanos habituales (and, or y not). Por motivos de simplicidad, restringiremos nuestra discusión a asertos de tipo Contiene. Un aserto de tipo Contiene obliga a que cada ocurrencia de un ítem de metadatos dado contenga cierta cadena especificada en el aserto.

En Chasqui las restricciones también se representan internamente utilizando un lenguaje de marcado basado en XML. La Figura 11 muestra la DTD de dicho lenguaje. La

<! ELEMENT Items (Item+)> <! ELEMENT Item (Name,Value)> <! ELEMENT Name ( #PCDATA)> <! ELEMENT Value ( #PCDATA)>

Figura 9. Lenguaje de marcado (simplificado) para los documentos de metadatos Chasqui.

<Items> <Item> <Name>Descripción </Name> <Value>Informe sobre gramáticas l-atribuidas </Value> </Item> <Item> <Name>Aspecto especificado </Name> <Value>semántica </Value> </Item> <Item> <Name>Formalismo </Name> <Value>gramáticas de atributos </Value> </Item> <Item> <Name>tipo de objeto</ Name> <Value>informe </Value> </Item> </Items>

Figura 10. Un documento de metadatos.

<!ENTITY % Constraint "(And|Or|Not|Contains)"> <!ELEMENT And (%Constraint;,%Constraint;)> <!ELEMENT Or (%Constraint;,%Constraint;)> <!ELEMENT Not (%Constraint;)> <!ELEMENT Contains (It,Val)> <!ELEMENT It ( #PCDATA)> <!ELEMENT Val ( #PCDATA)>

Figura 11. Lenguaje de marcado (simplificado) para las restricciones sobre metadatos.

<Or> <Contains> <It>Descripción </It> <Val>gramática </Val> </Contains> <Contains> <It>Formalismo </It> <Val>gramática </Val> </Contains> </Or>

Figura 12. Un ejemplo de restricción <Check> <Constraint> ... </Constraint> <Items> ... </Items> </Check>

Figura 13. Esquema de la entrada al proceso de comprobación de restricciones.

AssertionStore

+addAssertion(String i, String v)+boolean checkAssertion(String i, String v)+boolean yields(String i, String v)

EResul

+boolean valueOf()+SIterator newIterator()+int supportSize()

SIterator

+next()+String item()+String value() produces

Figura 14. Lógica específica de la aplicación para la comprobación de restricciones en documentos de metadatos Chasqui.


ISSN 1932-8540 © IEEE

Figura 12, por su parte, muestra un ejemplo de restricción que fuerza a que el término gramática ocurra en todos los valores del ítem Descripción , o en todos los valores del ítem Formalismo . La Figura 13 muestra el tipo de entrada que recibe el servicio Chasqui que chequea las restricciones (un documento XML que agrupa bajo el elemento Check una restricción y un documento de metadatos Chasqui).

B. La Capa de Lógica Específica de la Aplicación

La Figura 14 esquematiza la lógica específica de la aplicación utilizada en la comprobación de restricciones sobre documentos de metadatos Chasqui. Dicha lógica específica incluye una clase para almacenar la información necesaria sobre los asertos básicos (AssertionStore ), una segunda clase para contener los resultados de evaluación de las restricciones (EResul ), y una tercera clase para iterar sobre tales resultados (SIterator ).

C. La Capa Lingüística

La Figura 15 muestra la gramática de atributos XLOP que caracteriza el proceso de comprobación de restricciones sobre documentos de metadatos en Chasqui. La gramática incontextual subyacente representa la estructura del documento de tipo Check descrito anteriormente. De nuevo, y por los motivos a los que se ha hecho ya alusión en la sección III, se utiliza recursión a izquierdas para representar la secuencia de ítems en el documento de metadatos. En lo que respecta al procesamiento, éste se concibe en tres etapas diferentes: una primera etapa de recolección en la que se recolectan todos los asertos básicos, una segunda etapa de

chequeo en la que se comprueba si dichos asertos básicos se satisfacen o se violan, y una última etapa de evaluación, en la que se comprueba la satisfacción o violación de la restricción en su totalidad. De esta forma: - La etapa de recolección se lleva a cabo sintetizando un

atributo basicAssertions que referirá al almacén de

asertos (instancia de AssertionStore ) utilizado para almacenar los asertos básicos referidos en la restricción. Este almacén se propaga por las estructuras asociadas al documento de metadatos utilizando un atributo heredado basicAssertionsh .

- La etapa de chequeo se lleva a cabo sintetizando un atributo checkedBasicAssertion que hará referencia al almacén de asertos una vez que cada ítem de metadatos haya sido comprobado con respecto a los asertos básicos. El almacén resultante es realimentado de nuevo sobre la estructura de la restricción utilizando un atributo heredado checkedBasicAssertionh .

- En la etapa de evaluación se sintetiza un atributo val para la restricción. Este atributo contiene un valor de verdad asociado a la restricción y un conjunto de asertos básicos que justifican dicho valor denominado soporte (esta información se almacena en instancias de EResul ). Para asertos básicos, el valor de verdad se obtiene consultando el almacén de asertos. En condiciones afectadas por el operador +ot se complementa el valor de verdad de la condición y se mantiene el conjunto soporte de la condición. El valor de una condición And depende de los valores de sus argumentos: si ambos valores son

CheckDoc ::= <Check><Constraint>C</Constraint> Is</ Check> { basicAssertionsh of Is = basicAssertions of C checkedBasicAssertionsh of C = checkedBasicAsser tions of Is val of CheckDoc = val of C basicAssertions of CheckDoc = checkedBasicAssert ions of Is} C ::= <And> C C </And> { basicAssertions of C(0) = comb(basicAssertions of C(1),basicAssertions of C(2)) checkedBasicAssertionsh of C(1) = checkedBasicA ssertionsh of C(0) checkedBasicAssertionsh of C(2) = checkedBasicA ssertionsh of C(0) val of C(0)= valOfAnd(val of C(1),val of C(2),c heckedBasicAssertionsh of C(0))} C ::= <Or> C C </Or> { basicAssertions of C(0) = comb(basicAssertions of C(1),basicAssertions of C(2)) checkedBasicAssertionsh of C(1) = checkedBasicA ssertionsh of C(0) checkedBasicAssertionsh of C(2) = checkedBasicA ssertionsh of C(0) val of C(0)= valOfOr(val of C(1),val of C(2),ch eckedBasicAssertionsh of C(0))} C ::= <Not> C </Not> { basicAssertions of C(0) = basicAssertions of C (1) checkedBasicAssertionsh of C(1) = checkedBasic Assertionsh of C(0) val of C(0) = valOfNot(val of C(1))} C ::= <Contains> <Attr>#pcdata</Attr> <Val>#pcdata< /Val> </Contains> { basicAssertions of C = newCons(text of #pcdata (0),text of #pcdata(1)) val of C = valOfC(text of #pcdata(0),text of # pcdata(1), checkedBasicAssertionsh of C)} Is ::= <Items> IList</Items> { basicAssertionsh of IList = basicAssertionsh o f Is checkedBasicAssertions of Is = checkedBasicAss ertions of IList } IList ::= IList I { basicAssertionsh of IList(1) = basicAssertions h of IList(0) checkedBasicAssertions of IList(0) = check(che ckedBasicAssertions of IList(1),item of I,val of I) } IList ::= I { checkedBasicAssertions of IList = check(basicA ssertionsh of IList, item of I,val of I) } I ::= <Item> <Name>#pcdata</Name> <Value>#pcdata</V alue> </Item> { item of I = text of #pcdata(0) val of I = text of #pcdata(1) }

Figura 15. Especificación XLOP de la capa lingüística para la comprobación de restricciones sobre metadatos en Chasqui.


ISSN 1932-8540 © IEEE

verdad, el valor final es verdad y el soporte es la unión de los soportes de los argumentos, y en caso contrario el valor de verdad es falso y el conjunto soporte es el conjunto más simple que justifica dicho valor. Por último el valor de una condición Or es el dual de una condición And.

D. La Clase Semántica

La Figura 16 muestra un fragmento de la clase semántica para el procesamiento descrito en esta sección. Obsérvese que la clase maneja internamente estado con el fin de mejorar la eficiencia del procesador finalmente generado. Efectivamente, la clase permite reutilizar el mismo almacén de asertos en todas las operaciones. Esta optimización no compromete, sin embargo, el carácter declarativo de dicha especificación.

V. CONCLUSIONES Y TRABAJO FUTURO XLOP proporciona una abstracción dirigida por lenguajes

que introduce dos capas bien diferenciadas en la construcción de componentes y/o aplicaciones e-Learning que hacen un uso intensivo de documentación XML: una capa con la lógica específica de la aplicación, y una capa lingüística. La capa lingüística se especifica a alto nivel, como una gramática de atributos, y se conecta con la capa de la lógica específica mediante una clase semántica, que implementa las funciones semánticas utilizadas en la gramática. XLOP facilita el desarrollo y mantenimiento de las capas lingüísticas, ya que éstas se especifican a un grado muy alto de abstracción.

Actualmente se están realizando distintas extensiones del lenguaje de especificación de XLOP (e.g., operadores definidos por el usuario, funciones semánticas no estrictas, capacidades de modularización, o tipado estático de las especificaciones). Como trabajo futuro se buscará la integración de XLOP con lenguajes para gramáticas documentales XML. Así mismo se desarrollará un entorno gráfico de depuración. Por último, se aplicará XLOP a experiencias e-Learning adicionales.

AGRADECIMIENTOS El grupo de investigación UCM 921340 y los proyectos

TIN2005-08788-C04-01, TIN2007-68125-C02-01, y Santander/UCM PR34/07-15865 han financiado este trabajo.

REFERENCIAS [1] Aho, A.V., Lam, M.S., Sethi, R., Ullman, J.D. 2007. Compilers:

principles, techniques and tools (second edition). Addison-Wesley

[2] Appel, A.W. 1997. Modern Compiler Implementation in Java. Cambridge Univ. Press

[3] Birbeck, M et al. 2001. Professional XML 2nd Edition. WROX Press, Birminghan,UK

[4] Bork, A. 1985. Personal Computers for Education. Harper & Rows [5] Fernández-Manjón, B., Sierra, J.L., Moreno-Ger, P., Martínez-Ortiz, I.

Uso de Estándares Aplicados a TIC en Educación. Informe Técnico 16, Centro Nacional de Información y Comunicación Educativa (CNICE), ares.cnice.mec.es/informes/16/

[6] IMS. IMS Question and Test Interoperability 2.1. www.imsglobal.org/question/

[7] Kawaguchi, K. 2002. Flexible Data-Biding with RelaxNGCC. Extreme Markup Languages 2002, 4-9 Agosto, Montreal, Canada

[8] Knuth, D. E. 1968. Semantics of Context-free Languages. Math. Syst. Theory 2(2), 127–145. Ver también Math. Syst. Theory 5(1), 95–96

[9] Paaki, J. 1995. Attribute Grammar Paradigms – A High-Level Methodology in Language Implementation. ACM Comp. Surveys, 27(2), 196-255.

[10] Sarasa, A., Navarro, I., Sierra, J.L, Fernández-Valmayor, A. 2008. Building a Syntax Directed Processing Environment for XML Documents by Combining SAX and JavaCC. 3rd Int. Workshop on XML Data Management Tools & Techniques. DEXA’08. 1-5 Sept., Turin, Italia

[11] Sarasa, A., Sierra, J.L., Fernández-Valmayor, A. 2008. Procesamiento de documentos XML dirigido por lenguajes en entornos de e-Learning. SIIE’08, 1-3 Oct., Salamanca, España.

[12] Sarasa, A., Temprado, B., Sierra, J.L., Fernández-Valmayor, A. 2008. XML Language-Oriented Processing with XLOP. 5th Int. Symp. on Web and Mobile Information Services. AINA’09. 26-29 Mayo, Bradford, UK

[13] Sierra, J.L., Fernández-Manjón, B., Fernández-Valmayor, A. 2007. Language-Driven Development of Web-Based Learning Applications. Advances in Web Based Learning - ICWL 2007, LNCS 4823, 520-531

[14] Sierra, J.L., Fernández-Manjón, B., Fernández-Valmayor, A. 2008. A Language-Driven Approach for the Design of Interactive Applications. Interacting with Computers 20(1), 112-127

[15] Sierra, J.L., Fernández-Valmayor, A. 2008. Tagging Learning Objects with Evolving Metadata Schema. ICALT’08. 1-5 Julio, Santander, España.

[16] Sierra, J.L., Fernández-Valmayor, A., Fernández-Manjón, B. 2007. How to Prototype an Educational Modeling Language. SIIE’07, 14-16 Nov., Porto, Portugal.

[17] Sierra, J.L., Fernández-Valmayor, A., Fernández-Manjón, B. 2008. From Documents to Applications Using Markup Languages. IEEE Software 25(2), 68-76

[18] Sierra, J.L., Fernández-Valmayor, A., Guinea, M., Hernánz, H. 2006. From Research Resources to Virtual Objects: Process model and Virtualization Experiences. J. of Ed. Tech. & Society, 9(3), 56-68.

[19] Stanchfield, S., ANTXR: Easy XML Parsing based on The ANLR Parser Generator. Java Due.com, Hillcrest Comm. & FGM, Inc. javadude.com/tools/antxr/index.html

[20] XTutor web site. 2007. icampus.mit.edu/xtutor. Vis. 21 Abril 2008

Antonio Sarasa-Cabezuelo es Licenciado en Ciencias Matemáticas por la Universidad Complutense de Madrid (España), dónde actualmente ejerce como Profesor Colaborador. Coautor de más de 50 artículos publicados en actas de conferencias y revistas, colabora también con RED.ES y el Ministerio de Industria, Turismo y Comercio de España en diversas iniciativas e-Learning (especificación LOM-ES y proyecto AGREGA). Sus intereses investigadores incluyen la creación y despliegue de objetos educativos estandarizados, y el procesamiento de documentos XML dirigido por lenguajes, campo este último en el que está realizando su Tesis Doctoral.

public class CheckingSemanticClass { private AssertionStore astore; public CheckingSemanticClass() { astore = new AssertionStore(); } public AssertionStore newCons(String i, String v) { astore.addAssertion(i,v); return astore; } public AssertionStore comb(AssertionStore a1, AssertionStore a2) { return astore; } ... }

Figura 16. Fragmento de la clase semántica para la comprobación de restricciones sobre metadatos en Chasqui.


ISSN 1932-8540 © IEEE

José-Luis Sierra-Rodríguez es Doctor en Informática por la Universidad Complutense de Madrid (España), dónde actualmente ocupa una plaza de Profesor Titular de Universidad. El Dr. Sierra es coautor de más de 70 artículos de investigación publicados en revistas y actas de conferencias internacionales. Sus intereses investigadores incluyen la Ingeniería del Software orientada a lenguajes, los lenguajes de marcado y el desarrollo dirigido por lenguajes de Sistemas e-Learning.

Alfredo Fernández-Valmayor es Doctor en Ciencias Físicas por la Universidad Complutense de Madrid (España), y Profesor Titular de Universidad en dicha universidad, dónde también dirige el Campus Virtual de la institución. El Dr. Fernández-Valmayor es coautor de más de 70 artículos científicos publicados en revistas y actas de conferencias internacionales. Sus intereses investigadores se centran en los usos educativos de los lenguajes de marcado y en el desarrollo y autoría de materiales para sistemas de educación basados en web.


ISSN 1932-8540 © IEEE

Procesamiento de Documentos XML Dirigido por...

Documents

Transcript of Procesamiento de Documentos XML Dirigido por...