Procesamiento de Documentos XML Dirigido por - IEEE-RITA

IEEE-RITA Vol. 4, Núm. 3, Ago. 2009
175
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
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: languagedriven 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
X
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
ISSN 1932-8540 © IEEE
176
IEEE-RITA Vol. 4, Núm. 3, Ago. 2009
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.
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]).
ISSN 1932-8540 © IEEE
SARASA-CABEZUELO et al.: PROCESAMIENTO DE DOCS. XML DIRIGIDO POR LENGUAJES
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
Generador
XLOP
Documento
XML a
Procesar
Especificación
XLOP
Procesador
177
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
Implementación
en CUP
java
Generador
CUP
Implementación
en JVM
Implementación
en Java
Clase
semántica y
entorno de
ejecución
XLOP
Piensa en el nombre
del país …
¿Cuál es la capital
de Brasil?
(1)
javac
(1)
¡No! Esa es dónde
los carnavales ;)
Figura 2. Cadena de generación en XLOP
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
Brasilia
Río de
Janeiro
(2)
¡No! La respuesta
correcta es Brasilia
Otra
¡No! Piensa en el
nombre del país…
ISSN 1932-8540 © IEEE
(1)
¡Eso es! Vamos
con otra pregunta
(2)
Prueba con otra…
Figura 3. Fragmento de un tutorial socrático
178
IEEE-RITA Vol. 4, Núm. 3, Ago. 2009
<!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
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
Tutorial
next
start
*
<<interface>>
TElement
0..1
Speech
Question
*
Answer
End
for
for
speech
*
feedback
Figura 6. Esbozo de la capa de lógica específica de la aplicación en <e-Tutor>
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
ISSN 1932-8540 © IEEE
SARASA-CABEZUELO et al.: PROCESAMIENTO DE DOCS. XML DIRIGIDO POR LENGUAJES
179
Tutorial ::= <Tutorial> <Start/> TElements <End/> </Tutorial> {
finalUnlinkedTutorialh of TElements = addStartAndEnd(next of <Start>, id of <End>,
unlinkedTutorial of TElements)
tutorial of Tutorial = tutorial of TElements }
TElements ::= TElements TElement {
unlinkedTutorial of TElements(0) = addElement(element of TElement, unlinkedTutorial of TElements(1))
finalUnlinkedTutorialh of TElements(1) = finalUnlinkedTutorialh of TElements(0)
tutorial of TElements(0) = link(element of TElement,tutorial of TElements(1)) }
TElements ::= TElement {
unlinkedTutorial of TElements = addElement(element of TElement,newTutorial())
tutorial of TElements(0) = link(element of TElement,finalUnlinkedTutorialh of TElements) }
TElement ::= <Speech> #pcdata </Speech> {
element of TElement = newSpeech(id of <Speech>,next 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>,forQuestion of <Answer>,default of <Answer>,
text of #pcdata)
}
TElement ::= <Feedback/> {
element of TElement = newFeedback(counter of <Feedback>,forAnswer of <Feedback>,
speech of <Feedback>) }
Figura 7. Especificación XLOP de la capa lingüística de <e-Tutor>.
<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
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.
TElements, así como con Tutorial
representará el tutorial finalmente construido).
(éste
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
ISSN 1932-8540 © IEEE
180
IEEE-RITA Vol. 4, Núm. 3, Ago. 2009
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
<!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)>
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<Or>
<Contains>
<It>Descripción</It>
<Val>gramática</Val>
</Contains>
<Contains>
<It>Formalismo</It>
<Val>gramática</Val>
</Contains>
</Or>
Items (Item+)>
Item (Name,Value)>
Name (#PCDATA)>
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 11. Lenguaje de marcado (simplificado) para las restricciones sobre
metadatos.
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
EResul
+addAssertion(String i, String v)
+boolean checkAssertion(String i, String v)
+boolean yields(String i, String v)
+boolean valueOf()
+SIterator newIterator()
+int supportSize()
SIterator
Figura 10. Un documento de metadatos.
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 metadatos1 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
1
En Chasqui los ítems de metadatos se denominan atributos. No obstante, en
este trabajo evitaremos tal denominación para evitar confusiones.
+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.
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
ISSN 1932-8540 © IEEE
SARASA-CABEZUELO et al.: PROCESAMIENTO DE DOCS. XML DIRIGIDO POR LENGUAJES
181
CheckDoc ::= <Check><Constraint>C</Constraint> Is</Check> {
basicAssertionsh of Is = basicAssertions of C
checkedBasicAssertionsh of C = checkedBasicAssertions of Is
val of CheckDoc = val of C
basicAssertions of CheckDoc = checkedBasicAssertions of Is}
C ::= <And> C C </And> {
basicAssertions of C(0) = comb(basicAssertions of C(1),basicAssertions of C(2))
checkedBasicAssertionsh of C(1) = checkedBasicAssertionsh of C(0)
checkedBasicAssertionsh of C(2) = checkedBasicAssertionsh of C(0)
val of C(0)= valOfAnd(val of C(1),val of C(2),checkedBasicAssertionsh 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) = checkedBasicAssertionsh of C(0)
checkedBasicAssertionsh of C(2) = checkedBasicAssertionsh of C(0)
val of C(0)= valOfOr(val of C(1),val of C(2),checkedBasicAssertionsh of C(0))}
C ::= <Not> C </Not> {
basicAssertions of C(0) = basicAssertions of C(1)
checkedBasicAssertionsh of C(1) = checkedBasicAssertionsh 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 of Is
checkedBasicAssertions of Is = checkedBasicAssertions of IList }
IList ::= IList I {
basicAssertionsh of IList(1) = basicAssertionsh of IList(0)
checkedBasicAssertions of IList(0) = check(checkedBasicAssertions of IList(1),item of I,val of I) }
IList ::= I {
checkedBasicAssertions of IList = check(basicAssertionsh of IList, item of I,val of I) }
I ::= <Item> <Name>#pcdata</Name> <Value>#pcdata</Value> </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.
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
ISSN 1932-8540 © IEEE
182
IEEE-RITA Vol. 4, Núm. 3, Ago. 2009
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; } ... }
[2]
[3]
[4]
[5]
[6]
[7]
Figura 16. Fragmento de la clase semántica para la comprobación de
restricciones sobre metadatos en Chasqui.
[8]
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.
[9]
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.
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
Appel, A.W. 1997. Modern Compiler Implementation in Java.
Cambridge Univ. Press
Birbeck, M et al. 2001. Professional XML 2nd Edition. WROX Press,
Birminghan,UK
Bork, A. 1985. Personal Computers for Education. Harper & Rows
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/
IMS.
IMS
Question
and
Test
Interoperability
2.1.
www.imsglobal.org/question/
Kawaguchi, K. 2002. Flexible Data-Biding with RelaxNGCC. Extreme
Markup Languages 2002, 4-9 Agosto, Montreal, Canada
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
Paaki, J. 1995. Attribute Grammar Paradigms – A High-Level
Methodology in Language Implementation. ACM Comp. Surveys,
27(2), 196-255.
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
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.
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
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
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
Sierra, J.L., Fernández-Valmayor, A. 2008. Tagging Learning Objects
with Evolving Metadata Schema. ICALT’08. 1-5 Julio, Santander,
España.
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.
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
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.
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
XTutor web site. 2007. icampus.mit.edu/xtutor. Vis. 21 Abril 2008
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
ISSN 1932-8540 © IEEE
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.
SARASA-CABEZUELO et al.: PROCESAMIENTO DE DOCS. XML DIRIGIDO POR LENGUAJES
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 eLearning.
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
183