Automatizacion de Tareas en El Web

UNIVERSIDAD CARLOS III DE MADRID
Departamento de Ingenierı́a Telemática
Doctorado en Tecnologı́as de las Comunicaciones
TESIS DOCTORAL
AUTOMATIZACIÓN DE TAREAS
EN EL WEB:
UNA PROPUESTA BASADA EN
ESTÁNDARES
Autor: Vicente Luque Centeno

Licenciado en Informática
Directores: Carlos Delgado Kloos y Luis Sánchez Fernández

Doctores Ingenieros de Telecomunicación
Tribunal nombrado por el Mgfco. y Excmo. Sr. Rector de la Universidad
Carlos III de Madrid, el dı́a de de .
Presidente D.
Vocal D.
Vocal D.
Vocal D.
Secretario D.
Realizado el acto de defensa y lectura de la Tesis el dı́a de

de en .
Calificación:
EL PRESIDENTE EL SECRETARIO LOS VOCALES

Índice general
1. Planteamiento y objetivos 7
1.1. Diferencias entre navegación manual y automática . . . . . . . 9
1.1.1. Esfuerzo . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.2. Propensión a errores . . . . . . . . . . . . . . . . . . . 11
1.1.3. Tiempo de respuesta . . . . . . . . . . . . . . . . . . . 11
1.1.4. Requisitos hardware y software . . . . . . . . . . . . . 11
1.1.5. Adecuación de repositorios . . . . . . . . . . . . . . . . 12
1.1.6. Procesamiento . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.7. Coste de implantación y adaptabilidad . . . . . . . . . 13
1.2. Ejemplos de tareas costosas para la navegación manual . . . . 13
1.3. Tipos de programas de navegación automatizada . . . . . . . . 16
1.3.1. Programas de navegación genérica no adaptada . . . . 16
1.3.2. Programas de navegación genérica adaptada . . . . . . 17
1.3.3. Programas de navegación particularizada . . . . . . . . 17
1.3.4. Modos de integración de aplicaciones Web . . . . . . . 20
1.3.5. Sistemas mediadores . . . . . . . . . . . . . . . . . . . 22
1.3.6. Asistentes de navegación Web . . . . . . . . . . . . . . 24
1.4. Caracterı́sticas de los datos del Web . . . . . . . . . . . . . . . 25
1.4.1. Voluminosidad . . . . . . . . . . . . . . . . . . . . . . 25
1.4.2. Heterogeneidad . . . . . . . . . . . . . . . . . . . . . . 26
1.4.3. Orientación a los visualización . . . . . . . . . . . . . . 26
i
1.4.4. Relevancia dependiente de la tarea . . . . . . . . . . . 29
1.4.5. Regularidad estructural . . . . . . . . . . . . . . . . . 30
1.4.6. Ausencia de semántica en el marcado . . . . . . . . . . 32
1.4.7. Niveles de estructuración . . . . . . . . . . . . . . . . . 32
1.4.8. Distribución de la información . . . . . . . . . . . . . . 35
1.4.9. Difı́cil modificabilidad . . . . . . . . . . . . . . . . . . 36
1.4.10. Aportaciones de XML . . . . . . . . . . . . . . . . . . 36
1.5. Coste de la navegación automatizada . . . . . . . . . . . . . . 39
1.5.1. Coste de desarrollo . . . . . . . . . . . . . . . . . . . . 41
1.5.2. Coste de ejecución fallida . . . . . . . . . . . . . . . . . 42
1.5.3. Coste de mantenimiento . . . . . . . . . . . . . . . . . 45
1.6. Marco de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.7. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.8. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . 51
2. Análisis de tareas Web 53

2.1. Acciones básicas implı́citas . . . . . . . . . . . . . . . . . . . . 57
2.1.1. Gestión de cabeceras HTTP . . . . . . . . . . . . . . . 57
2.1.2. Gestión de errores en la comunicación con el servidor . 58
2.1.3. Reparación interna de páginas mal construidas . . . . . 58
2.1.4. Seguimiento implı́cito de enlaces . . . . . . . . . . . . . 59
2.1.5. Ejecución de comportamientos embebidos en las páginas 60
2.1.6. Soporte para otros protocolos . . . . . . . . . . . . . . 61
2.1.7. Tratamiento adecuado de cada campo de formularios
según su forma de rellenado . . . . . . . . . . . . . . . 61
2.1.8. Creación de query-string a partir de un formulario relleno 62
2.2. Acciones básicas explı́citas . . . . . . . . . . . . . . . . . . . . 63
2.2.1. Extracción de datos relevantes . . . . . . . . . . . . . . 63
2.2.2. Estructuración de datos semiestructurados . . . . . . . 65
2.2.3. Seguimiento explı́cito de enlaces . . . . . . . . . . . . . 66
ii
2.2.4. Rellenado de formularios . . . . . . . . . . . . . . . . . 67
2.2.5. Envı́o de formularios . . . . . . . . . . . . . . . . . . . 68
2.2.6. Procesamiento de datos . . . . . . . . . . . . . . . . . 68
2.3. Subsanación de las faltas de soporte de la plataforma de na-
vegación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3. Estado de la cuestión 71
3.1. Consideraciones previas . . . . . . . . . . . . . . . . . . . . . . 71
3.2. Automatización de aplicaciones interactivas . . . . . . . . . . 72
3.2.1. Lenguaje Expect . . . . . . . . . . . . . . . . . . . . . 73
3.3. Web Semántico . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.4. Mecanismos de construcción de programas de navegación au-
tomatizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.4.1. Uso de APIs estándares . . . . . . . . . . . . . . . . . 83
3.5. Conclusiones del estado de la cuestión . . . . . . . . . . . . . . 87
3.6. Limitaciones de las tecnologı́as actuales . . . . . . . . . . . . . 90
4. Selección de tecnologı́as para la automatización de tareas en

el Web 95
4.1. MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.1.1. Entidades . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.1.2. Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.1.3. Acciones . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.1.4. Temporizadores . . . . . . . . . . . . . . . . . . . . . . 99
4.1.5. Corregiones . . . . . . . . . . . . . . . . . . . . . . . . 100
4.1.6. Condiciones . . . . . . . . . . . . . . . . . . . . . . . . 101
4.1.7. Creación y destrucción dinámica de entidades . . . . . 101
4.1.8. Expresiones inline . . . . . . . . . . . . . . . . . . . . . 103
4.1.9. Descomposición modular . . . . . . . . . . . . . . . . . 103
4.2. XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.2.1. Secuencias . . . . . . . . . . . . . . . . . . . . . . . . . 108
iii
4.2.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.2.3. Operadores aritmético-lógicos y de comparación . . . . 110
4.2.4. Ejes de navegación . . . . . . . . . . . . . . . . . . . . 110
4.2.5. Predicados . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.2.6. Llamadas a funciones . . . . . . . . . . . . . . . . . . . 112
4.2.7. Constructores de datos secundarios . . . . . . . . . . . 112
4.2.8. Modificaciones introducidas en XPath 2.0 respecto de
XPath 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.2.9. Aportaciones de XPath . . . . . . . . . . . . . . . . . . 114
4.3. XPointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.3.1. Puntos . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.3.2. Rangos . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.3.3. Patrones de texto . . . . . . . . . . . . . . . . . . . . . 116
4.3.4. Aportaciones de XPointer . . . . . . . . . . . . . . . . 117
4.4. XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.4.1. Aportaciones de XSLT . . . . . . . . . . . . . . . . . . 119
4.5. XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.5.1. Aportaciones de XQuery . . . . . . . . . . . . . . . . . 121
4.6. DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.6.1. Aportaciones de DOM . . . . . . . . . . . . . . . . . . 122
4.7. SAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.7.1. Aportaciones de SAX . . . . . . . . . . . . . . . . . . . 124
5. XTendedPath: Lenguaje para la consulta y modificación de

documentos XML 125
5.1. Problemas de XPath 2.0 . . . . . . . . . . . . . . . . . . . . . 126
5.1.1. Procesamiento incremental . . . . . . . . . . . . . . . . 126
5.1.2. Dificultad para calcular valores agregados . . . . . . . 129
5.1.3. Combinar dos o más secuencias en una nueva . . . . . 130
5.1.4. XPath no puede expandirse indefinidamente . . . . . . 130
iv
5.1.5. Poca flexibilidad para llamar a ciertas funciones . . . . 131
5.1.6. Poca reusabilidad para expresiones de tipo “for” . . . . 131
5.2. Soluciones basadas en funciones de orden superior . . . . . . . 131
5.3. Lenguaje XTendedPath: extensión de XPath 2.0 . . . . . . . . 135
5.4. Componentes comunes con XPath 2.0 . . . . . . . . . . . . . . 140
5.4.1. Tipos de datos comunes . . . . . . . . . . . . . . . . . 140
5.4.2. Consideraciones semánticas . . . . . . . . . . . . . . . 141
5.4.3. Funciones de comparación . . . . . . . . . . . . . . . . 143
5.4.4. Funciones lógicas . . . . . . . . . . . . . . . . . . . . . 144
5.4.5. Función TO: (generador de secuencias numéricas) . . . 144
5.4.6. Funciones EVERY y SOME: (expresiones cuantificadas) 145
5.4.7. Funciones eje . . . . . . . . . . . . . . . . . . . . . . . 145
5.4.8. Función F: (predicados) . . . . . . . . . . . . . . . . . 152
5.4.9. Elemento raı́z del documento . . . . . . . . . . . . . . 154
5.4.10. Funciones de datos secundarios . . . . . . . . . . . . . 154
5.4.11. Operaciones con secuencias . . . . . . . . . . . . . . . 154
5.5. Extensiones propias de XTendedPath . . . . . . . . . . . . . . 155
5.5.1. Extensiones provenientes de XPointer . . . . . . . . . . 156
5.5.2. Orden superior . . . . . . . . . . . . . . . . . . . . . . 166
5.5.3. Modificación de documentos . . . . . . . . . . . . . . . 170
6. XPlore: Lenguaje para la navegación y procesamiento de da-

tos en el Web 175
6.1. Componentes de XPlore orientados a la navegación . . . . . . 181
6.1.1. Transacciones HTTP . . . . . . . . . . . . . . . . . . . 181
6.1.2. Combinadores de servicios . . . . . . . . . . . . . . . . 182
6.2. Componentes de XPlore orientados al procesamiento . . . . . 185
6.2.1. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.2.2. Sentencias de control de flujo . . . . . . . . . . . . . . 186
6.2.3. Entrada/salida . . . . . . . . . . . . . . . . . . . . . . 188
v
6.2.4. Estado de ejecución . . . . . . . . . . . . . . . . . . . . 189
6.2.5. Errores en la ejecución . . . . . . . . . . . . . . . . . . 189
6.2.6. Funciones . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.2.7. Llamada a clases Java externas . . . . . . . . . . . . . 190
6.2.8. Llamada a programas externos . . . . . . . . . . . . . . 192
6.2.9. Operador de concurrencia . . . . . . . . . . . . . . . . 192
7. Ejemplos desarrollados con los lenguajes propuestos 195

7.1. Valoración de una cartera de acciones del Nasdaq en euros . . 196
7.2. Publicación de un catálogo de artı́culos en un Web de subastas 201
7.3. Listado de correos nuevos en un Web de correo gratuito y
borrado de spam . . . . . . . . . . . . . . . . . . . . . . . . . 208
7.4. Recomendaciones de desarrollo . . . . . . . . . . . . . . . . . . 213
8. Conclusiones y trabajos futuros 221

8.1. Principales contribuciones . . . . . . . . . . . . . . . . . . . . 221
8.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
8.3. Lı́neas de trabajos futuros . . . . . . . . . . . . . . . . . . . . 225
8.3.1. Herramienta CASE . . . . . . . . . . . . . . . . . . . . 225
8.3.2. Accesibilidad a sitios Web orientados a la visualización 226
8.3.3. Desarrollo de agentes inteligentes no particularizados . 228
8.4. Gramática EBNF del lenguaje XPlore . . . . . . . . . . . . . 229
vi
Índice de cuadros
1.1. Diferencias entre la navegación manual y la navegación au-

tomática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2. Clasificación de programas que navegan por el Web según su
adaptación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3. Comparaciones aclarativas de alternativas de navegación
según coste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4. Principales diferencias entre las últimas versiones de HTML . 29
1.5. Diferencias entre caracterı́sticas de los datos según su nivel de
estructuración . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.6. Resumen de aportaciones de XML . . . . . . . . . . . . . . . . 38
1.7. Resumen de tipos de coste de la navegación automatizada . . 40
1.8. Resumen de medidas de robustez según origen del fallo . . . . 45
2.1. Diferencias entre acciones básicas explı́citas e implı́citas . . . . 57

2.2. Principales cabeceras gestionadas por los clientes del protocolo
HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.3. Tipo de seguimiento de enlaces HTML dependiendo del browser 60
2.4. Tipo de rellenado de campos de formularios HTML . . . . . . 62
2.5. Acciones básicas explı́citas . . . . . . . . . . . . . . . . . . . . 63
3.1. Resumen de las tecnologı́as utilizables . . . . . . . . . . . . . . 87
4.1. Tipos de expresiones inline . . . . . . . . . . . . . . . . . . . . 103

4.2. Ejes de XPath partiendo de un nodo contexto . . . . . . . . . 111
vii
5.1. Resumen de los lenguajes basados en XPath . . . . . . . . . . 138
5.2. Reescritura de tipos de datos de XPath en XTendedPath . . . 141
5.3. Operadores de comparación en XTendedPath . . . . . . . . . . 143
5.4. Operadores lógicos en XTendedPath . . . . . . . . . . . . . . 144
5.5. Generador de secuencias numéricas en XTendedPath . . . . . 144
5.6. Expresiones cuantificadas en XTendedPath . . . . . . . . . . . 145
5.7. Semántica de la función C . . . . . . . . . . . . . . . . . . . . 146
5.8. Ejemplo de la aplicación de la currificación en la función C . . 146
5.9. Semántica de la función D . . . . . . . . . . . . . . . . . . . . 147
5.10. Semántica de la función DORSELF . . . . . . . . . . . . . . . 147
5.11. Semántica de la función P . . . . . . . . . . . . . . . . . . . . 148
5.12. Semántica de la función A . . . . . . . . . . . . . . . . . . . . 148
5.13. Semántica de la función AORSELF . . . . . . . . . . . . . . . 149
5.14. Semántica de la función PS . . . . . . . . . . . . . . . . . . . 149
5.15. Semántica de la función FS . . . . . . . . . . . . . . . . . . . 150
5.16. Semántica de la función PREC . . . . . . . . . . . . . . . . . 150
5.17. Semántica de la función FOLL . . . . . . . . . . . . . . . . . . 151
5.18. Semántica de la función AT . . . . . . . . . . . . . . . . . . . 151
5.19. Texto de nodos en XTendedPath . . . . . . . . . . . . . . . . 152
5.20. Semántica de la función F . . . . . . . . . . . . . . . . . . . . 153
5.21. Elemento raı́z del documento . . . . . . . . . . . . . . . . . . 154
5.22. Funciones de datos secundarios . . . . . . . . . . . . . . . . . 154
5.23. Expresiones con secuencias . . . . . . . . . . . . . . . . . . . . 155
5.24. Operador de evaluación alternativa . . . . . . . . . . . . . . . 157
5.25. Puntos adyacentes de un nodo x . . . . . . . . . . . . . . . . . 159
5.26. Operador de patrones de texto . . . . . . . . . . . . . . . . . . 162
5.27. Funciones auxiliares . . . . . . . . . . . . . . . . . . . . . . . . 163
5.28. Algunos ejemplos de rangos . . . . . . . . . . . . . . . . . . . 164
5.29. Semántica de la expresión INSIDE(a,b) . . . . . . . . . . . . . 164
viii
5.30. Ejemplos de uso del operador jerárquico INSIDE . . . . . . . . 165
5.31. Semántica de la expresión CONTAIN(a,b) . . . . . . . . . . . 165
5.32. Funciones de orden superior de XTendedPath . . . . . . . . . 167
5.33. Ejemplos de expresiones XPath y sus equivalentes en XTen-
dedPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
5.34. Operadores básicos de modificación de documentos . . . . . . 171
5.35. Ejemplos de uso de la función MASK . . . . . . . . . . . . . . 173
6.1. Relación de expresiones inline con sentencias de control de flujo188

6.2. Primitivas de entrada/salida . . . . . . . . . . . . . . . . . . . 188
6.3. Primitivas de cambio de estado de ejecución . . . . . . . . . . 189
6.4. Primitivas de errores de ejecución . . . . . . . . . . . . . . . . 189
7.1. Estructura del documento XML con las cotizaciones del Nas-
daq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
ix
x
Índice de figuras
1.1. Sistema mediador . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.2. Comparación de navegación manual con automática . . . . . . 25
1.3. Regularidad en el Web . . . . . . . . . . . . . . . . . . . . . . 31
3.1. Script Expect para controlar ejecución interactiva de ftp . . . 74

3.2. Script Expect para controlar ejecución interactiva de talk . . . 75
3.3. Ejemplo de documento XML sencillo . . . . . . . . . . . . . . 84
3.4. Programa Java que extrae datos de documento XML con DOM 84
3.5. Programa Java que extrae datos de documento XML con XPath 85
3.6. Hoja XSLT que extrae datos de documento XML . . . . . . . 86
4.1. Entidades de un MSC . . . . . . . . . . . . . . . . . . . . . . 98

4.2. Mensajes de un MSC . . . . . . . . . . . . . . . . . . . . . . . 99
4.3. Acciones de un MSC . . . . . . . . . . . . . . . . . . . . . . . 99
4.4. Temporizadores de un MSC . . . . . . . . . . . . . . . . . . . 100
4.5. Corregiones en un MSC . . . . . . . . . . . . . . . . . . . . . 101
4.6. Condiciones de un MSC . . . . . . . . . . . . . . . . . . . . . 102
4.7. Creación y destrucción dinámica de entidades en un MSC . . . 102
4.8. Expresiones inline en un MSC . . . . . . . . . . . . . . . . . . 104
4.9. Referencias a otros MSC . . . . . . . . . . . . . . . . . . . . . 105
4.10. MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.11. Funcionalidades de XPath 2.0 comparadas con las de XPath 1.0109
4.12. Representación de elementos XPointer en un fragmento XML . 116
xi
4.13. Expresión XPath reformulada con el operador if . . . . . . . . 120
4.14. Expresión XPath reformulada con el operador every . . . . . . 120
5.1. Expresión XPath 2.0 que calcula importe de ventas con sub-
totales parciales . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.2. Pseudocódigo basado en variables que calcula subtotales . . . 127
5.3. Pseudocódigo basado en funciones que calcula subtotales . . . 128
5.4. Ejemplo de expresión de tipo for . . . . . . . . . . . . . . . . . 131
5.5. Ejemplo foldl en Haskell . . . . . . . . . . . . . . . . . . . . . 133
5.6. Ejemplo zip en Haskell . . . . . . . . . . . . . . . . . . . . . . 133
5.7. Ejemplo scanl en Haskell . . . . . . . . . . . . . . . . . . . . . 133
5.8. Ejemplo scanl1 en Haskell . . . . . . . . . . . . . . . . . . . . 134
5.9. Elementos para los que f() es mı́nimo . . . . . . . . . . . . . . 135
5.10. Determinar si para una secuencia se devuelve todo positivo . . 135
5.11. Para una secuencia se devuelve ordenado . . . . . . . . . . . . 135
5.12. Restricción que debe cumplir todo rango en XTendedPath . . 160
5.13. Restricción de rangos reescrita con operadores jerárquicos . . . 165
5.14. Algunas funciones de orden superior definidas en XTendedPath 168
5.15. Ejemplo de expresión lambda definida en Java . . . . . . . . . 170
5.16. Ejemplo de expresiones de rellenado de formulario . . . . . . . 171
5.17. Expresión XPath equivalente a
source//address[addressee[text() =name]] . . . . . . . . . . . 173
6.1. Representación de transacción HTTP . . . . . . . . . . . . . . 182

6.2. Ejemplo de ejecución temporizada . . . . . . . . . . . . . . . . 183
6.3. Ejemplo de ejecución reiterada . . . . . . . . . . . . . . . . . . 184
6.4. Ejemplo de ejecución secuencial . . . . . . . . . . . . . . . . . 184
6.5. Ejemplo de ejecución concurrente . . . . . . . . . . . . . . . . 185
6.6. Ejemplo de combinación de servicios . . . . . . . . . . . . . . 185
6.7. Representación de un bucle y una sentencia condicional ani-
dados en XPlore notación MSC . . . . . . . . . . . . . . . . . 187
xii
6.8. Ejemplo de sentencias anidadas en notación compacta de XPlore187
6.9. Representación de llamadas a funciones en XPlore notación
MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.10. Ejemplo de definición de función Identif en XPlore notación
compacta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.11. Ejemplo de llamada de función en XPlore . . . . . . . . . . . 191
6.12. Ejemplo de llamada a clases Java desde XPlore notación com-
pacta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
6.13. Representación de llamada a programa externo . . . . . . . . . 192
6.14. Representación de operador de concurrencia . . . . . . . . . . 194
7.1. Cambio de divisas del BCE . . . . . . . . . . . . . . . . . . . 197

7.2. MSC gráfico del programa Nasdaq . . . . . . . . . . . . . . . . 198
7.3. Programa Nasdaq en XPlore notación MSC . . . . . . . . . . 199
7.4. Programa Nasdaq en XPlore notación compacta . . . . . . . . 200
7.5. MSC gráfico del programa Aucland . . . . . . . . . . . . . . . 202
7.6. Programa Aucland en XPlore notación MSC . . . . . . . . . . 203
7.7. Campos del formulario de publicación de Aucland . . . . . . . 204
7.8. Programa Aucland en XPlore notación compacta . . . . . . . 205
7.9. Programa Aucland en XPlore notación compacta (2) . . . . . 206
7.10. Programa Aucland en XPlore notación compacta (3) . . . . . 207
7.11. Bandeja de entrada del correo de Yahoo! . . . . . . . . . . . . 208
7.12. MSC gráfico del programa YahooMail . . . . . . . . . . . . . . 210
7.13. MSC gráfico del programa YahooMail (2) . . . . . . . . . . . . 211
7.14. Programa YahooMail en XPlore notación MSC . . . . . . . . . 212
7.15. Programa YahooMail en XPlore notación MSC (2) . . . . . . 213
7.16. Programa YahooMail en XPlore notación compacta . . . . . . 214
7.17. Programa YahooMail en XPlore notación compacta (2) . . . . 215
xiii
xiv
Agradecimientos
Quiero agradecer a todas aquellas personas que, de una un otra forma,

han hecho posible este trabajo. Agradezco a mis padres el haber depositado
su confianza en mı́ y haberme permitido seguir adelante y haberme apoyado
en todo momento. A mis directores de tesis, quiero agradecerles los buenos
y consejos y las sabias preguntas que me hicieron buscar las respuestas para
elaborar este trabajo. A mis compañeros del Departamento de Ingenierı́a
Telemática, por toda la colaboración recibida y por todo lo que de ellos he
aprendido en estos años de doctorado. A mis antiguos compañeros de la
Facultad de Informática, de donde tantı́simas cosas aprendı́. A mis amigos y
amigas por haber estado ahı́ todo este tiempo.
1
2
Resumen
Actualmente, millones de usuarios en todo el mundo se ven abocados a

realizar cada dı́a tareas en Internet, manejando de forma repetida un con-
junto cada vez mayor de remotas aplicaciones que se encuentran accesibles
en el Web. Para todas esas labores, la gran mayorı́a de esas personas ape-
nas cuenta con la única ayuda de los browsers, lo cual confiere al proceso
de navegación una alta necesidad de interacción por parte del usuario, en lo
que habitualmente se conoce como navegación manual. Sin embargo, ello a
menudo implica un esfuerzo demasiado elevado para muchas personas, es-
pecialmente cuando el volumen de datos es grande o la complejidad de su
manejo requiere muchas interacciones con el browser.
Desarrollar programas que naveguen automatizadamente por el Web, ma-
nipulando inteligentemente la información disponible en Internet es una ne-
cesidad cada vez más demandada en numerosos entornos. Sin embargo, el
desarrollo de este tipo de programas tradicionalmente se ha afrontado con
técnicas que implican un alto coste de desarrollo y un elevado coste de man-
tenimiento, además de tener una vida demasiado corta y ser muy sensibles
a pequeñas modificaciones en las páginas accedidas. En este trabajo se pro-
ponen nuevas técnicas basadas en estándares para reducir el coste de estos
desarrollos y mejorar la estabilidad de estos programas.
3
4
Abstract
Nowadays, millions of people around the world have to daily perform tasks
on Internet, repeatedly managing an increasing amount of Web enabled ap-
plications. For many of these tasks, most people use browsers, by manually
and mecanically interacting with screens of data retrieved from remote com-
puters. However, this implies too much effort for too many people, specially
when the amount of data is big or those data require complex managements
with several user interactions.
Developing wrapper agents to automate these tasks for the user, by inte-
lligently managing Web’s data is an increasingly demanded need at several
enterprises. However these programs have traditionally had a large deve-
lopment and maintenance cost, they have had very short lives and their
behaviour when minor changes affect pages is not desirable. This document
presents several standards-based new techniques for reducing these costs and
making these programs more stable.
5
6
Capı́tulo 1
Planteamiento y objetivos
Esta tesis doctoral aborda el problema de la automatización de tareas

en el Web. En cualquier automatización, como por ejemplo cualquiera de las
llevadas a cabo en un complejo industrial, se persigue delegar en las máquinas
la realización de trabajos, de forma que éstos sean llevados a cabo con la
mı́nima intervención humana y mecánica posible bajo un coste amortizable.
El World Wide Web se ha convertido en poco tiempo en el mayor reposi-
torio de conocimiento de la humanidad. Una multitud creciente de servicios
Web, que comprenden, por una parte, a los servidores de información alma-
cenada en simples páginas Web, y por otra, a las aplicaciones remotamente
accesibles desde el Web para muy diversos propósitos, se puede acceder a
través de una gran variedad de páginas Web. Gran cantidad de esa informa-
ción se encuentra muchas veces almacenada en bases de datos que, siendo
accesibles mediante interfaces especı́ficamente diseñadas para el Web, se en-
cuentran sin embargo a veces sin explorar conforme a las necesidades particu-
lares de muchos usuarios. Mucha información, ciertamente, pero en especial
muchas aplicaciones accesibles remotamente desde el Web, acaban quedando
infrautilizadas para muchos usuarios en un mundo donde los browsers se han
quedado ciertamente limitados como herramientas de trabajo, ya que care-
cen de cualquier tipo de propósito más allá que el de la mera presentación
paginada de datos al usuario y la recogida de datos del usuario mediante
formularios.
La heterogeneidad del Web actual es inmensa. Por un lado, hay innume-
rables formas posibles de organizar y estructurar los contenidos dentro de
cada página mediante distintas combinaciones de etiquetas de marcado, no
sólo HTML sino también XML. Por otro lado, existen múltiples variantes
para distribuir la información entre las distintas páginas, ası́ como múltiples
7
maneras de dejar éstas enlazadas entre sı́. Toda esta heterogeneidad dificulta
enormemente la integración de datos obtenidos de distintos servidores para su
combinación o gestión unificada. La integración de datos de diversas fuentes,
bien para la obtención de datos elaborados con valor añadido (sindicación de
contenidos), bien como cadena de suministro (aplicaciones que deban pasar-
se datos de unas a otras), es un área que actualmente está demandando un
creciente interés, habida cuenta de la necesidad de automatizar el manejo de
grandes volúmenes de datos en el Web.
En ocasiones, los usuarios se encuentran con la tarea de tener que rellenar
muchas veces un conjunto conocido de formularios o seguir de forma repeti-
tiva un mismo conjunto de enlaces para poder conseguir la información que
desean o para poder manejar intensivamente aplicaciones remotamente por
medio del Web. Estos usuarios acaban invirtiendo para ello gran cantidad
de tiempo en labores que, dado su automatismo, serı́a muchas veces posible
que se realizaran autónonamente por un ordenador. Es habitual que muchas
de estas aplicaciones del Web ofrezcan interfaces para realizar transacciones
simples, pero no que dispongan de interfaces para ofrecer múltiples transac-
ciones que puedan ser procesadas por lotes. Sin embargo, los usuarios no
disponen hoy en dı́a de otra herramienta más allá del browser, por lo que
acaban debiendo aprobar con un click de ratón cada enlace que desean se-
guir una y otra vez, transacción a transacción, repetidamente cada vez que
manejan una de estas aplicaciones accesibles desde el Web.
Tradicionalmente, uno de los grandes problemas del Web estriba en la
incapacidad de manejar en él grandes volúmenes de información de forma
efectiva, conforme a los deseos de los usuarios. Los grandes buscadores ape-
nas resuelven una pequeña parte del problema de la búsqueda de información.
Aunque son capaces de listar los documentos del Web en los que se sabe que
aparecen los términos de búsqueda, no sin problemas como los apuntados por
[28], los buscadores no dejan de devolver como resultados documentos ente-
ros, dejando al usuario la responsabilidad de analizar su estructura, semántica
o funcionalidad interna con el fin de buscar allı́ los datos que le interesan. Sin
duda, las necesidades de los usuarios son mucho más complejas que aquellas
a las que puede dar respuesta un simple buscador, ya que, una vez delante
de la página en la que debe empezar a trabajar, debe ser el usuario quien in-
dique por dónde navegar, construyendo ası́ el camino que le lleve a conseguir
sus objetivos.
8
1.1. Diferencias entre navegación manual y
automática
Dentro del mundo industrial en general, la automatización persigue in-

crementar la productividad de las personas, minimizando los errores propios
de la naturaleza humana y mejorando ası́ la eficiencia en la realización de
trabajos y en la optimización de los recursos involucrados. Con la automa-
tización de tareas en el Web se persiguen esos mismos objetivos aplicados
en la realización del cada vez mayor número de tareas que pueden realizarse
a través del Web. Al igual que en cualquier empresa, el objetivo principal
de la automatización de tareas en el Web es ahorrar tiempo y esfuerzo a
las personas. En el caso del Web, los beneficios de la automatización serán
más patentes en aquellas tareas que necesiten procesar grandes volúmenes
de información o que deban ser frecuentemente ejecutadas.
Trasladando a las máquinas las actividades más automatizables y rutina-
rias, se permite ahorrar esfuerzo a las personas. Gracias a ello las personas
pueden centrarse en otras actividades, habitualmente más productivas, crea-
tivas y probablemente más adecuadas para sus trabajos y sus preparaciones.
Sin duda, la productividad y creatividad humana se ve muchas veces ale-
targada por las tareas más rutinarias de navegación en el Web. El hecho de
tener que realizar una y otra vez los mismos pasos dı́a a dı́a delante de un
browser, siguiendo los mismos enlaces y rellenando una y otra vez los mis-
mos formularios, acaba siendo una tarea que requiere demasiado esfuerzo y
dedicación para muchas personas. Ejemplos de tareas que pueden requerir
ser realizadas frecuentemente, son las que se pueden llevar a cabo con aplica-
ciones como las bancarias (comprobaciones de saldo, transferencias, listado
de movimientos, operaciones de bolsa, subastas de depósitos, fondos de in-
versión ...), de subastas (publicación de artı́culos para vender, búsqueda y
comparación de artı́culos para pujar, inserción de pujas, gestión de avisos,
evaluación de transacciones, ...), de compra-venta (búsqueda y comparación
de artı́culos, realización de pedidos y de pagos, ...), de reserva de billetes de
avión o de tren, habitaciones de hotel, entradas a espectáculos, envı́o de men-
sajes, ası́ como un largo etcétera. Estas aplicaciones se encuentran cada vez
más frecuentemente, tanto en las intranets de las empresas, como accesibles
a todo el mundo en un gran número de servidores.
Algunas de las tareas Web, en especial las que deben hacerse de forma re-
petitiva mediante browsers, suponen demasiado esfuerzo, en tanto en cuanto
para llevarlas a cabo, las acciones mecánicas que debe ejecutar el usuario pa-
ra indicar sus instrucciones al ordenador, deben ser repetidas muchas veces.
9
Al contrario de lo que ocurre con la navegación manual basada en browsers,
gracias a la automatización de tareas en el Web, grandes volúmenes de in-
formación distribuida en múltiples bases de datos accesibles desde el Web
pueden ser procesados conforme a los intereses de los usuarios requiriendo
de ellos un esfuerzo mı́nimo. Las principales diferencias entre la navegación
manual y la automática, resumidas en la tabla 1.1, aparecen detalladas a
continuación.
Navegación manual Navegación automática

Intervención Humana Ordenador
Acción Mecánica Programada
Esfuerzo De navegación De programación
Errores De navegación De programación
Tiempo de respuesta Significativo Ínfimo
Requisitos Browser Conexión
Repositorios No programables Programables
Procesamiento Cálculo mental Automatizable
Volumen de datos Limitado Enorme
Implantación Factible Costosa
Adaptabilidad ante cambios Tolerable Costosa
Cuadro 1.1: Diferencias entre la navegación manual y la navegación automáti-

ca
1.1.1. Esfuerzo
El Web actual está diseñado para ser navegado de forma interactiva, con
el usuario proporcionando mecánicamente una a una sus instrucciones detrás
de la pantalla del ordenador, haciendo click en cada enlace que desea seguir.
Ello supone en muchas ocasiones un serio coste de recursos humanos, esto
es, de personas que deben dedicar a menudo una gran cantidad de tiempo,
esfuerzo y perseverancia frente al ordenador para realizar tareas sencillas.
Frente a esa opción, una tarea automatizada por un programa capaz de
navegar en lugar del usuario, emulando el comportamiento de la actuación
conjunta de éste y del navegador, puede reducir significativamente ese coste
de navegación.
10
1.1.2. Propensión a errores
La interacción mecánica de las personas en la navegación manual aumenta
en gran medida la propensión a cometer errores durante la ejecución de la
tarea. Este riesgo se hace más probable cuando el conjunto de datos que debe
ser manipulado es voluminoso. Por el contrario, un programa que navegue
automáticamente por el Web puede manipular eficiente y adecuadamente
grandes volúmenes de información, incluso a pesar de que ésta se encuentra
distribuida en varias fuentes de datos.
1.1.3. Tiempo de respuesta

Pese a que el rendimiento de una aplicación Web está principalmente
condicionado por el tiempo de respuesta del servidor y de las conexiones
que comunican a éste con el cliente, lo cierto es que, las personas, cuando
navegamos delante de un browser en el que debemos introducir interactiva-
mente nuestras órdenes, tenemos unos tiempos de respuesta significativos.
Además, y no menos importante, las personas somos fácilmente distraı́bles
de nuestros cometidos, como puede ocurrir con la aparición de enlaces que
inesperadamente reclamen nuestra atención por un tema que nos interese y
no tenga nada que ver con la tarea que nos estaba ocupando. Incluso en una
escena en la que un operador se encuentre altamente concentrado en la rea-
lización de una tarea con un browser, el simple hecho de tener que activar
mecánicamente unos dispositivos de introducción de datos, como el teclado y
el ratón, estando a la vez pendiente de varias ventanas abiertas en la pantalla
que reclaman simultáneamente la atención del usuario, supone unos tiempos
de retraso que, aunque aceptables para unas pocas transacciones, resultan
ciertamente frustrantes cuando el número de acciones mecánicas a ejecutar
acaba siendo elevado, especialmente debido a la imposibilidad de ordenar
trabajos por lotes en el Web.
1.1.4. Requisitos hardware y software

Sin duda, uno de los grandes problemas de los browsers es que, además
de la intervención mecánica necesaria para poder proceder al seguimiento de
enlaces, requieren de hardware y software especializado, de forma que gran
parte del Web ahora mismo está pensada exclusivamente para ser accesi-
ble desde ordenadores personales (PC), con unas resoluciones de pantalla
determinadas, y con unos requisitos de software especı́ficos muy concretos.
11
Sin embargo, la proliferación de un cada vez mayor número de dispositivos
electrónicos conectados a la red, como algunas cabinas públicas de acceso a
Internet, los dispositivos inalámbricos, u otros pequeños electrodomésticos,
está aumentando el número de dispositivos con reducidas capacidades de vi-
sualización de datos, que, sin embargo, no dejan de ser capaces de tratar
adecuadamente los datos de la Red. Estos dispositivos podrı́an fácilmente
conectarse a la red para automatizar tareas en el Web, al igual que lo hace
cualquier otro ordenador, conforme a lo propuesto en [42], prescindiendo, al
tratar automáticamente las páginas sin necesitar que el usuario las visualice
para proporcionar interactivamente sus instrucciones sobre las mismas, de las
capacidades de visualización que sı́ poseen los ordenadores de sobremesa en
los que se ejecutan los browsers. Es decir, la navegación manual está prácti-
camente limitada a un conjunto muy particular de dispositivos (aquellos que
tengan instalado el browser contemplado por el sitio Web), mientras que la
navegación automática, al carecer de esas restricciones, puede llevarse a ca-
bo desde un número mucho mayor de dispositivos de acceso, como neveras,
asistentes personales, teléfonos móviles, set-top boxes ...
1.1.5. Adecuación de repositorios

Otro de los problemas con los que se encuentran las personas que navegan
con browsers es que la forma de recolectar los datos relevantes que van en-
contrando está basada en métodos poco automatizables, e inadecuados para
grandes volúmenes de datos, como la memorización, el apuntar los datos en
un papel, guardar toda la página a fichero, imprimirla para analizarla frente
a otras personas en una reunión, o, quizá en el mejor de los casos, el simple
copiar y pegar en la ventana de otra aplicación. Sin embargo, ni el papel,
ni la memoria humana, ni una ventana abierta de un editor de texto son
repositorios adecuados para almacenar los datos relevantes que se van extra-
yendo de las páginas cuando el volumen de datos empieza a ser considerable.
Por el contrario, desde el punto de vista de la automatización de tareas, es
deseable la utilización de repositorios de datos accesibles desde programas de
ordenador, como variables de memoria, ficheros con algún tipo de estructura
conocida por el programador o registros en una base de datos.
1.1.6. Procesamiento
Pese a que muchas veces el procesamiento que se debe realizar sobre los
datos del Web es realmente sencillo, (aunque ciertamente es posible que en
12
el futuro estos procesamientos se puedan volver cada vez más complejos), lo
cierto es que el volumen de datos que muchas veces hay que manejar en el
Web es demasiado alto como para ser manejado mentalmente por personas
delante de un navegador. Es fácil encontrar la versión más barata de un libro
en una página que tenga pocos ejemplares, pero ya no lo es tanto cuando se
desean comparar un gran número de listados de tiendas, cada una con sus
propios precios, de forma que haya que mezclar los resultados de todas ellas,
y calcular el gasto final incluyendo gastos de envı́o, descuentos especiales
o promocionales, o eliminando resultados repetidos. Realizar este tipo de
tareas es algo que puede fácilmente ser automatizado por un programa capaz
de acceder a los datos involucrados si éstos se encuentran convenientemente
almacenados en un repositorio adecuado de datos como los mencionados en
el punto anterior.
1.1.7. Coste de implantación y adaptabilidad

Todas las ventajas de la navegación automática frente a la navegación
manual tienen un coste. Desarrollar aplicaciones que automaticen las tareas
de navegación en el Web es costoso. Apenas existen técnicas especı́ficamente
orientadas a la reducción del coste de implantación de este tipo de progra-
mas. Buena parte de ellas puede encontrarse en el capı́tulo 3. Sin embargo,
cualquier mı́nimo cambio en la estructura de las páginas involucradas en
una tarea puede acabar requiriendo una ardua labor de mantenimiento. Por
el contrario, las páginas cuya estructura es frecuentemente actualizada, no
plantean excesivos problemas a las personas que las navegan manualmente
con browsers, pues el comportamiento humano es fácilmente adaptable a las
nuevas circunstancias, algo que no puede decirse normalmente del compor-
tamiento de los programas de ordenador. En el apartado 1.5 aparecen más
detallados estos costes.
1.2. Ejemplos de tareas costosas para la na-

vegación manual
Según aumentan las posibilidades de realizar nuevas acciones en un mundo
cada vez más interconectado, resulta cada vez menos difı́cil encontrar tareas
capaces de absorber horas de trabajo a sus usuarios o en las que se justifique
poco la conveniencia de que éstos deban estar presentes en todo momento
ante la pantalla del ordenador. A continuación figura una lista de posibles
13
tareas Web que reflejan los problemas:
Solicitar al Web de Hacienda el envı́o de datos fiscales de 100 perso-

nas. Actualmente esa labor se desarrolla rellenando un formulario en
un único paso, pero que debe ser rellenado y enviado una vez para ca-
da persona, introduciendo datos personales y fiscales de la declaración
anterior.
Publicar en eBay un catálogo de una tienda con 500 artı́culos en su-

bastas. Actualmente cada artı́culo requiere el rellenado del orden de
unos 8 ó 9 formularios, que aparecen en secuencia y que empiezan por
la selección del tipo de subasta y categorı́a en la que se desea publicar,
continúan preguntando por información especializada del artı́culo basa-
da en las selecciones anteriores, y acaban solicitando una confirmación
de que todo está conforme para el usuario. En algunos de los pasos ca-
be la posibilidad de que aparezcan variantes en la secuencia, como por
ejemplo los que se desprenden del hecho de que cada artı́culo pueda in-
cluir o no fotografı́a, por lo que para esos artı́culos puede ser necesario
rellenar un formulario aparte para enviar la foto al servidor. Además,
resulta deseable realizar una serie de mı́nimas comprobaciones en cada
paso, como el cercioramiento de que las tarifas que se pretenden cobrar
son las que el usuario espera, o que se confirme que cada artı́culo ha
sido efectivamente puesto en subasta (no hacer este tipo de compro-
baciones significa no tener garantizado el cumplimiento de la tarea).
El algoritmo de esta tarea consistirá en el rellenado en secuencia de
los formularios necesarios para la publicación de un artı́culo, contem-
plando las cuestiones mencionadas, de forma que esa secuencia figure
dentro de un bucle que itere sobre los artı́culos que se desea publicar,
presumiblemente leı́dos de algún repositorio definido por el usuario.
Buscar con Google cada semana las páginas de cierto tema, mantenien-
do para ello una lista acumulada de páginas ya conocidas que se res-
tará a los resultados obtenidos. De esta forma se presentará al usuario
una lista que contenga exclusivamente las direcciones hasta el momento
no conocidas por el usuario y que los robots de Google, en su continuo
devenir por la red, van descubriendo. En todo caso, los resultados que
se analicen de Google no deben comprender sólo la primera página de
resultados, sino que debe inspeccionar todas independientemente de la
paginación, filtrando de los resultados encontrados aquellos que apa-
rezcan en la lista de conocidos por el usuario. Dicha lista deberá residir
en un fichero en el ordenador del usuario, capaz de ser actualizado por
14
éste, pues Google, en su versión actual, no permite albergar este tipo
de información personalizada para cada usuario.
Componer un listado con los titulares de los principales periódicos cada

mañana. Los resultados podrı́an ser visualizados en una televisión co-
nectada a Internet mediante una set-top box que recoja los titulares de
varias fuentes de noticias del Web y las presente agrupadas al usuario
por secciones o según sus preferencias.
Buscar, desde una nevera conectada a Internet, la mejor oferta de leche

fresca en varias tiendas, incluyendo, a ser posible, no sólo la búsqueda
en tiendas habilitadas para neveras, sino en cualquier tienda que venda
a domicilio.
Ampliar la tarea anterior para que busque la tienda que pide menos
dinero por la entrega a domicilio de una cesta de la compra con varios
artı́culos, incluyendo los gastos de envı́o y descuentos aplicables de cada
tienda.
Chequear si, entre los mensajes en varias cuentas de correo Web (de
varios portales) hay algunos que cumplan ciertos requisitos, como remi-
tentes especiales o fechas o asuntos determinados. A cada uno de esos
mensajes, aplicarles ciertas acciones, como extraer de ellos los cuerpos
de los mensajes para ser leı́dos, cambiarlos de carpeta, responderlos,
reenviarlos a alguna dirección o simplemente borrarlos.
Mandar un SMS (Short Message Service) a una lista de teléfonos móvi-

les usando los formularios que para ello ponen accesibles algunos por-
tales del Web, a ser posible eliminando las restricciones que imponen
estos portales sobre tamaño de los mensajes y número de mensajes
enviados por unidad de tiempo.
Buscar en algún reconocido portal de ocio los restaurantes de una de-

terminada zona geográfica, seleccionar aquellos que sirvan comida a
domicilio y comparar sus ofertas.
Combinar la información de restaurantes de un portal de ocio (que indi-

que si aceptan tarjeta de crédito) con el callejero de la ciudad ofrecido
por otro portal para obtener un listado de restaurantes que acepten
tarjeta de crédito que estén cerca de la salida del cine al que voy a ir
esta tarde.
15
La mayorı́a de los ejemplos anteriores está pensada para automatizar un
elevado volumen de datos en una aplicación accesible desde el Web, como
puede ser una aplicación de recolección de datos de la Administración, un
buscador, una aplicación de publicación de subastas, una aplicación de envı́o
de mensajes a móviles o una que gestione cuentas de correo electrónico desde
el Web. En algunos casos, en lugar de acceder a una aplicación, la tarea
debe acceder simplemente a varias páginas de estructura conocida pero de
información variante, con el fin de combinar la información dispersa en esas
fuentes de la forma deseada por el usuario.
1.3. Tipos de programas de navegación auto-

matizada
Para conseguir automatizar tareas en el Web se necesita disponer de apli-
caciones que automaticen la navegación de los usuarios en páginas y apli-
caciones en el Web, de forma que sustituyan al usuario siguiendo alguna
secuencia de enlaces que deban seguirse y formularios que deban rellenarse
para poder realizar la tarea.
Los programas que pueden navegar en el Web pueden clasificarse según
su grado de particularización a las páginas Web que se espera que visiten.
Dicho criterio permite clasificar estos programas en tres grandes grupos:
1.3.1. Programas de navegación genérica no adaptada

Son programas que no están particularizados a ningún sitio Web y que,
por lo tanto, pueden ser usados en cualquiera de ellos. Normalmente se dedi-
can a solicitar interactivamente al usuario información acerca de qué enlaces
seguir (browsers), o bien a seguir todos los enlaces de un sitio Web para
realizar una tarea muy sencilla, normalmente idéntica en cada una de las
páginas encontradas, como por ejemplo, la indexación por palabras de cada
una de sus páginas (robots de buscadores), la comprobación de enlaces ro-
tos [126], la descarga completa de sitios Web [20] o el aviso de que ciertas
páginas han sido actualizadas recientemente [15]. Dado que estos programas
carecen normalmente de un contexto semántico (ver tabla 1.6) y por lo tanto,
son incapaces de particularizar su comportamiento al significado semántico
de los datos de las páginas visitadas, sólo pueden ser usados en tareas muy
sencillas, sin posibilidades de poder navegar de forma eficiente por el deep
Web [110, 105].
16
1.3.2. Programas de navegación genérica adaptada
Son programas que, siendo en principio utilizables en cualquier Web, ne-

cesitan meta-información acerca del mismo para poder navegarlo de forma
adaptada a sus caracterı́sticas particulares. Normalmente, suelen analizar pri-
mero la meta-información, expresada en términos declarativos, del sitio Web
para decidir mientras navegan qué enlaces tienen la mayor probabilidad de
llevar a la consecución de unos objetivos preestablecidos. El Web Semántico
[87] del W3C es un prometedor exponente de esta forma de automatización
de tareas en el Web.
1.3.3. Programas de navegación particularizada
Son programas totalmente particularizados a las peculiaridades de un si-

tio Web concreto, por lo que, en principio, no son reutilizables en otros sitios
Web. Estos programas, comúnmente denominados wrappers o código envol-
torio [70], presentan importantes ventajas, ya que no necesitan ningún tipo
de metadatos y pueden estar completamente adaptados a las caracterı́sticas
del sitio Web visitado. Mediante el seguimiento, particularizado al sitio Web,
de enlaces pre-programados estáticamente según la semántica que el progra-
mador implı́citamente refleja en el código de estos programas, prácticamente
casi cualquier tarea concebida por el usuario puede ser desarrollada de forma
eficiente, teniendo además en cuenta sus preferencias acerca de la forma en la
que desea que se lleve a cabo la tarea. Por ejemplo, para borrar el correo spam
en la bandeja de entrada de una cuenta de correo Web como el de Yahoo!, un
usuario puede querer marcar los correos de ciertos dominios que él considera
spam, para después pulsar en el botón de borrado, mientras que otro usuario
puede preferir seleccionar los mensajes con determinados asuntos moviéndo-
los a una carpeta temporal que será borrada posteriormente. Sin embargo,
este tipo de programas son muy costosos, tanto de desarrollar (debe imple-
mentarse uno para cada tarea), como de mantener (cualquier cambio en la
estructura de las páginas accedidas puede provocar un malfuncionamiento
del programa).
En la tabla 1.2 aparecen resumidas las principales caracterı́sticas de los
distintos tipos de programas que navegan por el Web según su grado de
adaptación a las páginas de esos sitios Web.
17
Genérica no adaptada Genérica adaptada Particularizada
Ejemplos Browsers, robots Web Semántico Wrappers
Algoritmo Usuario, fuerza bruta Guiado por objetivos Pre-programado
Contexto semántico Nulo Metadatos declarativos Implı́cito en programación
Construcción de caminos Usuario, todos Dinámica Estática, pero flexible
Implantabilidad Fácil Incipiente, a largo plazo Conocida y factible
Mantenimiento Ínfimo Fácil (declarativo) Costoso (programación)
Aplicable a cualquier Web Sı́ Si tiene metadatos No
Automatización de tareas MUY simples No complejas Sı́
Cuadro 1.2: Clasificación de programas que navegan por el Web según su

adaptación
Comparaciones de costes
Siempre que se permita al autor un par de pequeñas licencias literarias,

cabrı́a quizá comparar los distintos tipos de programas orientados a la nave-
gación en el Web con soluciones médicas que intentan paliar una enfermedad
en una persona y con la navegación marina.
Los programas genéricos no adaptados podrı́an asimilarse a los trata-
mientos médicos más sencillos, sin receta y con un bajo coste, y que todo el
mundo puede usar, como el hecho de beber agua, ingerir té verde o incluso
tomar una aspirina. Son éstas soluciones válidas y fácilmente aplicables pa-
ra problemas habitualmente comunes de encontrar. Los programas genéricos
adaptados podrı́an quizá asimilarse a una fisioterapia o a un tratamiento
medicinal con receta médica. Este tipo de soluciones está enfocada a una
finalidad más especı́fica que los tratamientos sencillos son incapaces de resol-
ver por sı́ mismos, por lo que se requiere normalmente la ayuda de alguien
externo capaz de facilitar la solución al usuario. Finalmente, los programas
no genéricos, esto es, los completamente particularizados, pueden ser com-
parables a una operación de cirugı́a. Este tipo de operaciones tiene un coste
sensiblemente superior al de otras alternativas, pero es realmente efectivo
cuando el problema del usuario no puede ser solucionado con las técnicas
anteriores.
De la misma forma, puede hacerse un sı́mil de la navegación en el deep
Web con los viajes en el mar. Una navegación basada en browsers puede ser
asimilada con un buzo, capaz de sumergirse con autonomı́a propia por cual-
quier recoveco marino por estrecho que sea, pero incapaz de recorrer grandes
distancias ni de llegar a grandes profundidades (además de estar frecuente-
mente orientada al ocio). Los robots son asimilables a los barcos, capaces de
18
recorrer grandes distancias en superficie, pero incapaces de navegar por el
deep Web rellenando formularios o siguiendo enlaces de profundidad poten-
cialmente ilimitada. La gran diversidad de robots según su complejidad es
asimilable a la gran diversidad de barcos existentes, desde pequeñas balsas
a transatlánticos, según su complejidad. En todos los casos, su navegación
está centrada en la parte más superficial del mar y nunca se sumergen en
el fondo del deep Web. La navegación con alternativas genéricas adaptadas
como la del Web Semántico es asimilable a varias alternativas, según el pun-
to de vista de sus promotores o sus detractores. Para los primeros, el Web
Semántico es comparable a un enorme submarino tripulado, capaz de auto-
matizar cualquier tarea a cualquier distancia y profundidad y con capacidad
autónoma (programación de agentes y de inteligencia artificial) para tomar
decisiones durante la navegación, pero incapaz de introducirse por los recove-
cos en los que no cabe, es decir, incapaz de navegar sin sus correspondientes
metadatos. Para sus detractores, sin embargo, el Web Semántico promete de-
masiadas cosas irrealizables aún hoy en dı́a, y es en realidad más asimilable al
uso de una red de transitables túneles construidos debajo del fondo del mar
(como el Eurotunel que atraviesa el canal de la Mancha). En ambos casos se
requiere la construcción de rutas de navegación (por las que quepa el subma-
rino) o transitables túneles adaptados al fondo marino, que sean asimilables
a los metadatos adaptados al sitio Web al que describen. Estos metadatos
actúan como guı́as de la navegación, indicando por dónde navegar y por
dónde no y cuál es el camino que hay que tomar en cada bifurcación para
llegar a un destino. Finalmente, cuando se necesita recorrer grandes distan-
cias, acceder a grandes profundidades e introducirse por pequeños recovecos
en los que no cabe un enorme submarino, y no se dispone de metadatos, lo
habitual es recurrir a soluciones como los pequeños batiscafos no tripulados
y teledirigidos, costosos, pero capaces de recorrer cualquier ruta. La tabla 1.3
contiene un resumen de estas comparaciones aclarativas.
Genérica no adaptada Genérica adaptada Particularizada

Ejemplos Browsers, robots Web Semántico Wrappers
Medicina Té verde, aspirinas, ... Medicación con receta, fisioterapia, ... Cirugı́a
Deep Web Buzo, barcos Red de túneles bajo el mar, submarino Batiscafo no tripulado
Coste Bajo Medio/alto Alto
Cuadro 1.3: Comparaciones aclarativas de alternativas de navegación según

coste
19
Las tareas que los usuarios necesitan automatizar en el Web pueden lle-
gar a ser bastante complejas. Sólo aquellos programas capaces de manipular
adecuadamente los datos que aparecen en los documentos visitados pueden
servir al usuario para automatizar sus tareas en el Web. Dado que la mayorı́a
de las tareas realizables por las aplicaciones de navegación genérica no adap-
tada son demasiado simples y que el Web Semántico es aún una tecnologı́a
realmente incipiente, la principal alternativa utilizable actualmente consiste
en la creación de programas de navegación particularizada a los sitios Web.
La navegación basada en wrappers ha sido sin duda la que más apor-
taciones ha realizado últimamente a la automatización de complejas tareas
en el Web, en donde ha demostrado en repetidas ocasiones ser aplicable de
forma fructı́fera [67]. Si bien los contextos semánticos (ver tabla 1.6) basa-
dos en metadatos declarativos pueden aún tardar tiempo en ser efectivos,
es constatable que los contextos semánticos embebidos en las sentencias de
programación que forman parte del código de un wrapper son una podero-
sa arma de automatización. Por otro lado, si bien la construcción dinámica
de caminos de navegación guiados por el cumplimiento de objetivos resulta
impracticable sin la existencia de metadatos, la construcción estática, pe-
ro flexible para ganar robustez, de caminos pre-programados de navegación
donde no sea necesaria la existencia de metadatos que indiquen los enlaces
que se deben seguir, puede servir como base para la automatización de tareas
que manejen aplicaciones accesibles desde el Web.
1.3.4. Modos de integración de aplicaciones Web

Cuando se desea automatizar tareas que involucran a más de una aplica-
ción Web, dos modos de integrarlas suelen ser los más empleados.
Integración de aplicaciones similares
Es normal encontrar aplicaciones de diversos servidores que, siendo

semánticamente similares porque están concebidos para fines parecidos, desde
el punto de vista del marcado de sus páginas, son estructuralmente distintas.
Normalmente, se trata de aplicaciones que, aunque pueden tener pequeñas
diferencias entre sı́, ofrecen una funcionalidad similar al usuario, cada una
accesible desde su propio servidor. Es por ello que el usuario puede tener
que conectarse simultáneamente a varias de ellas a la vez, escogiendo sobre
la marcha, qué acciones desea ejecutar en ciertas aplicaciones y qué otras ac-
ciones desea ejecutar en otras. Agentes de bolsa, personas con varias cuentas
20
de correo electrónico o con varias cuentas bancarias, personas que manejen
varios sitios de subastas en el Web o que quieran simplemente buscar las
mejores ofertas en varias tiendas suelen tener que abrir varias ventanas, una
para cada una de estas aplicaciones, y operar con todas ellas a la vez.
Integración de aplicaciones complementarias
Por otro lado, también resulta frecuente encontrarse con tareas que invo-
lucran el intercambio de datos entre varias aplicaciones construidas de forma
independiente unas de otras, pero que no estén integradas convenientemente,
por lo que la única forma de manejarlas sea manipulando los formularios pro-
pios de acceso a la herramienta. Ante esta situación, los usuarios tı́picamente
deben conectarse a alguna de ellas y, tras analizar los datos obtenidos de ésta,
enviar esos mismos datos, quizá con alguna variación, a otra herramienta, re-
llenando con el teclado y el ratón su correspondiente formulario. Eso suele
ocurrir en entornos donde, por ejemplo, una aplicación se dedica a recoger
peticiones de muchos usuarios y, antes de procesarlas convenientemente, un
supervisor debe darles el visto bueno, reinsertando esos datos en otra aplica-
ción junto con alguna información adicional. En ese caso, el supervisor, si las
herramientas no se han integrado convenientemente, puede tener que estar
copiando los datos de una ventana de la primera herramienta y pegándolos
en una ventana de la segunda herramienta. Otro ejemplo distinto, pero con
el mismo planteamiento operativo, se puede encontrar en personas que deban
enviar por alguna aplicación Web de correo electrónico determinados frag-
mentos de documentos que una primera aplicación les pueda estar mostrando
en otra ventana. Sin duda, las tareas realizables pueden llegar a ser cierta-
mente impensables para los diseñadores de las aplicaciones Web accedidas,
pues son los usuarios quienes mejor definen la forma en la que desean hacer
sus tareas. Por ejemplo, una persona puede desear responder desde el correo
que tiene en Yahoo! los correos electrónicos que le lleguen a su cuenta de
correo en Hotmail, porque no desee responder directamente desde allı́. En
este caso, los formularios de Yahoo! deberán recibir información, no sólo del
usuario, sino de la proporcionada por Hotmail, de la misma forma en la que
un usuario que realizara esa tarea hubiera copiado y pegado ese texto desde
la ventana de una aplicación a la ventana de la otra.
21
1.3.5. Sistemas mediadores
Los datos semiestructurados, que aparecen detallados en el apartado 1.4.7,

aunque primordialmente se encuentran en la inmensa multitud de páginas
HTML disponibles dentro de todo el Web, también pueden encontrarse con
frecuencia en abundantes fuentes de datos dentro de entornos corporativos
de tamaño mediano o grande. Precisamente por ello, son numerosas las em-
presas que presentan actualmente necesidades de poder integrar, no ya en un
único documento, sino quizá también en la toma de decisiones operativas de
la empresa, los datos provenientes de varias de esas fuentes de datos preexis-
tentes, de la misma forma en la que es necesario realizar tareas que combinen
la información obtenida de distintas fuentes en el Web.
Si bien es habitual que cada una de esas fuentes fuera desarrollada en
su momento con distintas tecnologı́as y objetivos, lo cierto es que la gran
mayorı́a de ellas fue concebida para ser accedida de forma que la información
resultante de cada una de ellas fuera a ser consultada directamente, bien
por personas, bien, en el mejor de los casos, pese a su enorme coste, por
otras aplicaciones capaces de realizar llamadas a una interfaz particular de
la aplicación. Las nuevas formas de negocio de hoy en dı́a y la necesidad de
manipular mucho más eficientemente grandes volúmenes de información de
fuentes muy diversas han contribuido ineludiblemente a una necesidad cada
vez mayor de que esas consultas a los antiguos sistemas aislados preexistentes
puedan estar ahora integradas en otras consultas realizadas por nuevos pro-
gramas capaces de combinar eficientemente la información que pueda estar
distribuida en varios repositorios independientes entre sı́.
De esta forma, los datos relevantes se pueden considerar como provenien-
tes de fuentes semi-estructuradas [66], esto es, con un formato reconocible
más allá del simple texto sin estructura, si se tienen en cuenta precisamente
combinaciones especiales de etiquetas de marcado que son capaces de iden-
tificar a los datos clave que deben extraerse de las páginas.
Un foco importante de investigación en la actualidad es la construcción de
sistemas capaces de integrar de manera sencilla datos semiestructurados he-
terogéneos y dispersos de múltiples fuentes accesibles por medios telemáticos
de forma que se obtenga de los mismos una visión similar a la proporcionada
por una única base de datos convencional. La idea de este enfoque consiste
en ocultar todo tipo de heterogeneidad de cada una de las fuentes de datos
accedidas de forma que al usuario se le proporcione una única visión global
de todo el sistema y pueda manipular cada uno de los recursos de la red
de una forma uniformizada, pese a que cada sistema trabaje en realidad de
22
forma distinta y tenga sus propias particularidades sintácticas. Los sistemas
Datawarehouse, basados en la replicación de información a un repositorio
común [68, 92] usados en entornos cerrados desde hace tiempo, no son ade-
cuadamente escalables para ser usados en el Web. Quizá la aproximación
arquitectural más utilizada hasta el momento para este tipo de sistemas sea
la de los sistemas mediadores [79, 101]. En ella, los datos permanecen en sus
fuentes originales y un sistema intermedio, llamado mediador, se encarga de
proporcionar a lo usuarios la ilusión de que existe una única fuente en la que
se encuentran todos los datos combinados y unificados de manera coherente
de acuerdo a un único esquema global. Cuando el mediador recibe una con-
sulta sobre el esquema global, ésta se reformula en diversas subconsultas que
se realizan directamente sobre las fuentes originales. La interacción directa
con las fuentes es delegada por el mediador a los llamados programas envol-
torio (o wrappers), cada uno de ellos especializado en el diálogo concreto con
cada servidor. Estos se encargan de recibir las peticiones del mediador, tra-
ducirlas como subconsultas ajustadas al formato particular de cada fuente,
ejecutarlas sobre la misma y obtener los resultados, devolviéndoselos al me-
diador. Es entonces cuando los resultados de las fuentes son reestructurados
por el mediador para ajustarse al esquema global y ser devueltos entonces al
usuario. De esta manera, éste obtiene la impresión de estar consultando un
único sistema. Este esquema se encuentra representado en la figura 1.1.
Figura 1.1: Sistema mediador
La motivación de la construcción de este tipo de sistemas se encuentra

tanto en los planes estratégicos a nivel corporativo dentro de una organiza-
ción, como a nivel de servicios utilizables por personas de forma individual.
Las organizaciones se encuentran, por un lado, con que su operativa genera
23
una cantidad de información enorme, que es difı́cil de gestionar, y a la que
es complicado, cuando no imposible, sacar el máximo partido. Por otro la-
do, diversos factores, como la rápida evolución tecnológica, las presiones del
mercado o el efecto de la competencia entre diferentes proveedores de solucio-
nes técnicas, han causado que los entornos y las tecnologı́as utilizadas para la
generación y manejo de estos datos difiera en gran medida a lo largo del tiem-
po, creando ası́, a lo largo de los últimos años, un escenario donde grandes
volúmenes de información se encuentra dispersa en fuentes independientes y
heterogéneas, cuyos datos necesitan ahora más que nunca ser combinados y
unificados. Son muchas las organizaciones que están desarrollando o tienen
planes de desarrollar sistemas capaces de proporcionar visiones unificadas de
los datos manejados por la organización.
Los problemas a los que los sistemas mediadores se han venido enfrentan-
do en los últimos años son extrapolables a la realización de muchas tareas
en el Web. Muchos de las aplicaciones construidas en las intranets de los
sistemas corporativos a lo largo de los últimos años han sido creadas con
interfaces para el Web. Es por ello que los sistemas mediadores se han visto
últimamente cada vez más abocados a la automatización de tareas en las
aplicaciones de las intranets de estas corporaciones. A pesar de que el núme-
ro de posibles tareas automatizables en el Web es mayor que las realizables
en las intranets de las aplicaciones corporativas, los sistemas mediadores,
impulsados por las necesidades de estas corporaciones, no han dejado de ser
un importante exponente de la necesidad de automatizar el tratamiento de
datos obtenible de aplicaciones accesibles desde el Web.
1.3.6. Asistentes de navegación Web
Para automatizar tareas en el Web se necesitan programas capaces de eli-

minar la necesidad de que el usuario deba interactuar incansablemente con el
ordenador durante la ejecución de la tarea. En lugar de solicitar que, durante
la navegación, el usuario active el seguimiento de cada enlace que se desea
visitar, se deben preprogramar todas esas activaciones en un algoritmo, de
forma que queden ası́ explı́citamente la selección preaprobada de los enlaces
que se seguirán durante la ejecución de la tarea. El resultado de ese algoritmo
normalmente consistirá en presentarle al usuario sólo los datos (resultados,
confirmaciones, ...) que a éste le interesan, evitando, en lo posible, mostrarle
toda aquella información irrelevante para su tarea. El programa capaz de
automatizar de esta forma las tareas del usuario conforme a sus intereses
se denomina asistente de navegación Web. En la figura 1.2 aparece es-
24
quematizada la diferencia entre la tradicional navegación manual basada en
browsers y la navegación basada en asistentes de navegación Web. Con un
asistente de navegación Web, se persigue sustituir al browser y al usuario que
lo maneja por un único programa capaz de automatizar una tarea de forma
que los servidores Web involucrados presten a la aplicación el mismo servicio
que prestarı́an a un usuario que realizara esa tarea con un browser.
Figura 1.2: Comparación de navegación manual con automática
1.4. Caracterı́sticas de los datos del Web

Para procesar datos automatizadamente hay que tener en cuenta las prin-
cipales caracterı́sticas de los datos cuyo tratamiento se pretende automatizar.
A continuación se presentan algunas de las principales caracterı́sticas de los
datos del Web.
1.4.1. Voluminosidad
En las últimas décadas las nuevas tecnologı́as han permitido la creación,

recopilación y publicación de grandes volúmenes de información accesible en
una amplia diversidad de formatos y mediante una amplia gama de medios
de acceso telemáticos. Por otra parte, muchas aplicaciones ya existentes en
las intranets de muchas organizaciones han sido reconvertidas para poder ser
accedidas ahora desde el Web, mediante un mayor número de terminales.
Esto ha llevado, por otra parte, a la aparición de un gran número de aplica-
ciones que, siendo accesibles desde cualquier punto del planeta mediante el
Web, a través de sus interfaces basadas en formularios, proporcionan al Web
una enorme cantidad de información para la que no existen apenas medios
adecuados de manipulación.
25
1.4.2. Heterogeneidad
El Web es un ente tremendamente heterogéneo, lo cual ha implicado una
gran dificultad a la hora de manejar adecuadamente los grandes volúmenes
de información dispersa en el Web. La proliferación de fuentes de informa-
ción desarrolladas de forma totalmente independiente unas respecto de las
otras ha llevado a un escenario en el que mucha información potencialmen-
te útil para las necesidades particulares de muchos usuarios esté dispersa y
almacenada según esquemas y estructuras de almacenamiento con grandes
heterogeneidades. Debido a la intrı́nseca naturaleza abierta en el Web, los
contenidos de la misma se muestran débilmente estructurados y, cuando lo
están, su esquema es enormemente heterogéneo, presenta irregularidades, y
sigue muy pocas restricciones. Otra peculiaridad del Web actual es el hecho
de que la inmensa mayorı́a de su información es legible para las personas,
pero no lo es para las máquinas, por lo que su tratamiento automatizado se
encuentra con importantes problemas. La heterogeneidad de las Webs de las
empresas supone aún mayores problemas cuando se las pretende interconec-
tar con las de sus clientes o proveedores u otros canales de comercialización.
1.4.3. Orientación a los visualización

Una de las grandes barreras a la automatización en el Web actual (no
tanto por los principios en los que se fundó, sino por el uso que se le ha
ido dando después) es que está muy orientado a la visualización. La gran
mayorı́a de los diseñadores no han concebido sus páginas para ser procesadas
por otro tipo de aplicaciones distintas a los browsers. Es más, tampoco resulta
extraño que algunos diseñadores hayan concebido sus páginas para que sean
navegadas exclusivamente desde ciertos browsers concretos, excluyendo,
en ocasiones sin saberlo, en otras intencionadamente, la navegación de otros
tipos de programas como las que aparecen en la tabla 1.2.
La actual orientación a la visualización en el Web no es un problema
en sı́ mismo para la accesibilidad si esa orientación está basada en hojas
de estilo. Sin embargo, quizá porque las hojas de estilo nacieron algo más
tarde que el propio Web y aún no tienen un soporte completo en muchas
herramientas, tradicionalmente las páginas han reflejado su orientación a la
visualización en el propio marcado HTML de sus páginas. La gran mayorı́a de
los sitios Web actuales centran aún el uso de su marcado HTML en aspectos
primordialmente visuales (tamaños y tipos de letra, colores, alineamientos,
espaciados, distribución por la pantalla, imágenes, ...), muchos de ellos en-
focados para impactar visualmente al usuario que use uno de los browsers
26
gráficos admitidos por el diseñador del sitio Web.
A pesar de que iniciativas como las de las hojas de estilo CSS bien permi-
ten independizar a HTML de esa orientación a la visualización, buena parte
del marcado HTML que se usa en las páginas de millones de aplicaciones
accesibles desde el Web, creadas a lo largo de los últimos años, está aún
orientado a estos fines. Ası́, en lugar de un Web en la que cualquier página
HTML pueda ser navegable desde cualquier browser y dispositivo de acce-
so, donde las distintas peculiaridades de cada uno estén contempladas en
distintas hojas de estilo, cada una de ellas adaptada a un tipo distinto de
terminal, el Web actual adolece de un grave problema de orientación a un
reducido número de browsers, puesto que los usuarios que utilizan otros ti-
pos de programas de acceso distinto a esos browsers, no tienen un adecuado
acceso a los contenidos que desean visitar. Para muchos usuarios, son muchas
las páginas inaccesibles, donde determinados contenidos dejan de ser visibles
y muchas aplicaciones accesibles desde el Web dejan de ser funcionales sim-
plemente por el hecho de que se acceda a ellas con browsers no considerados
por el diseñador del sitio Web.
Por ejemplo, resulta habitual el hecho de que se visualicen enlaces que sin
embargo no se pueden pulsar (tienen una capa invisible encima que lo impi-
de), textos que quedan ilegibles por aparecer superpuestos unos sobre otros,
o incluso servidores que, siendo en realidad visitables, discriminan según el
agente de usuario empleado y acaban redirigiendo a la portada del Web o a
una página de error en la correspondiente respuesta a toda petición en la que
no se acompañe la identificación del browser esperado en ese Web. En muchos
sitios, la navegación basada en browsers sobre terminales tipo texto, como
Lynx [10] resulta impracticable. Incluso la navegación basada en browsers
gráficos resulta impracticable en muchos sitios Web si no se tiene activada
alguna funcionalidad especial que el diseñador del sitio Web consideró como
necesaria, como son las cookies, las rutinas JavaScript [74], las imágenes, o
las animaciones en Flash u otros formatos. A ello hay que añadir la escasez
práctica de descriptores textuales adecuados en numerosos componentes de
las páginas, como los scripts, los applets, los plugins, los frames o los contro-
les ActiveX, muchos de los cuales sólo resultan funcionales en determinados
browsers, pero no en otras aplicaciones.
Accesibilidad
Iniciativas de mejora para la accesibilidad, como las publicadas por el

W3C en sus recomendaciones [128, 137, 136], están encontrando últimamen-
27
te un decidido apoyo en numerosas personas e instituciones para conseguir
que el acceso a los contenidos Web sea funcional con independencia de cual
sea la plataforma de acceso, tanto hardware como software. Estas recomenda-
ciones últimamente hacen especial hincapié en poco costosas, pero efectivas
mejoras de acceso al Web por parte de, tanto browsers especı́ficos usados
por personas discapacitadas, como los recientes terminales inalámbricos con
pantallas de reducidas dimensiones y escasa capacidad de procesamiento o
ancho de banda limitado, tales como teléfonos móviles, asistentes personales
o pequeños electrodomésticos. La correcta operatividad con independencia
del browser utilizado o del dispositivo de acceso escogido es una de las gran-
des necesidades del Web actual. Últimamente, el cada vez mayor número de
formas de acceso ha puesto aún más de manifiesto el serio problema de acce-
sibilidad existente en el Web, como lo demuestra el hecho de que los nuevos
dispositivos sean incapaces de acceder adecuadamente a las páginas del Web
legado. Este problema ha permanecido disimulado por el importante domi-
nio de Microsoft Internet Explorer como browser más utilizado en los últimos
años. No obstante, numerosas iniciativas de mejora, como las del W3C y otras
[109, 106, 96, 121] han sido propuestas para aportar soluciones. Dentro de las
recomendaciones del W3C se enumeran varios tipos de programas de navega-
ción, mucho más allá de los habituales browsers gráficos. El objetivo de estas
recomendaciones es la de permitir el correcto acceso al Web desde terminales
en modo texto, software especı́fico de navegación para personas con visión
discapacitada que presentan al usuario las páginas en Braille o en audio,
ası́ como desde terminales de reducidas dimensiones, con pequeños displays
como los cada vez más habituales dispositivos inalámbricos, y muchos más.
El objetivo principal de estas iniciativas consiste en que las páginas pu-
blicadas en el Web sean accesibles a sus usuarios independientemente del
dispositivo de acceso empleado por cada uno de ellos. Una de las ideas prin-
cipales de estas iniciativas de mejora consiste en reducir al mı́nimo el uso del
marcado HTML que esté orientado a la visualización, delegando esa tarea en
las hojas de estilo y simplificando ası́ el marcado estructural de las páginas.
En la tabla 1.4 pueden contemplarse las principales diferencias entre las dis-
tintas versiones de HTML surgidas en los últimos tiempos, desde los puntos
de vista de la orientación a la visualización y a la accesibilidad.
Resulta curioso destacar en este punto cómo los sitios Web que más éxito
han cosechado en los últimos tiempos (Google, Yahoo, eBay, EasyJet ...)
suelen tener como caracterı́stica común el hecho de que no hacen apenas
28
HE = Hojas de estilo HTML sin HE HTML con HE XHTML o XML
Orientación a la visualización En HTML En hoja de estilo En hoja de estilo
Accesibilidad por terminales Baja Media Alta
Regularidad estructural Orientación visual Sencilla Sencilla
Modificaciones en la estructura Habituales Escasas Ínfimas
Reglas de construcción Básicas Básicas Tipo de documento
Automatización de tareas Difı́cil Media Fácil
Difusión relativa en el Web Alta Baja Muy baja
Cuadro 1.4: Principales diferencias entre las últimas versiones de HTML
uso de tecnologı́as que mermen la accesibilidad de sus páginas. Sin embargo,

la escasa implantación práctica de las normas y recomendaciones del W3C
durante muchos años hace prever que la transición hacia un Web accesible
para browsers de distintos terminales será aún lenta, en cuanto a la inercia del
Web está asentada en su gran tamaño y en la tradicional escasa orientación
de diseñadores y herramientas a estos aspectos. La orientación del Web a
los browsers como únicas herramientas de acceso es la razón de que el Web
sea aún muy abundante en páginas que no sólo no cumplen las reglas de la
recomendación oficial de XHTML, sino que ni tan siquiera cumplen muchas
de las reglas de las recomendaciones anteriores de HTML.
1.4.4. Relevancia dependiente de la tarea

Por datos relevantes se debe entender, no sólo aquella información es-
pecı́fica que está siendo buscada y que forma parte de los resultados que,
quizá tras algún procesamiento, se le deben proporcionar al usuario al finali-
zar la tarea, sino, en general, todos aquellos datos que puedan ser utilizables
en algún momento dentro de ese proceso de navegación. Ejemplos de datos
relevantes son las direcciones de las páginas que se deben visitar, los campos
de formularios que se deben rellenar, o quizá incluso simples campos que apa-
recen en las páginas en función de cuyos valores se puede tomar la decisión
de seguir uno u otro enlace o efectuar una u otra acción definible por el usua-
rio. No toda la información de cada página Web es igualmente relevante. Es
común que, para una tarea particular, de una sola página apenas interese un
dato, un determinado enlace o un formulario concreto y los demás datos de la
página puedan ser felizmente ignorados. La relevancia de cada información,
por otra parte, no se puede considerar en términos absolutos. La relevancia
de un dato depende de la tarea concreta que se desee realizar, es decir, de los
objetivos por los cuales la página que contiene el dato ha sido consultada.
29
Por ejemplo, dentro de un mismo documento, para una tarea concreta, pue-
de ser interesante un enlace, mientras que para otra tarea, puede serlo otro
enlace completamente distinto. Para ciertas personas, determinada informa-
ción puede ser considerada como relevante, mientras que, para otras, pese a
que tengan propósitos similares, esa misma información puede no serlo. En
cualquier caso, dicha información, relevante o no, es presentada al usuario
tı́picamente embebida en páginas Web que, estando escritas en HTML para
su visualización en browsers, no están, sin embargo, orientadas para ser pro-
cesadas por otro tipo de aplicaciones capaces de manipular esa información
automáticamente. Es decir, las páginas HTML están construidas para ser vi-
sualizadas, pero no para ser comprendidas por máquinas. El problema de la
integración de datos del Web en aplicaciones, esto es, de su automatización,
ha sido abordado de manera muy activa por investigadores de diferentes co-
munidades y disciplinas, tales como la Telemática, la Minerı́a de Datos o la
Inteligencia Artificial, realizándose en los últimos años importantes contri-
buciones desde diferentes puntos de vista.
1.4.5. Regularidad estructural
Las bases de datos, que almacenan su información de forma estructurada,

al volcar sus contenidos en páginas Web, suelen conservar en ese volcado
cierta regularidad, denominada estructural, en el marcado HTML de los datos
volcados. Distintos datos conviviendo bajo la misma férrea estructura de una
base de datos acaban siendo volcados al Web con similares etiquetas HTML,
por lo que conservan una cierta regularidad estructural en sus marcados. Un
ejemplo de ello puede verse en la figura 1.3, donde se muestra parte del código
de una página Web que contiene los resultados de una búsqueda en Google.
El hecho de que exista una regularidad estructural en las páginas HTML
publicadas en un mismo servicio (aplicación accesible desde el Web o con-
junto de páginas lógicamente enlazadas para un fin común y publicadas bajo
una misma estructura) tiene un inmenso valor para la extracción de datos
del Web. La regularidad estructural puede ser usada para identificar unos
datos respecto de otros. Sin embargo, el hecho de que dicha estructura no
sea explı́cita (como sı́ lo es el esquema de una base de datos), sino implı́cita,
permite que los sitios Web puedan cambiar en cualquier momento sus estruc-
turas de marcado HTML sin apenas contemplaciones. Además, la estructura
supuestamente regular de los sitios Web puede presentar irregularidades con
frecuencia. Por ejemplo, es habitual que en el catálogo electrónico de una tien-
da todos los artı́culos contengan datos como precios, descripciones o marcas,
30
Figura 1.3: Regularidad en el Web
pero puede ocurrir que algunos pocos de esos artı́culos vengan acompañados
además de un indicativo promocional de oferta, que otros artı́culos no poseen.
Es precisamente la posibilidad que HTML ofrece para realizar múltiples y fle-
xibles combinaciones de marcado de sus etiquetas sin apenas restricciones,
una de las razones por las que el Web de hoy en dı́a resulta tan heterogéneo a
simple vista, pese a que los principios de su funcionamiento sean en realidad
sencillos. Es precisamente esa combinación de sencillez y flexibilidad, caren-
tes en el mundo de las bases de datos, una de las principales razones que han
encumbrado a HTML como el formato por excelencia de los documentos en
el Web.
Reconocer esta regularidad estructural en una página permite extraer sus
datos relevantes. Existe una gran necesidad actualmente de aplicaciones que
puedan integrar la información semiestructurada de varias fuentes diversas
preexistentes. La heterogeneidad de la forma de marcar datos en cada fuente
hace necesario muchas veces un pretratamiento particularizado consistente
en adaptar los datos provenientes de diversas fuentes a un formato común.
Una vez estructurados todos los datos en un formato común, éstos pueden
ser procesados adecuadamente sin tener en cuenta su procedencia. Esto suele
ser necesario en procesos de integración de información proveniente de dis-
tintos servidores cuya forma de acceso no es posible que sea modificada. Ello
31
suele ocurrir muchas veces en el Web en general, o, a menor escala, en los
servidores localizados en la intranet de una empresa, donde es primordial
que los sistemas sigan funcionando para las personas y herramientas que los
llevan usando sin necesidad de ser interferidos por el hecho de que una nueva
herramienta de acceso se incorpore al sistema informático preexistente.
1.4.6. Ausencia de semántica en el marcado

Cualquier dato que aparezca en una página HTML no puede distinguirse
fácilmente de forma automatizada. Por ejemplo, un dato numérico, no puede
reconocerse fácilmente como un precio, una cantidad, una fecha o un número
de referencia por la sencilla razón de que en el marcado HTML del Web
actual no se distingue entre unos tipos de datos respecto de otros. Por otro
lado, prácticamente casi cualquier combinación de etiquetas HTML puede
usarse indistintamente para marcar unos datos u otros, razón por la que
acaba siendo el usuario quien, aplicando sus conocimientos contextuales en
la navegación, infiere la semántica de esos datos al visualizarlos en la pantalla.
Esto es algo que ocurre cuando se navega con un browser. En la navegación
manual se debe tomar muchas veces la decisión de pulsar en uno u otro enlace
o la de rellenar un formulario en lugar de otro, o la de rellenar cierto campo de
una forma en lugar de cierta otra dependiendo de los datos visualizados hasta
el momento en la pantalla, pero que el ordenador no es capaz de distinguir
respecto del resto de los datos visualizados porque HTML es un lenguaje
de marcado poco orientado a la descripción semántica y con un uso muy
orientado a la visualización.
1.4.7. Niveles de estructuración

Tradicionalmente, en el campo de la documentación, se ha distinguido en-
tre datos estructurados y datos no estructurados. Los datos no estructurados
son aquellos que no presentan ningún esquema o estructura más allá de la
mera secuencia de bytes o palabras. Los datos estructurados son aquellos que
siguen un esquema de datos perfectamente definido (e.g. aquellos contenidos
en bases de datos). El esquema que define la estructura de un conjunto de
datos estructurados suele incluir férreas restricciones sobre los mismos, tales
como un fuerte tipado de datos, restricciones en los rangos posibles de valo-
res admitidos para ciertos datos, unicidad, cardinalidad de las repeticiones,
limitaciones en el tamaño o posibilidad de impedir la existencia de campos
con valores nulos.
32
Datos no estructurados
Un ejemplo tı́pico de datos no estructurados son los textos libres. Debi-

do a su escasa o prácticamente nula estructura, la única manera posible de
recuperar información de estos documentos es mediante consultas no estruc-
turadas o imprecisas, tales como las búsquedas por palabra clave. Con este
tipo de consultas sólo es posible representar expresiones que recuperen aque-
llos documentos en los que aparece el conjunto de palabras clave buscadas. Es
habitual en este tipo de consultas la posibilidad de utilizar operadores lógicos
para combinar expresiones simples. Básicamente, éste es el sistema de datos
en el que se basan los buscadores de Internet como Google o Altavista.
Si bien este tipo de consultas son sencillas de realizar y existe un gran
número de trabajos e importantes contribuciones a este respecto [28], lo ha-
bitual es que este tipo de soluciones trabajen con un nivel de granularidad
demasiado grueso (el documento), frente a lo que muchas veces en reali-
dad se necesita (el dato). Los muy bien conocidos buscadores como Google
o Altavista consideran el Web como un gran repositorio de información no
estructurada y son capaces de construir gigantescos ı́ndices sobre el Web,
permitiendo su consulta de forma eficiente. Sin embargo, para un cada vez
mayor número de usuarios que encuentran la necesidad de realizar consultas
más especializadas, esta abstracción del Web como un conjunto de informa-
ción no estructurada es demasiado débil, ya que, a fin de cuentas, no sirven
para nada más que para localizar documentos que tengan las palabras con-
sultadas, no para obtener el dato en sı́ que en realidad buscan, ni tampoco
para automatizar el uso de aplicaciones manejables desde formularios.
Datos estructurados
Los datos estructurados son aquellos que presentan un esquema rı́gido

y bien definido para los datos. Un ejemplo tı́pico de fuente estructurada de
datos son las bases de datos relacionales. En este caso existe un diccionario
de datos que define la organización interna y las restricciones de los datos,
ası́ como de las relaciones entre los mismos. Cuando los datos se encuentran en
forma estructurada, es posible realizar consultas precisas mediante lenguajes
de consulta estructurados, de los cuales el más popular es SQL [78]. Esta
precisión a la hora de hacer consultas hace que los datos estructurados sean
muy adecuados para su tratamiento por programas de ordenador.
33
Datos semiestructurados
Al contrario de los datos estructurados, los datos del Web carecen de todas
estas restricciones y pertenecen a una categorı́a distinta. Esa categorı́a de
datos ha recibido el nombre de datos semi-estructurados [36]. Los datos semi-
estructurados se caracterizan porque, aunque siguen algún tipo de esquema,
el seguimiento que hacen del mismo es mucho menos rı́gido que en el caso
de los datos estructurados. Según [60], las principales caracterı́sticas de los
datos semiestructurados son:
El esquema de datos no es explı́cito, esto es, no es conocido de ante-

mano. Puede existir, pero estará, en todo caso, implı́cito en los datos y
cualquier restricción asumible de ese esquema deberá inferirse de ellos
de alguna manera.
El esquema de datos está sujeto a cambios y puede cambiar con frecuen-

cia. No existen impedimentos para que esto pueda ocurrir en cualquier
momento.
El esquema tolera irregularidades que no siempre aparecen especifica-

das.
No existe un tipado fuerte de los datos individuales, por lo que es posible

encontrar en ocasiones valores de tipos diferentes a los esperados. Por
ejemplo, para un mismo tipo de dato consultado, es posible que éste
aparezca en varios formatos distintos.
Sin tener la programabilidad de una férrea base de datos en la que es fácil

asumir decisiones semánticas acerca de los datos, su bajo coste de creación
las ha convertido en poco tiempo en la alternativa usada por excelencia para
la publicación de datos en el Web. Sin embargo, la gran mayorı́a de la in-
formación accesible por el Web no presenta un nivel de estructuración tan
fuerte, pese a que serı́a deseable poder manipularla eficazmente. En muchas
ocasiones, especialmente en el caso de bases de datos accesibles desde el Web,
la estructura de marcado HTML en la que esos datos se ven incrustados ha-
ce perder fácilmente la visión de esa estructura férrea. HTML es un buen
formato para ser visualizado en navegadores. Sin embargo, su estructura no
está orientada a la descripción de los datos, sino a su visualización. Ténga-
se en cuenta, que en el proceso de transformación de la información desde
repositorios estructurados a formatos visualizables, se produce una pérdida
de estructuración que, a lo largo de los últimos años, las diversas aplicacio-
nes que volcaban al Web los contenidos de las bases de datos, han venido
34
produciendo sin demasiados reparos. Es ahora, con un Web lleno de con-
tenidos inmanejables eficazmente, cuando los métodos para reestructurar la
información del Web son más necesarios.
HTML es el lenguaje de marcado en el que se encuentran embebidos
mayoritariamente los datos del Web. Apenas los Web Services [53] y unos
pocos y marginales (comparativamente con el inmenso tamaño del Web)
segmentos de negocio usan XML como formato de intercambio de datos.
Algunos más son los sitios que aparecen publicados en XHTML [117]. Muy
al contrario de los documentos XML, las páginas HTML se caracterizan
porque su estructuración está atada a muy pocas reglas. La gran mayorı́a
de ellas son reglas elementales de construcción, sin que las reglas lógicas de
estructuración propias del ámbito de conocimiento del documento queden
bien reflejadas en su marcado estructural. Este marcado, por el contrario,
sı́ suele contener una elevada carga de aspectos orientados a la visualización.
Esta débil estructuración de las páginas puede ser cambiada fácilmente en
cualquier momento, pues no existe un esquema de datos explı́cito que deba
regir la estructura de las páginas. Por todos estos motivos, los documentos
HTML pueden ser considerados como datos semiestructurados.
La tabla 1.5 presenta un resumen de las principales diferencias entre las
caracterı́sticas de los datos según sus distintos niveles de estructuración.
Datos no estructurados Datos estructurados Datos semi estructurados

Esquema de datos Inexistente Explı́cito Implı́cito
Restricciones Inexistentes Férreas Laxas
Irregularidades Inexistentes Prohibidas Abundantes
Cambios de estructura Inexistentes Prohibidos Habituales
Consultas Imprecisas Precisas Poco precisas
Ejemplo Texto plano Base de datos Página Web
Coste de creación Bajo Alto Bajo
Uso Medio Bajo Muy alto
Cuadro 1.5: Diferencias entre caracterı́sticas de los datos según su nivel de

estructuración
1.4.8. Distribución de la información

Los datos que aparecen en el Web y son necesarios para una tarea no
suelen aparecer todos integrados en un mismo documento, sino que suelen
35
aparecer distribuidos en varios de ellos por cuestiones organizativas. Ası́ pues,
información que necesita ser combinada para realizar una tarea puede encon-
trarse distribuida de muy diversas formas:
Entre los documentos de diversos sitios Web, como por ejemplo in-
formaciones complementarias de restaurantes en distintos portales de
ocio.
Entre los documentos individuales integrantes de otros documentos
multimedia, como por ejemplo las diversas páginas que formen un mis-
mo frameset.
Entre diversas páginas enlazadas entre sı́, como por ejemplo, los deri-
vados de la paginación de resultados de búsqueda.
Mezclada dentro de una misma página con información no relevante
para la tarea, como por ejemplo, la publicidad y otras informaciones
no relevantes para la tarea.
1.4.9. Difı́cil modificabilidad

Los programas creados para navegar automáticamente en el Web, de-
ben, por lo tanto, afrontar el problema del manejo de información semi-
estructurada, corriendo el peligro de ver modificada, sin previo aviso, la es-
tructura de las páginas que se desea visitar. En el caso de la integración
de aplicaciones accesibles desde el Web, éstas deben ser tratadas con su-
mo cuidado y respeto para no interferir en el correcto funcionamiento de
las tareas realizadas por otros mecanismos, tı́picamente browsers, que otros
usuarios estén llevando a cabo. La mejor forma de integrar estas aplicaciones
legadas suele consistir, no en modificarlas para que contemplen una nueva
herramienta de acceso, sino en usar las interfaces que ya tengan desarrolla-
das, tı́picamente formularios en formato HTML, creando herramientas que
emulen las herramientas de acceso preexistentes que hasta el momento han
estado siendo usadas. En muchas ocasiones ello supone, si no un serio ahorro
de costes, la única opción aplicable.
1.4.10. Aportaciones de XML

XML [132], concebido como una tecnologı́a para definir lenguajes de mar-
cado propios para cada campo del conocimiento, aporta numerosas y signi-
ficativas soluciones a la hora de estructurar los documentos de una forma
36
mucho más clara que la manera en la que HTML lo permite actualmente.
Gracias a su mayor expresividad, y a su facilidad para ser procesado por pro-
gramas no orientados a la mera visualización, el uso de XML se ha extendido
rápidamente como solución al intercambio de datos estructurados en muy
diversos ámbitos. Las principales cualidades de los documentos XML son las
siguientes:
Sintaxis fácilmente procesable
XML presenta una sintaxis textual muy simplificada que permite estruc-
turar fácilmente los documentos en forma de árbol. Al contrario de su pre-
decesor SGML [65], los programas que procesan XML pueden ser muy fácil-
mente construibles debido a la simplicidad del formato, algo que sin embargo
no le resta flexibilidad y extensibilidad para poder definir documentos com-
plejos.
Independencia de la presentación
XML permite dotar fácilmente a los documentos de una estructura

sintáctica que esté adecuada a la naturaleza propia del documento, pres-
cindiendo absolutamente de la forma en la que éste pueda ser visualizado,
labor que queda delegada en las hojas de estilo.
Estructuración de datos
Las etiquetas XML no definen propiedades acerca de cómo deben ser

visualizadas, sino que simplemente describen los datos que contienen. Con el
fin de dar una descripción formal a los posibles contenidos que puede tener
una etiqueta dentro de un documento, XML incluye la posibilidad opcional
de describir esas sintaxis mediante los DTD o XML Schema.
Contexto semántico
Algo que no forma parte de la especificación de XML y para lo que aún

no se ha definido formato estandarizado de representación es el contexto
semántico. Mediante un contexto semántico capaz de dotar de significados
a cada una de las partes de esa estructuración sintáctica (etiquetas y atri-
butos XML), es posible ası́ que cada uno de los datos que aparecen en un
37
documento pueda tener significado semántico para los usuarios. De esta for-
ma, las distintas partes de los documentos pueden presentar un significado
conocido y sin ambigüedades, adecuado para ser entendible por las máquinas,
algo que las páginas HTML que forman parte del Web actual no cumplen,
pues están orientadas a la mera visualización. La tabla 1.6 refleja un resumen
de las aportaciones que realiza cada una de las tecnologı́as mencionadas en
este párrafo a los documentos estructurados en XML.
Tecnologı́a Aporta Finalidad Herramientas

XML Sintaxis Datos descritos DTD, Schema, Relax-NG, ...
Hojas de estilo Presentación Documentos presentables CSS, XSL, ...
Contexto semántico Semántica Documentos procesables Metadatos RDF/OWL, programas ...
Cuadro 1.6: Resumen de aportaciones de XML
Sin embargo, siendo XML una buena opción, lamentablemente aún no es

usada masivamente en el Web. Para ello resulta necesario un cierto consenso
a la hora de escoger el lenguaje concreto de entre los múltiples lenguajes
existentes de un dominio de conocimiento para marcar adecuadamente los
contenidos. Por otro lado, lo cierto es que XML apenas resuelve una parte
del problema: la de la estructuración de los documentos y la posibilidad de
asociar, gracias a un contexto que suele estar implı́cito en las personas, sig-
nificados semánticos a cada una de esas partes estructuradas del documento.
Sin embargo, XML no realiza aportaciones a la forma en la que esos docu-
mentos deben ser obtenidos de las fuentes de datos, algo que normalmente
no se puede conseguir en un solo paso.
Sin embargo, al igual que ocurre con la orientación a la accesibilidad e
independencia del dispositivo de acceso, son numerosos los inconvenientes que
permiten augurar que XML aún tardará mucho tiempo en ser una solución
efectiva. Entre esos inconvenientes cabe destacar los siguientes:
El uso de XML directamente en los browsers, como mero formato de

visualización, acompañado, eso sı́, de sus correspondientes hojas de
estilo, no aporta ventajas sobre otros formatos para los que ya existen
browsers, como HTML.
El ya gigantesco tamaño del Web supone sin duda una gran inercia a
la hora de acoger nuevas tecnologı́as. Ello implica que, aunque en de-
terminado momento, XML pase por fin a ser la solución comúnmente
38
aceptada por los servidores Web, la lentitud con la que se reajustarán
las páginas de los servidores Web ya existentes implicará que el acceso
a sitios Web basados en HTML seguirá siendo necesario durante mucho
tiempo. Y aún ası́, no es previsible tampoco que HTML llegue a desa-
parecer por XML, por lo que habrá un gran número de aplicaciones que
no migrarán a XML. En cualquier caso, en la actualidad, tras cuatro
años después del nacimiento de XML, éste apenas se encuentra usado
en unos pocos segmentos verticales de negocio, de una forma marginal
si se lo compara con HTML.
El hecho de que las especificaciones del W3C que parecen prometer

nuevas soluciones estén aún en fase de borrador supone un serio incon-
veniente para ser adoptadas por los desarrolladores, que las contemplan
aún con muchas reticencias.
1.5. Coste de la navegación automatizada

Uno de los aspectos más curiosos para la automatización de tareas en el
Web es que la mayorı́a de las mejoras de accesibilidad mencionadas en el
apartado 1.4.3 en lo referente a la independencia de dispositivos de acceso
en la navegación con browsers, son también directamente aprovechables para
otras aplicaciones que no son browsers, como las de navegación automática.
Un marcado poco orientado a los aspectos de visualización, que delegue esa
labor en hojas de estilo, independiente del dispositivo de acceso, y cercano a
la estructura lógica del documento, es más simple y regular y menos proclive
a ser modificado con el tiempo, pues serán las hojas de estilo quienes asuman
los cambios de presentación. Ello redunda en una importante minimización
de costes, tanto de publicación en el lado del servidor como de procesamiento
en el cliente que manipule las páginas obtenidas del servidor.
En el lado del servidor, la opción de mantener documentos accesibles, cada
uno de ellos visualizable con varias hojas de estilo alternativas, cada una de
ellas a su vez orientada a un dispositivo de acceso, será sin duda mucho más
económica (en tiempo, espacio y esfuerzo a largo plazo) y escalable que la de
mantener para cada página una versión orientada a cada terminal.
En el lado del cliente, la simplicidad del marcado de las páginas accesibles
reduce sensiblemente la complejidad de procesamiento. Esto tiene especial
importancia en las reglas de extracción de datos basadas en la regularidad
estructural de las páginas. Al ser esta regularidad estructural más simple y
más estable, estas reglas serán a su vez más simples y estables, por lo que
39
necesitarán un menor esfuerzo de desarrollo y de mantenimiento.
Las aplicaciones capaces de navegar en el Web que aparecen en el aparta-
do 1.3 pueden, sin duda, ser construidas desde varias plataformas basadas en
distintos lenguajes de programación. Desde C, Java, Perl, TCL-TK, Prolog,
Visual Basic hasta el mismo ensamblador, cualquiera de estos lenguajes puede
ser usado en la construcción de estos sistemas, habida cuenta de la existencia
de varias bibliotecas de soporte utilizables en cada uno de estos lenguajes,
como las mencionadas en el apartado 3.4. Sin embargo, no todas las alterna-
tivas presentan la misma flexibilidad para cada labor, ni tampoco tienen los
mismos costes, soliendo haber unos lenguajes más orientados que otros para
cada tipo de labor. Para minimizar los costes, es necesario que la plataforma
de ejecución proporcione un buen soporte al acceso de datos en el Web por
el protocolo HTTP, emulando lo más parecidamente el comportamiento de
un browser y ejecutando la mayor cantidad de acciones que implı́citamente
éste ejecuta, algunas de las cuales aparecen en el apartado 2.1, como por
ejemplo que éste sea robusto en los fallos que ocasionalmente ocurren en las
comunicaciones (sobrecarga en la conexión, tiempo de respuesta excesivo en
el servidor, ...), enlaces rotos a componentes del documento, y que permita
ubicar fácilmente los errores cuando éstos se produzcan, para ayudar a una
más rápida reparación del código de la aplicación. Desde el punto de vista del
programador, la plataforma de ejecución debe proporcionarle además un API
de desarrollo con el adecuado nivel de abstracción, la posibilidad de añadir
sus propias medidas de robustez ante inesperados comportamientos del ser-
vidor (páginas de error, cambios de regularidad estructural, ...) y, sobre todo,
una sencilla forma de definir para fuentes de datos semiestructuradas, reglas
de extracción de datos, sencillas, potentes y fáciles de mantener, pues suelen
ser la parte que más suele sufrir ante los inevitables cambios en la regula-
ridad estructural de las páginas. Los costes de la navegación automatizada,
que aparecen resumidos en la tabla 1.7, pueden separarse en tres grandes
grupos:
Coste Necesidad Para programador Para plataforma

De desarrollo Buen API Buen nivel de abstracción Buen soporte acciones implı́citas
De ejecución fallida Robustez Ante cambios o fallos del servidor En comunicaciones
De mantenimiento Bajo coste Reglas de extracción de datos Ubicación de errores
Cuadro 1.7: Resumen de tipos de coste de la navegación automatizada
40
1.5.1. Coste de desarrollo
El desarrollo de aplicaciones de navegación automatizada debe tener en

cuenta las caracterı́sticas de los datos que va a manejar, que se encuentran
en el apartado 1.4. El coste de desarrollo depende sin duda de la complejidad
de la tarea que se desea automatizar, pero también es altamente dependiente
del API que ofrece la plataforma de desarrollo de estos programas. En gene-
ral, lo deseable es que este API tenga un completo soporte de las acciones
básicas implı́citas que aparecen en el apartado 2.1 y que a su vez ese API
tenga un buen nivel de abstracción para poder facilitar convenientemente la
implementación de las acciones básicas explı́citas, esto es, los pasos básicos
de la tarea, detallados en el apartado 2.2. Una óptima plataforma de desa-
rrollo será aquella que permita detallar cada una de estas acciones con el
mı́nimo número de lı́neas de código de alto nivel, entendibles por mucha gen-
te y evitando en la medida de lo posible que sus diferencias con un browser
trasciendan al usuario, para garantizar que la parte de la tarea que especifica
la recuperación de documentos del Web sea realizada de la forma más sencilla
posible.
Sin embargo, la recuperación de documentos del Web no es más que una
de las acciones que deben formar parte de la tarea. Tal y como figura en el
apartado 2.2, debe procesarse el documento para extraer los datos relevantes
que en él figuran, estructurarlos, opcionalmente homogeneizarlos en el caso de
que puedan proceder de varias fuentes y procesarlos conforme a la tarea que se
esté automatizando. Todas estas acciones deben ser programadas para cada
tarea. Sin duda, dado que a fin de cuentas el desarrollo de estos programas
es una labor de programación, conviene dotar al programador de las mejores
técnicas de reutilización de código propias de los lenguajes de alto nivel de
abstracción, como son la encapsulación en funciones definidas por el usuario
y la modularización de las mismas para que pueda construir sus propias
bibliotecas reutilizables por él y por otros usuarios. De esta forma puede
reducirse igualmente el time to market, es decir, el tiempo de desarrollo y se
puede disfrutar más fácilmente de prototipos más rápidamente aplicables.
No obstante, una de las principales fuentes de coste de desarrollo de estos
programas es la falta de soporte adecuado para muchas acciones ocultas al
usuario durante la navegación y que son normalmente ejecutadas por los
browsers. Siendo lo ideal que dichas acciones sean llevadas a cabo de forma
transparente por estas plataformas para que no trasciendan al usuario, lo
habitual es que las actuales plataformas de desarrollo de estos programas
proporcionen un soporte bastante incompleto de las mismas, por lo que al
final, el programador debe introducir su propio código para llevar a cabo un
41
sinfı́n de pequeños detalles técnicos de los que los usuarios de los browsers no
acaban siendo normalmente conscientes y que aumentan considerablemente
la complejidad de la tarea. De esta forma, una pequeña y sencilla labor en el
Web puede fácilmente requerir el desarrollo de programas demasiado grandes
y complejos que intentan resolver una gran variedad de pequeños detalles
técnicos más propios de la configuración del servidor que de la propia tarea
y que además, al ser tremendamente cambiantes, suponen una importante
fuente de futuros fallos de ejecución.
El coste de desarrollo queda minimizado con la utilización de lenguajes
de programación con el adecuado nivel de abstracción y soporte transparente
a los detalles de la navegación. Un lenguaje de programación de alto nivel de
abstracción, encapsulable, modular, con la posibilidad de definir fácilmente
reglas de extracción de datos basadas en la regularidad estructural y con flexi-
bilidad para estructurar esos datos extraı́dos resulta primordial para reducir
los costes de desarrollo de estas aplicaciones.
1.5.2. Coste de ejecución fallida

El coste de ejecución fallida es el coste que supone un fallo de ejecución al
realizar una tarea. Dicho coste suele depender de la relevancia de la tarea y no
ser dependiente de la forma en la que este programa pueda haber sido cons-
truido. Este coste, no obstante, puede quedar convenientemente minimizado
con la utilización de medidas capaces de dotar de robustez a la navegación,
para que el programa trate de la forma más adecuada los comportamientos
no esperados de las comunicaciones o del servidor. Básicamente, para aplicar
las medidas de robustez se suele tener en cuenta la ubicación del fallo y el
tipo de tratamiento que se desea aplicar.
Ubicación del fallo
Fallos en las comunicaciones Las comunicaciones con el protocolo

HTTP pueden fallar si existe una sobrecarga en la conexión TCP/IP, el
servidor al que se intenta conectar está inaccesible o su respuesta tarda
un tiempo considerado demasiado alto. Este tipo de fallos, normalmen-
te notificados al programador en forma de excepciones o de códigos
de error, pueden ser convenientemente tratados tanto desde el código
de las bibliotecas de la plataforma de ejecución, como por código del
usuario.
Fallos del servidor Las aplicaciones del Web legado no siempre funcionan
42
de la manera en la que de ellas se espera. Ante correctas peticiones de
procesamiento de formularios, las aplicaciones del Web pueden funcio-
nar puntualmente de forma incorrecta, devolviendo al cliente páginas
de error inesperadas por éste. En estos casos, el error no está ni en la
aplicación de navegación, ni en la conexión TCP/IP, sino en el servidor.
Distinguir una página de error (que normalmente ha sido obtenida sin
errores desde el punto de vista del protocolo HTTP), de una página
que confirme que se han procesado adecuadamente los datos enviados
en un formulario, no es algo realizable de forma genérica, sino que de-
penderá de la aplicación y de su forma de devolver páginas de error.
Aunque otras medidas son posibles, lo habitual suele ser tratar estos
errores insertando código que asevere que la respuesta de una petición
indique que ésta ha sido correctamente procesada, tı́picamente con una
sentencia del tipo assert. No insertar este tipo de comprobaciones puede
impedir el tener garantizado que el servidor haya procesado adecuada-
mente la petición recibida. Por otro lado, la página devuelta puede no
ser una página de error y contener los datos que espera el cliente, pe-
ro puede estar tan mal construida, que no se respeten algunas normas
básicas de construcción de páginas necesarias para su correcto proce-
samiento. En esos casos, lo habitual suele ser corregir internamente los
errores de estas páginas antes de que sean manipuladas por el programa
para que presenten ante el programador una estructura correctamente
procesable.
Fallos del cliente por cambios en el servidor Por otro lado, conforme
a lo expuesto en el apartado 1.4.7, la regularidad estructural de las pági-
nas del servidor puede cambiar en cualquier momento al ser el Web una
fuente semiestructurada de datos. Por este motivo, los programas de
navegación en el Web suelen incluir código para detectar los cambios de
regularidad estructural en las páginas visitadas, de forma que, si ésta
cambia, el programa pueda actuar en consecuencia. Lo habitual suele
ser capturar el error y ejecutar reglas secundarias de extracción de da-
tos, o bien no capturar el error, propagando excepciones y confiando en
que la regularidad estructural no cambie durante mucho tiempo. De-
pendiendo del grado de robustez que se quiera añadir a estos programas
y del coste asumible por el programador, se puede insertar un núme-
ro mayor o menor de reglas secundarias que redunden en una mayor
posibilidad de encontrar el dato buscado ante estos posibles cambios.
43
Naturaleza del tratamiento
Tratamiento genérico Los tratamientos genéricos son aquellos que pue-

den implementarse para solucionar errores producidos en la navegación
con cualquier servidor o aplicación accesible desde el Web. Se trata de
fallos que son procesables en las rutinas de las bibliotecas de la plata-
formas de ejecución y que suelen permitir cierta parametrización desde
el código del cliente. Ejemplos de estos tratamientos genéricos son al-
gunas rutinas existentes, como [104, 58, 146], que permiten reparar la
estructura de las páginas HTML mal construidas. Otros ejemplos son
los temporizadores, que limitan el tiempo máximo admisible en el que
debe ser resuelta una petición en el Web. También puede llevarse a
cabo una polı́tica de reintentos suaves, consistente en reintentar va-
rias veces una petición HTTP que no tenga efectos colaterales hasta
que sea correctamente procesada, quizá con un número máximo de in-
tentos. Se denomina petición sin efecto colateral a la que no modifica
datos esenciales en el servidor y puede ser realizada múltiples veces
sin temor a sufrir efectos colaterales. Una petición con efectos cola-
terales, como por ejemplo una petición de transferencia bancaria, no
debe ser reintentada múltiples veces, salvo que se asuma el coste de su
multiplicidad. Algunas iniciativas como [114] proponen extensiones al
protocolo HTTP para que las peticiones con efectos colaterales puedan
ser realizadas completamente de forma atómica, o que, en caso de fallo,
no tengan efectos colaterales, pero se trata aún de una iniciativa sin
estandarizar y carente de soporte en el Web actual. Si todo esto falla,
el usuario aún puede tratar el error en su código capturando las excep-
ciones adecuadas o analizando los errores de estas llamadas con el fin
de aplicar un tratamiento particularizado.
Tratamiento particularizado Los tratamientos particularizados son

aquellos que no son aplicables de forma genérica en bibliotecas, sino
que, al depender de las aplicaciones concretas que estén involucradas
en la tarea, son mejor tratables en el código del programador (por lo
que su coste es también más elevado). Son múltiples las acciones de
tratamiento que puede emprender un programador. Por ejemplo, pue-
de aplicar una polı́tica de reintentos ante peticiones no correctamente
respondidas, como por ejemplo, cuando el servidor indica que está so-
brecargado de trabajo y responde con una página en la que indica que
se reintente la petición más adelante. También es posible inundar el
programa con reglas de extracción alternativas y redundantes para que
se pongan en ejecución en el caso de fallos de las reglas principales de
44
extracción de datos. También es posible insertar código para asegurar-
se de que cada petición ha sido respondida correctamente y lanzar un
mensaje de error y aviso al programador cuando no sea ası́. En la ta-
bla 1.8 aparece un resumen de las medidas de robustez más habituales
aplicadas según el origen del fallo.
Sı́ntoma Tratamiento genérico Tratamiento particular

Lugar Varios Plataforma de ejecución Código de programador
En comunicaciones Excepciones, errores Temporizadores, reintentos suaves Reintentos
Fallos del servidor Páginas de error Reparación de páginas Asserts, reintentos
Cambios de estructura Fallos en las reglas No Reglas secundarias, asserts
Cuadro 1.8: Resumen de medidas de robustez según origen del fallo
1.5.3. Coste de mantenimiento
Los programas de navegación genérica no adaptada apenas necesitan la-

bor de mantenimiento. Ésta está apenas centrada en algunos browsers, para
los que frecuentemente se lanzan nuevas versiones que mejoran imperfecciones
de sus predecesoras o mejoran alguna pequeña funcionalidad. Las modifica-
ciones en la regularidad estructural de las páginas no las afecta, como sı́ lo
hace a las aplicaciones de navegación genérica adaptada y particularizada.
En el caso del Web Semántico, por ejemplo, esas modificaciones deben que-
dar convenientemente reflejadas en los metadatos del sitio Web, de forma
que el mantenimiento se reduce a una labor declarativa. Sin embargo, en los
programas de navegación particularizada, este mantenimiento es una labor
muy costosa que debe realizarse habitualmente en el mismo código del pro-
grama. Por muchas medidas de robustez que se quieran añadir para alargar
la vida del programa, inevitablemente algún cambio no contemplado en la
regularidad estructural acabará apareciendo tarde o temprano, invalidando
alguna de las suposiciones asumidas por el programador. La labor de man-
tenimiento es en estos casos la única opción. Con el fin de minimizar costes,
suele ser deseable que el mantenimiento lo pueda realizar personal que no
necesariamente tenga una elevada preparación. Es por ello que resulta tre-
mendamente importante que los programas de navegación particularizada
cumplan tres importantes requisitos: legibilidad, brevedad y simplicidad.
45
Legibilidad
Las personas que realizan el mantenimiento de los programas no tienen

por qué ser necesariamente las mismas que participaron en su desarrollo.
Incluso aún cuando sı́ sean las mismas personas, las medidas de robustez
anteriormente mencionadas pueden haber sido efectivas durante bastante
tiempo y el programador que quiera realizar una labor de mantenimiento
puede haber olvidado los detalles en los que se basó para su construcción.
Por todas estas razones y por muchas otras, la legibilidad de los programas
resulta primordial. Para mejorar esa legibilidad, es conveniente usar técnicas
de programación con un nivel de abstracción adecuado para la descripción de
tareas y que preferiblemente sean conocidas por mucha gente y estén basadas
en estándares que eviten la ambigüedad, de forma que cualquier pequeño tro-
zo de código pueda ser fácilmente entendido por las personas que lo analicen
sin necesidad de tener un conocimiento completo del problema.
Brevedad
La legibilidad no es el único factor que influye en el coste de mantenimien-

to de estos programas. Un wrapper escrito en C o Java puede ser fácilmente
legible al estar escrito en un lenguaje de programación conocido por mucha
gente, pero si no usa unas bibliotecas de soporte con el adecuado nivel de
abstracción, con primitivas que reflejen cada una de las acciones de la tarea
en pocas lı́neas de código, el tamaño del programa final puede fácilmente
dispararse. Para conseguir programas breves, lo deseable es poder disponer
de un potente conjunto de primitivas capaces de reflejar cada paso de la tarea
en unas pocas lı́neas de código.
Simplicidad
Una buena plataforma de desarrollo se caracteriza por la flexibilidad y

potencia de sus primitivas de construcción, las cuales deben ser capaces de
permitir a su vez la suficiente parametrización para poder controlar todos
los aspectos técnicos de bajo nivel que requieran ser atendidos. Sin embargo,
esa potencia suele conseguirse implicando cierta complejidad de manejo por
parte del programador, por lo que es deseable además de las propiedades
anteriores de legibilidad y brevedad, la suficiente simplicidad del programa
para que cualquier cambio que se realice en el mismo no acabe afectando
a demasiadas lı́neas de código. Por esa razón, es deseable usar mecanismos
que, permitiendo la programación de complejos algoritmos de navegación y
46
manipulación de datos, mantengan lo más simple posible los programas con
el objetivo de que sea poco costosa la labor de localizar y modificar las lı́neas
de código implicadas en un cambio dentro de uno de estos programas. La
simplicidad de mantenimiento se refleja en la capacidad de que cualquier
cambio pueda fácilmente localizarse sobre una pequeña parte del programa
(una lı́nea de código es lo ideal) sin que el cambio implique necesariamente
una revisión del resto del programa. Es importante que la plataforma de
ejecución pueda indicar el lugar donde se producen los fallos con el fin de
tener localizado el lugar en el que debe aplicarse un cambio.
1.6. Marco de trabajo

Numerosos han sido los trabajos que han elaborado aplicaciones de nave-
gación particularizada para los sitios Web en los últimos años. Buena parte
de ellos aparece resumida en el capı́tulo 3. Todos ellos coinciden en presentar
soluciones con serios costes de desarrollo, problemas de aplicabilidad en
diversas fuentes de datos (dadas sus enormes heterogeneidades), una elevada
fragilidad ante errores y cambios en el servidor, y, principalmente, elevados
costes de mantenimiento que sin duda han influido en su escasa utilización.
Por estas razones, nuevas formas avanzadas de recuperación y tratamien-
to de la información para la navegación Web particularizada, aplicable al
deep Web que se sabe localizada en el Web legado, con las caracterı́sticas
mencionadas en el apartado 1.4, necesitan ser aplicadas, de forma que se
aprovechen los avances de los últimos estándares orientados al Web, con el
fin de dar soluciones efectivas a los problemas anteriormente mencionados
minimizando adecuadamente sus costes.
1.7. Objetivos
En la presente tesis doctoral se pretende aportar soluciones para los pro-
blemas mencionados en el apartado 1.5 y que se encuentran resumidos en el
apartado 1.6. Con el fin de facilitar la automatización de tareas en el Web
legado, tanto basado en HTML como en cualquier formato XML, se persi-
guen métodos avanzados, para reducir el coste de desarrollo y mantenimiento
de aplicaciones de automatización, de forma que a su vez éstas sean lo más
robustas posibles ante posibles errores en las aplicaciones que ejecutan en
los servidores y ante la orientación a la visualización de las páginas y a sus
47
cambios de regularidad estructural. A continuación se detallan los objetivos
de esta tesis:
1. Proponer unos mecanismos de desarrollo de programas que nave-

guen automáticamente en el deep Web, de forma que el coste de de-
sarrollo de estas aplicaciones, mencionado en el apartado 1.5.1, se vea
sensiblemente reducido frente a las opciones existentes actualmente y la
automatización de tareas en el Web por medio de programas de navega-
ción particularizada sea ası́ asequible a un mayor número de personas.
Estos métodos de construcción deberán tener un adecuado nivel de
abstracción, con el fin de favorecer su comprensión, y, en lo posible,
permitir su utilización por herramientas que ayuden al programador en
su desarrollo.
2. Proporcionar una plataforma que no sólo pueda usarse con un elevado

nivel de abstracción y comprensible por los usuarios conforme al ob-
jetivo anterior, sino que además sea convenientemente parametrizable
y con el mayor cubrimiento posible a la ejecución de aquellas acciones
que implı́citamente el browser realiza de forma transparente evitando
en lo posible que el usuario sea consciente de ello. Dichas acciones, que
aparecen detalladas en el apartado 2.1, son necesarias para mantener
correctamente el diálogo y el concepto de sesión con los servidores Web
con los que se dialoga. El fin de esta mejora consiste en abstraer al usua-
rio del mayor número posible de detalles de bajo nivel, permitiéndole,
sin embargo, tener el control de los mismos cada vez que lo necesite.
Consiguiendo que la gestión de estas acciones genéricas de cualquier
sitio Web queden convenientemente encapsuladas y no formen parte
del código principal de los programas, los programas se mantienen lo
más compactos posible.
3. Si bien es recomendable que la plataforma de navegación se haga cargo

de las acciones de las que no es normalmente consciente un usuario que
navega manualmente usando un browser, las acciones que sı́ tras-
cienden al usuario, y que aparecen en el apartado 2.2, como seguir
un enlace o rellenar un formulario, deben poder ser activables de la for-
ma más sencilla posible por parte de éste. Lo ideal es que cada una de
estas acciones pueda ser especificada con una acción sencilla en el caso
de que use una herramienta (como por ejemplo en un navegador), o con
un mı́nimo número de lı́neas de código, en el caso en el que emplee un
lenguaje de programación, usando a ser posible un conjunto pequeño
pero potente de constructores flexiblemente parametrizables.
48
4. Por otro lado, para las acciones más complejas que debe especificar
el usuario, que se encuentran detalladas en el apartado 2.2 y que nor-
malmente se corresponden con las acciones de procesamiento de datos
mencionado en el apartado 2.2.6, puede requerirse la especificación de
algoritmos complicados. Por ese motivo puede ser necesario la progra-
mación de varias lı́neas de código, con sentencias de programación como
llamadas a funciones que manipulen complejas estructuras de datos,
diversas condiciones que impliquen varios posibles casos alternativos
a tener en cuenta, bucles que se aniden entre sı́ o con las sentencias
condicionales y datos de diversos tipos. Lo habitual es que el código
que procese los datos de una tarea sea muy particular y dependiente
de ésta y de la forma en la que el usuario desee realizarla (por ejemplo,
seleccionar la mejor oferta de leche fresca de un catálogo según varios
criterios, como marca, precio, tamaño del envase y gastos de envı́o). Por
ello, lo más aconsejable consiste en permitir la programación de ruti-
nas definibles por el usuario en algún lenguaje de programación
ampliamente conocido, como Java, u otros lenguajes igualmente reco-
nocidos, de forma que esa rutina pueda ser convenientemente invocada
desde el código de programa. De esta forma, pasando por argumento
a esa rutina los datos extraı́dos y estructurados de las páginas alma-
cenados en repositorios programables (variables, ficheros, ...), la rutina
puede manipular los datos obtenidos del Web.
5. Proporcionar mecanismos adecuados para favorecer la robustez de

los programas ante fallos en las conexiones TCP/IP y adaptabilidad
ante cambios en las páginas, reduciendo el coste de ejecución fallida
y que aparece detallado en el apartado 1.5.2. El objetivo consiste en
incluir medidas de robustez ante fallos en las comunicaciones y ante
cambios y fallos en las aplicaciones accedidas por el Web. Estas medidas
se plasmarán tanto en la plataforma de soporte a la ejecución como
en constructores directamente utilizables por el usuario en su propio
código. Dicha funcionalidad no aparece en los browsers actuales, al
igual que tampoco es común encontrarla en otros tipos de plataformas.
También se debe contemplar una polı́tica de alternativas de uso en el
caso de que se encuentren enlaces rotos.
6. Las medidas de robustez pueden amortiguar los efectos de los cambios

de regularidad estructural del Web y pueden alargar el tiempo de vida
de las aplicaciones de navegación automatizada. Sin embargo, debido
al carácter siempre dinámico del Web, es necesario un mantenimien-
to para cuando esas medidas fallen. Por ello se pretende proporcionar
49
mecanismos para la minimización del coste de mantenimiento de las
aplicaciones de navegación automatizada, que aparece detallado en el
apartado 1.5.3, de forma que este mantenimiento quede reducido a una
mı́nima labor, con un coste sensiblemente inferior a las alternativas uti-
lizables hasta el momento, de forma que la mayorı́a de las acciones de
mantenimiento consistan en la modificación de una acción sencilla, de
las reflejadas en el apartado 2.2, fácilmente localizada y que normal-
mente afecte a muy pocas lı́neas de código del programa de usuario, sin
ser necesario revisar el programa completo.
7. Permitir que esa automatización se pueda aplicar a prácticamente cual-

quier fuente o aplicación del Web legado, es decir, a las tradicionales
páginas HTML orientadas a la visualización y cuyos principales atri-
butos aparecen detallados en el apartado 1.4 y que mayoritariamente
abundan en el Web actual. La automatización de tareas en el Web se
debe poder aplicar no sólo a las páginas que, por estar bien construidas,
les sean inmediatamente aplicables las modernas tecnologı́as de mani-
pulación de documentos y extracción de datos, sino también a aquellas
que estén mal construidas (dentro de unos lı́mites que las permitan ser
convenientemente reparadas). Para ello, se incluirán en la plataforma
de ejecución métodos capaces de reparar automáticamente esos errores
de las páginas recuperadas de los servidores. Igualmente, deberán pro-
porcionarse mecanismos, si no en la plataforma, al menos a disposición
del usuario, para solventar los problemas derivados del hecho de que
esas páginas estén pensadas exclusivamente para el acceso por medio
de un conjunto limitado de browsers gráficos, o con capacidad de accio-
nar eventos especiales desde rutinas embebidas en applets, animaciones
Flash o, principalmente, rutinas JavaScript.
8. Permitir aplicar ese tratamiento automatizado de la información men-

cionado anteriormente también a documentos de cualquier lenguaje
definido sobre XML, siempre que al menos su esquema sea conocible
a priori por el programador para las tareas más complejas que ası́ lo
requieran. Ası́ pues, se pretende que, aunque la mayor parte de las prue-
bas de implementación de esta tesis se realizará sobre páginas HTML
del Web legado, ese formato concreto no deje de ser sólo un ejemplo
particular de navegación sobre documentos en el Web, siendo posibles
igualmente otros lenguajes definibles en XML, no ya sólo algunos de las
ya conocidos (como WML + WMLScript [61], SMIL [125], RDF [123],
RSS [16], SVG [124], MathML [120], ...), sino cualquier otro lenguaje
XML en general, actual o futuro, es decir, ya inventado o aún por inven-
50
tar, independientemente de si su uso está centrado en la visualización
en un browser o si tiene otra finalidad.
1.8. Estructura de la memoria

El capı́tulo 2 presenta un análisis de los principales aspectos de la au-
tomatización en el Web. Para poder realizar una efectiva automatización
de tareas en el Web es preciso analizarlas primero, reconociendo sus par-
tes o acciones básicas, examinando las alternativas aplicables a cada una de
ellas, teniendo en cuenta las caracterı́sticas distintivas de la materia tratada
(los datos del Web). Para cada parte, se analizan sus principales ventajas e
inconvenientes desde los puntos de vista de aplicabilidad y de coste de im-
plantación, con el fin de poder escoger para cada problema la solución más
adecuada. En el capı́tulo 3 se describe el estado del arte de la automatización
de tareas en el Web, analizando desde sus precedentes hasta las tendencias
actuales. Un estudio sobre las soluciones tecnológicas existentes, clasificadas
según los criterios establecidos anteriormente puede encontrarse en el capı́tu-
lo 4. Los capı́tulos 5 y 6 presentan unas propuestas de tecnologı́as para la
sı́ntesis de aplicaciones para la automatización de tareas en el Web que,
basándose en las ideas del capı́tulo 2, presentan unos mecanismos de cons-
trucción de estas aplicaciones capaces de ser operables en el Web legado y
que tienen además la aportación de estar basadas en estándares que reducen
sensiblemente los costes de implantación y mantenimiento. El capı́tulo 7 in-
troduce unos ejemplos que demuestran la aplicabilidad de estas propuestas a
tareas definidas sobre sitios Web conocidos. Finalmente se enumeran algunas
conclusiones del trabajo ası́ como lı́neas de actuación para trabajos futuros.
51
52
Capı́tulo 2
Análisis de tareas Web
Cuando la gente navega por el Web, aparte de por ocio o entretenimiento,

suele hacerlo persiguiendo un fin concreto, un propósito particular. Ejemplos
de tareas Web quizá no tan complejas como las del apartado 1.2 pueden verse
en la siguiente lista:
Obtener un documento o un conjunto de ficheros multimedia
Leer un periódico
Usar un buscador (o varios)
Enviar postales electrónicas
Leer correo Web, lo cual implica las subtareas de identificarse, listar

los mensajes, visitar siguientes, responder, ...
Consultar disponibilidad de habitaciones en un hotel, suponiendo que

ofrezca esta información online
Comprobar que las páginas publicadas en un sitio Web cumplan ciertas

propiedades (no tener enlaces rotos, adherirse a algún formato particu-
lar, ...)
Comprar billetes de avión o de tren
Comprar en una tienda electrónica, lo cual implica buscar cada artı́culo,

añadirlo al carrito, estar atento a las ofertas, pagar, ...
Reservar salas de reuniones en la intranet de una organización
53
Presentar la declaración de la renta
Poner una denuncia en la policı́a
Y muchas más
Según crece el Web, con cada vez un mayor número de datos y aplicaciones
accesibles, el número de tareas igualmente aumenta. De hecho, el crecimiento
del Web no es el único impulsor del aumento de tareas realizables en el
Web. Últimamente comienzan a ser cada vez más necesarias aplicaciones
que combinen la información de varios sitios Web, de la misma forma en
la que se combinan datos de bases de datos verticalmente fragmentadas y
distribuidas [52]. Esas tareas empiezan a ser inmanejables para ser realizadas
manualmente.
En otras ocasiones, por el contrario, sobre una misma aplicación accesible
en el Web es deseable ejecutar varias tareas posibles. Pese a las reticencias
de quien no quiere que sus datos sean comparados de forma explı́cita por un
tercero, es poco extraño que un comparador de ofertas como [3] o de aso-
ciaciones de consumidores soliciten al Web de un banco la TAE de su mejor
depósito bancario a seis meses para compararla con la de su competencia. De
la misma forma, tampoco deberı́a resultar extraño que ese mismo dato acabe
siendo proporcionado a otra aplicación encargada de calcular el TAE medio
ofrecido por los principales bancos españoles para un estudio estadı́stico. La
utilidad que el dato tenga en la tarea es algo que depende mucho de la tarea
y poco del servidor.
Para poder automatizar las tareas en el Web es preciso analizarlas pri-
mero, diseccionando las partes en las que están estructuradas y reconociendo,
de cada una de esas partes, sus capacidades de automatización y sus princi-
pales retos. Ası́, en una etapa posterior, se podrán aprovechar esas cualidades
de la mejor forma posible para sintetizar aplicaciones que automaticen el Web
de forma más eficiente y menos costosa.
Acciones básicas
A pesar de la clara e intrı́nseca heterogeneidad del Web, mencionada

en el apartado 1.4 y manifiesta, no sólo en sus datos, sino también en sus
formas de presentación, lo cierto es que, por debajo de toda esta visible
heterogeneidad, los principios bajo los que se sustentan las tareas en el Web
son sencillos. De hecho, la simplicidad de manejo de cualquier browser no es
más que un fiel reflejo de que, efectivamente, las partes de una tarea realizable
54
con una navegación en el Web se reducen a un conjunto limitado y sencillo
de acciones básicas.
El conjunto de posibles tareas que se pueden realizar en el Web es in-
menso. De hecho, no para de crecer en tanto en cuanto es cada vez mayor
el número de aplicaciones que se encuentran disponibles a través del Web.
Sin embargo, los innumerables servicios del Web, sean éstos simples pági-
nas o bien complejas aplicaciones manejadas por varios formularios, pese a
sus aparentes diferencias visuales, tienen en común el hecho de estar todos
ellos fundamentados en alguna secuencia (o secuencias) de un reducido con-
junto de acciones básicas que resultan ser comunes a todas las tareas.
Cada tarea realizable en el Web se puede desarrollar efectuando una secuen-
cia particular de este conjunto de acciones básicas. Por ejemplo, una tı́pica
tarea de chequeo de cuentas de correo electrónico en un portal de correo
Web puede implicar una acción básica de solicitud de un documento donde
aparece un formulario de identificación que, una vez rellenado y enviado al
servidor, permite el acceso a una bandeja de correo entrante en la que apa-
rece una tabla con los principales atributos de los mensajes almacenados,
ordenados por fechas y en los que es posible distinguir entre mensajes leı́dos
y no leı́dos. Cada uno de esos mensajes a su vez puede ser leı́do si se sigue
convenientemente un enlace. También puede ser borrado, si se chequea su
opción de selección correspondiente y después se pulsa al botón de borrado.
Otras acciones, como responder o reenviar también son posibles. Secuencias
distintas de este reducido conjunto de acciones básicas constituyen el queha-
cer diario del tráfico Web actual al que dan servicio los numerosos servidores
Web conectados a la Red. Para la realización de una tarea Web, el usuario
debe realizar la ejecución en secuencia ordenada, de cada una de las acciones
básicas que conforman esa tarea.
Tipos de acciones básicas
Las acciones básicas que forman parte de una tarea no son todas de la
misma naturaleza, pudiendo distinguirse entre acciones básicas implı́citas y
acciones básicas explı́citas.
Las acciones básicas implı́citas son aquellas que no deben trascender al
usuario y que son realizadas automáticamente por el browser en una nave-
gación manual. En ellas, el usuario no es necesariamente emprendedor de la
acción. Se trata de acciones que se encuentran gestionadas internamente por
los browsers, sin que el usuario deba proporcionar instrucciones explı́citamen-
te para ello. Ejemplos de acciones básicas implı́citas son todas las referentes
55
a la gestión de cabeceras HTTP (gestión de cookies, redireccionamientos,
identificación de usuario y de agente de usuario, preferencias en los formatos
aceptados o en el idioma, ...), o las que se deben realizar necesariamente con
el contenido del cuerpo de la respuesta HTTP (corrección interna de errores
de estructura en el documento, seguimiento implı́cito de enlaces, acciones
embebidas en lenguajes de scripting, ...).
Las acciones básicas explı́citas son el conjunto de acciones que, en una
navegación manual, deben trascender al usuario, ya que el browser no puede
o no debe emprenderlas por su cuenta. Es por ello que el browser debe espe-
rar instrucciones del usuario, tı́picamente de forma interactiva, para poder
continuar. De esta forma, el usuario se acaba convirtiendo necesariamente
en el emprendedor de la acción. Ejemplos de acciones básicas explı́citas son
el seguimiento explı́cito de enlaces, el rellenado y envı́o de formularios, la
extracción de datos relevantes del documento o el procesamiento que debe
realizarse con los datos recolectados.
Como puede apreciarse, las acciones básicas explı́citas tienen un nivel de
abstracción más elevado y cercano al usuario, mientras que las acciones bási-
cas implı́citas tienen un nivel de abstracción más bajo y más cercano a los
aspectos técnicos de los protocolos HTTP y de los formatos de publicación
en el Web. Como puede comprobarse en la tabla 2.1, que refleja las principa-
les diferencias entre las acciones básicas explı́citas e implı́citas, las primeras
afectan constantemente al usuario de la navegación manual. Por el contra-
rio, esas acciones son atendidas por un programa que sustituye al usuario en
las aplicaciones de navegación automatizada, tanto genérica como particu-
larizada. Las acciones implı́citas, por su parte, diseñadas para ser resueltas
sin conocimiento explı́cito del usuario, son transparentemente gestionadas
por los browsers en la navegación manual. En el caso de la navegación au-
tomatizada, lo deseable serı́a que la plataforma de navegación (el programa
que navegue basándose en metadatos, o las bibliotecas usadas para la cons-
trucción del programa de navegación particularizada) ejecutaran todas esas
acciones con la misma transparencia de un browser. No obstante, la falta
de buenas plataformas de navegación automatizada para el Web con soporte
para todas estas posibles acciones muchas veces acaba obligando al progra-
mador a introducir su propio código de tratamiento para suplir las carencias
de las plataformas de navegación. Ello suele ser una fuente de encarecimiento
de costes de estos programas, según el nivel de soporte que de estas acciones
tenga la plataforma.
56
Acción básica explı́cita Acción básica implı́cita
Navegación manual Usuario Browser
Navegación automática genérica no adaptada Robot Según programa
Navegación automática genérica adaptada Metadatos Agente Web Semántico
Navegación automática particularizada Programador Bibliotecas+programador
Nivel de abstracción Cercano a la tarea Cercano a formatos y protocolos
Ejemplo Enviar un formulario relleno Gestionar una cookie
Cuadro 2.1: Diferencias entre acciones básicas explı́citas e implı́citas
2.1. Acciones básicas implı́citas

Las acciones básicas implı́citas son realizadas por muchos browsers sin
que sus usuarios sean muchas veces conscientes de ello. Pese a su relativa-
mente bajo conocimiento por muchos usuarios, las acciones básicas implı́citas
son necesarias para aspectos tan fundamentales como el mantenimiento de
sesiones HTTP, las restricciones de acceso a contenidos, la adecuación del
Web a preferencias del usuario, o la ejecución de múltiples comportamientos
internos necesarios para la correcta navegación por cualquier página accesi-
ble desde el Web. A continuación aparecen detalladas algunas de las acciones
básicas implı́citas más importantes.
2.1.1. Gestión de cabeceras HTTP
El protocolo HTTP establece la posibilidad de intercambiar en varios

campos situados en sus cabeceras, información relativa a las peticiones y
respuestas intercambiadas. Estas cabeceras pueden ser usadas tanto por el
cliente como por el servidor HTTP para obtener información que necesiten
del otro extremo con el fin de mantener un diálogo correcto. La mayorı́a
de esas cabeceras permanecen inalterables a lo largo de ese diálogo, pero
otras muchas van cambiando a lo largo de ese diálogo, por lo que deben ser
adecuadamente gestionadas para poder realizar correctamente la petición
HTTP.
En la tabla 2.2 aparecen las principales cabeceras que deben gestionar
los clientes del protocolo HTTP. Cada una de esas cabeceras tiene su es-
pecial importancia. Por ejemplo, algunos servidores Web presentan páginas
de error cuando son accedidos por programas que no acreditan ser Microsoft
Internet Explorer en la cabecera de identificación del cliente, pese a que sus
contenidos sean en realidad navegables por otros browsers. En otros casos, no
57
especificar correctamente una cookie o el campo Referer en una petición a un
servidor puede suponer la pérdida de la sesión con el servidor. No indicar que
se acepta HTML como formato, puede implicar la suposición por parte del
servidor de que debe responder con documentos en formato WML o quizá en
texto plano. No indicar que el idioma preferible es el español puede implicar
que las páginas vengan por defecto en inglés.
Nombre de cabecera Emitida por Significado Ejemplo

User-Agent Cliente Identificación del cliente Mozilla/4.6
Accept Cliente Formatos aceptados text/html, image/*
Accept-Language Cliente Idiomas preferibles en, es-ES, es
Referer Cliente URL desde la que se sigue el enlace http://www.yahoo.es/
Cookie Cliente Valor almacenado en el cliente NOMBRE=VALOR
Authorization Cliente Identificación para acceso restringido Base 64
Set-Cookie Servidor Valor almacenable en el cliente NOMBRE=VALOR
WWW-Authenticate Servidor Acceso restringido “AccessRestreint”
Content-Type Cliente o Servidor Formato del documento o petición text/html
Content-Length Cliente o Servidor Tamaño del documento o petición 12354
Cuadro 2.2: Principales cabeceras gestionadas por los clientes del protocolo
HTTP
2.1.2. Gestión de errores en la comunicación con el

servidor
Las comunicaciones con el protocolo HTTP pueden fallar si existe una
sobrecarga en la conexión TCP/IP, el servidor al que se intenta conectar
está inaccesible o su respuesta tarda un tiempo considerado demasiado alto
para lo razonable por la tarea. Dependiendo de la gravedad del fallo (no es lo
mismo que haya un fallo de transferencia en una página HTML que lo haya
en la transferencia de una de sus imágenes), el error deberá hacerse constar
con mayor o nivel de severidad al usuario o al programa que dirija la tarea
para que tome las medidas que considere oportunas.
2.1.3. Reparación interna de páginas mal construidas

Una vez obtenida una página del Web y solventados los problemas de
comunicación con el servidor, debe procederse a analizar la respuesta, nor-
58
malmente contenida en una página HTML. Lamentablemente, tal y como se
mencionaba en el apartado 1.4.3, muchas de las páginas que se encuentran
en el Web no cumplen el conjunto de normas básicas de construcción. Por
esa razón, resulta necesario reparar internamente esos errores con el fin de
permitir el análisis de esa respuesta por el cliente, ocultando al usuario esos
errores en la medida de lo posible. Este trabajo extra en el lado del cliente
debe ser realizado debido a la tradicional permisividad ante errores en las
páginas obtenidas de los servidores.
2.1.4. Seguimiento implı́cito de enlaces
Una vez correctamente analizada una página obtenida del Web, es nece-
sario identificar todos aquellos elementos multimedia que forman parte de la
misma con el fin de seguir los enlaces que implı́citamente deban visitarse. El
seguimiento de enlaces puede ser entendido como implı́cito, si es el browser
el que decide recuperar ese documento, quizá porque forme parte integrante
del que acaba de ser descargado y analizado, o explı́cito, si es el usuario
el responsable de la activación del enlace. Por ejemplo, los enlaces que en
HTML se definen con las etiquetas a o area son normalmente seguidos de
forma explı́cita, porque no deben ser visitados a no ser que el usuario explı́ci-
tamente lo solicite. Por el contrario, en otros tipos de enlaces que en HTML se
definen con etiquetas como frame, img, script, link u object, es el browser
quien determina si deben ser seguidos de forma explı́cita o implı́cita. Si, por
ejemplo, se desea emular a un browser gráfico como Mozilla [12] o Microsoft
Explorer [91], los seguimientos de los enlaces definidos en las etiquetas ante-
riores, salvo los roles explı́citos de link (next, previous, table of contents, ...),
son implı́citos, pues se entiende que un browser gráfico normalmente descar-
ga implı́citamente de cualquier página del Web todos sus componentes, como
son los marcos, imágenes, scripts externos y hojas de estilo externas. Por el
contrario, cuando se desea emular a un browser textual como Lynx [10], el
seguimiento de los anteriores enlaces se vuelve, si no explı́cito, muchas veces
incluso inaccesible, porque se entiende que hay documentos enlazados que no
son adecuadamente procesados por el browser. En la tabla 2.3 puede verse
un esquema resumido del comportamiento de estos enlaces dependiendo del
browser en el que se utilizan.
59
Browser a, area img, frame link script, object
Gráfico Explı́cito Implı́cito Implı́cito Implı́cito
Textual Explı́cito Explı́cito Limitado Inaccesible
Braille Explı́cito Limitado Limitado Inaccesible
Cuadro 2.3: Tipo de seguimiento de enlaces HTML dependiendo del browser
2.1.5. Ejecución de comportamientos embebidos en las

páginas
Una vez han sido correctamente descargados todos los elementos multi-
media de las páginas, los elementos dinámicos de las mismas (rutinas Ja-
vaScript o JScript, Applets, controles ActiveX, animaciones en Flash, otros
plugins, ...) pueden empezar a funcionar. Se trata de las rutinas que, me-
diante pequeños programas insertados en las páginas Web y, gracias a un
intérprete, máquina virtual o plugin embebido en el browser, permiten al di-
señador de la página tener acceso a ciertos recursos del browser del usuario.
Las rutinas JavaScript, que suelen ser las más usadas, permiten controlar
un amplio espectro de acciones tı́picamente manejadas por el browser. Por
ejemplo, son capaces de manipular aspectos tan diversos como las propie-
dades de visualización de los elementos de las páginas (tamaños, posiciones,
colores, visibilidad, ...) , la descarga condicionada de elementos multimedia
de una página, manipular la base de datos de cookies o modificar al gusto
del diseñador de la página la semántica del comportamiento de los controles
de los formularios. Tanto es ası́, que muchas páginas resultan innavegables
si el browser con el que se las intenta acceder no dispone de un intérprete
ajustado a las especificaciones del JavaScript utilizado en la página.
Si la plataforma de navegación no dispone de estos intérpretes o estos
plugins, los comportamientos embebidos no son ejecutables. Ello puede no
suponer un problema serio para el procesamiento de páginas con comporta-
mientos embebidos que sólo afecten a aspectos de visualización, siempre que
existan contenidos alternativos ofrecibles al usuario o, simplemente no apor-
ten datos relevantes. Sin embargo, puede suponer serios problemas para la
accesibilidad cuando esos comportamientos tienen un papel en la navegación.
Este tipo de rutinas tiene una caracterı́stica muy importante desde el
punto de vista de su automatización. Al tratarse de comportamientos que
vienen pre-programados en elementos multimedia de las páginas, su compor-
tamiento, no se encuentra por lo tanto pre-programado en ningún browser,
es decir, no es conocible a priori, por lo que para su correcto funcionamiento
se necesita del correspondiente soporte para la ejecución. Sin embargo, dis-
60
poner de ese soporte puede ser difı́cil o costoso para muchos usuarios que no
siempre lo encuentran disponible en browsers o plataformas de navegación
automatizada.
2.1.6. Soporte para otros protocolos

En ocasiones, se deben enviar mensajes por correo electrónico. En otras
ocasiones, algunos documentos deben recuperarse usando otros protocolos
como FTP. También es posible que sea necesario acceder a ciertas páginas
mediante protocolos seguros, principalmente SSL. Forma parte de las accio-
nes implı́citas de la plataforma de navegación saber gestionar adecuadamente
estos protocolos, de forma que el usuario no sea consciente de esos detalles
de bajo nivel de cada uno de ellos.
2.1.7. Tratamiento adecuado de cada campo de formu-

larios según su forma de rellenado
A la hora de asociar valores a los campos de los formularios, es necesario
tener en cuenta las reglas de rellenado de cada campo del formulario reflejadas
en la tabla 2.4. Por una parte, debe considerarse el tipo de valor que indica
la naturaleza del valor asociado a cada campo del formulario. Principalmen-
te, pueden distinguirse textos libres especificados por el usuario, ficheros que
deben ser enviados del cliente al servidor y valores ya especificados en la
página por el servidor. Por otra parte, debe considerarse la especificación de
rellenado por el usuario, es decir, aquello que el usuario debe proporcionar
para que dicho campo de formulario quede adecuadamente relleno. Princi-
palmente, puede distinguirse entre el rellenado directo, que consiste en el
que el usuario proporciona directamente el valor con el que desea rellenar
el formulario, o bien un rellenado indirecto, en el que el usuario especifica
un criterio de selección que sirve para decidir las opciones que deben quedar
marcadas y las que no. El criterio de selección consiste normalmente en un
criterio booleano que, aplicado a cada una de las opciones seleccionables,
indica si esa opción debe admitirse o no como seleccionada. Los criterios de
selección pueden ser de dos tipos, sencillos o múltiples, dependiendo de si,
cuando son aplicados a un conjunto de varias opciones, deben indicar una o
varias de esas opciones como seleccionadas. Este acomodamiento, o conjunto
de restricciones establecidas sobre el conjunto de valores posibles con los que
se puede rellenar un formulario, se encuentra ya facilitado por los browsers y
es una de las acciones básicas implı́citas que influyen en la forma de rellenar
61
cualquier formulario.
Campo Tipo de valor Rellenado por usuario

textarea Texto libre Rellenado directo
input.text, input.password Texto libre sin saltos de lı́nea Rellenado directo
select, input.radio Valor especificado por el servidor Criterio de selección
select.multiple, input.checkbox Valores especificados por el servidor Criterio de selección (múltiple)
input.file Fichero local Path al fichero
input.hidden Valor especificado por el servidor Oculto al usuario
input.button Llamada a JavaScript No
input.reset Reinicio del formulario No
input.submit, input.image Envı́o Criterio de selección
Cuadro 2.4: Tipo de rellenado de campos de formularios HTML
2.1.8. Creación de query-string a partir de un formu-

lario relleno
Antes de enviar a un servidor un formulario relleno, es necesario codificar

la información que encierra para su envı́o, de forma que sea correctamente
procesable en el servidor. Esta información codificada, denominada query-
string, es enviada como parte de la correspondiente petición HTTP al servi-
dor. En el caso de que la petición sea del tipo POST, el query-string debe
formar parte del cuerpo de la petición, por lo que irá aislado aparte de las
cabeceras HTTP. Por el contrario, si el formulario se envı́a con un comando
GET, el query-string es concatenado al final de la URL que se desea visitar.
La acción de codificación de formularios rellenos debe tener en cuenta su
estructura, respetando el orden y el tipo de cada uno de los campos que com-
ponen el formulario. A la hora de crear el query-string, se deben establecer
parejas campo-valor, independientemente de cómo se hubieran rellenado los
campos de ese formulario. Por otra parte, en la codificación del query-string
puede frecuentemente jugar también un papel importante el JavaScript. Mu-
chos de los campos de los formularios dedicados a controlar eventos JavaS-
cript no deben ser enviados al servidor. Los botones de envı́o no pulsados
tampoco deben ser enviados al servidor.
62
2.2. Acciones básicas explı́citas
Las acciones básicas explı́citas son las que definen los pasos en los que
está involucrado el usuario durante la ejecución de una tarea en el Web. Rea-
lizarlas con un navegador suele ser un buen punto de partida para empezar a
construir el esqueleto básico de una aplicación de navegación automatizada.
Las tareas del Web son, por lo tanto, especificadas basándose en este tipo
de acciones. Algunas de ellas, sin embargo, no son siempre necesarias en to-
dos los pasos. La tabla 2.5, muestra cada una de esas acciones en una fila,
para comparar su capacidad de automatización desde los puntos de vista de
la navegación manual y de la navegación automática. Como puede apreciar-
se, desde el punto de vista de la navegación manual, todas ellas, en mayor o
menor medida, con mayor o menor soporte por parte del browser, son respon-
sabilidad del usuario. Desde el punto de vista de la navegación automatizada,
estas acciones deben recaer en un programa, por lo que se mencionan las par-
tes de ese programa que están afectadas por cada una de esas acciones. Por
ejemplo, las acciones de seguimiento de enlaces y envı́o de formularios ape-
nas suelen suponer la correspondiente llamada a las primitivas GET o POST
del protocolo HTTP, a la que sólo hay que parametrizar convenientemente.
Sin embargo, el resto de las acciones básicas explı́citas no tiene un coste tan
reducido como ése habitualmente, ya que, al ser dependientes de la tarea,
deben ser programadas con código de usuario.
Acción básica explı́cita Navegación manual Navegación automatizada

Extracción de datos relevantes Usuario Reglas de extracción (regularidad estructural)
Estructuración de datos semiestructurados Usuario Repositorios estructurados
Seguimiento explı́cito de enlaces Usuario + Browser Llamada a primitiva GET
Rellenado de formularios Usuario + Browser Metadatos, código de programador
Envı́o de formularios Usuario + Browser Llamada a primitivas POST/GET
Procesamiento de datos Usuario Rutinas de usuario, programas externos, ...
Cuadro 2.5: Acciones básicas explı́citas
2.2.1. Extracción de datos relevantes

La extracción de datos relevantes implica la selección de los datos consi-
derados relevantes embebidos en las páginas Web y su extracción para poste-
riores procesamientos. Estos datos, cuya relevancia se encuentra descrita en
63
el apartado 1.4.4, se suelen encontrar repartidos por varias páginas o marcos.
Cuando no se trata de ficheros multimedia, lo normal es que se encuentren
en forma de simple información textual (e.g.: precios, titulares, mensajes,
teléfonos, direcciones, cotizaciones, fechas, cantidades, ...) tı́picamente em-
bebida en páginas HTML junto con otra mucha información que puede no
ser relevante para la tarea (publicidad, marcado estructural orientado a la
visualización, datos relevantes para otras tareas, ...).
La capacidad de extraer datos del Web, es sin duda de las más importan-
tes, pues juega un papel importante en todos los pasos ejecutados entre la
navegación por el Web. Seguir un enlace implica seleccionar en primer lugar
el enlace que debe ser seguido y extraer de él la dirección a la que apunta.
Enviar un formulario implica seleccionar en primer lugar todos los campos
que forman parte del mismo y rellenar cada uno conforme a su naturaleza
y a los objetivos del usuario, para después activar la acción del formulario.
Otros procesamientos más complejos definidos por el usuario, como compa-
raciones, integración de datos y otros comportamientos, necesitan también
la realización de complejas extracciones de datos. De esta forma se prescinde
de todos aquellos datos que aparecen en las páginas pero que no intervienen
en la tarea.
En el caso de la navegación manual basada en browsers, el usuario debe
visualizar normalmente pantallas enteras para poder detectar visualmente
la información que le interesa. Es normal que para ello deba examinar varias
pantallas y ventanas o hacer scrolling. Desafortunadamente, los browsers de
hoy en dı́a no reciben especificaciones acerca de cuáles son los datos relevan-
tes para los usuarios y cuáles pueden ser ignorados, con el fin de destacar
los primeros y ocultar los últimos (esta labor quizá podrı́a ser emprendida
con scripts definibles por los usuarios aplicados a documentos del Web, pero
ello no es una solución siempre factible). La única función de un browser
es mostrar un documento de la mejor forma posible y ejecutar sus órde-
nes interactivas, siendo imposible destacar para cada usuario los datos que
son interesantes para él y su tarea. Las opciones de destacado de partes de
documentos están a merced de los autores de los documentos, no de sus lec-
tores, algo que sin embargo algunos trabajos como [48] sı́ han logrado hacer
basándose en una personalización que no todos los sitios Web ofrecen. Aun-
que la simple lectura de textos sobre las pantallas de un ordenador puede
ser suficiente para algunos usuarios a la hora de pasar a realizar su siguien-
te acción, lo cierto es que el Web se caracteriza por presentar demasiada
información que presenta costes prohibitivos para ser procesada por perso-
nas, razón por la cual una separación automatizada de los datos relevantes
respecto del resto de datos no relevantes resulta conveniente en esos casos.
64
En el caso de la navegación automatizada, la extracción de datos no
está basada en la visualización, sino que consiste en una selección de da-
tos relevantes dentro de documentos semiestructurados, lo cual no es siem-
pre sencillo y es además claramente dependiente de la estructura interna de
esos documentos. Para ello, pueden usarse reglas de extracción de datos
basadas en una regularidad estructural seleccionando aquellos datos que
cumplan un formato esperado. Sin embargo, esta estructura de marcado en
la que están basadas estas reglas está normalmente muy orientada a los as-
pectos de visualización, por lo que las reglas de extracción de datos, aparte
de ser de las partes con mayor presencia en los programas, son también de
las más frágiles, ya que cualquier cambio en la estructura esperada de las
páginas afecta directamente a esas reglas. La fácil construcción de estas re-
glas de extracción de datos es vital para conseguir un bajo coste, no sólo de
desarrollo, sino también de mantenimiento.
En el caso de la navegación manual, esta labor recae completamente en
el usuario. El browser prácticamente no interviene ni realiza otra labor más
que presentar los datos en la pantalla junto con el resto de la información,
sin tener capacidad para tan siquiera resaltar el dato para el usuario, pues no
tiene forma de saber cuál de los datos que figuran en la página es el dato que
interesa al usuario para su tarea. En el caso de la navegación automática,
al tratarse de un tratamiento especı́fico y dependiente de la estructura de las
páginas, de los datos, y de la tarea que los va a utilizar, esta acción no se
encuentra pre-construida en una biblioteca genérica de la plataforma, por
lo que debe ser programada en reglas de extracción definibles por el usuario.
2.2.2. Estructuración de datos semiestructurados
Los datos extraı́dos pueden ser necesarios más de una vez a lo largo de
la ejecución de una tarea, por lo que conviene que sean convenientemente
almacenados en un repositorio estructurado. Desde el punto de vista de la
navegación manual, esta labor recae en la responsabilidad del usuario, quien
habitualmente suele resolver el problema memorizando el dato recientemente
visualizado (tı́picamente en su memoria a corto plazo), apuntarlo en un papel
o, en el mejor de los casos, recurrir el conocido uso del copiar y pegar en la
ventana de otra aplicación. Sin embargo, ni la mente humana, ni el papel, ni
una ventana de un editor de texto son repositorios adecuados para el proce-
samiento automatizado desde un programa de ordenador. Además, los datos
obtenibles del Web pueden ser muy voluminosos (de ahı́ el desbordamiento
habitual que sufren la mayorı́a de los usuarios que navegan con browsers), por
65
lo que para poder almacenar convenientemente esos datos se necesitan re-
positorios capaces de almacenar grandes volúmenes de los mismos, muchas
veces sin que su tamaño sea a priori limitable. Por esa razón, los programas
de navegación automática suelen usar, no sólo variables de memoria, sino es-
tructuras de datos de tamaño variable, como vectores, listas o ficheros, en los
que ir almacenando los valores extraı́dos de las páginas para que puedan ser
posteriormente procesados. Cuando se almacenan las partes seleccionadas de
estos documentos en repositorios especializados, los datos seleccionados pue-
den ser convertidos a tipos de datos más fácilmente procesables habituales
en los lenguajes de programación, como números, booleanos, fechas, cadenas
de caracteres o, quizás, nodos de un árbol de documento.
En el caso de la navegación manual basada en browsers, el usuario es el
responsable de almacenar los datos y por ello es él quien decide cómo almace-
narlos. Normalmente los suele intentar memorizar o dejar en alguna ventana
abierta del navegador que posteriormente esté accesible para poderla volver
a leer, pero ello implica la necesidad de tener que volver a extraer de ella
nuevamente los datos cada vez que se deseen manipular, y la posibilidad de
perderlos si se siguen enlaces en la misma ventana. En el mejor de los casos,
pueden almacenarse en otras herramientas externas, pero ello implica una
ardua labor de estructuración con el fin de poder manipular eficientemente
grandes volúmenes de información. En el caso de la navegación automáti-
ca, al tratarse de un tratamiento especı́fico y dependiente de la estructura de
las páginas, de los datos, y de la tarea que lo va a utilizar, esta acción no
se encuentra pre-construida en una biblioteca genérica de la platafor-
ma, por lo que debe ser programada en las correspondientes sentencias de
almacenamiento en repositorios estructurados.
2.2.3. Seguimiento explı́cito de enlaces
Los datos en el Web se suelen encontrar distribuidos en múltiples docu-

mentos que, por lo tanto, deben ser recuperados. Para ello suele usarse el
protocolo HTTP, haciendo un seguimiento explı́cito de enlaces conforme a
la tabla 2.3. A veces las direcciones de esos documentos no son conocidas
a priori por el usuario, sino que tienen que ser obtenidas dinámicamente
desde otras páginas ejercitando la navegación. En los casos más sencillos,
bastará con visitar una dirección Web en la que se sabe que figuran los da-
tos que se desea consultar. En otros casos, es necesario establecer una sesión
desde la página principal del sitio Web de forma que hay que seguir varios
enlaces y rellenar varios formularios antes de acceder finalmente a la página
66
que contiene el dato.
En el caso de la navegación manual, el seguimiento explı́cito de enlaces
consiste en una labor semiautomática, asistida por el browser, donde la labor
del usuario se reduce a seleccionar y activar los enlaces que le interesan. En
el caso de la navegación automática, esta acción se encuentra ya comple-
tamente pre-construida en las primitivas de varias bibliotecas utilizables
desde distintos lenguajes de programación para lanzar comandos GET, por lo
que tı́picamente la labor de programación se reduce a parametrizar la llamada
a esta primitiva.
2.2.4. Rellenado de formularios
El rellenado de un formulario Web consiste simplemente en asociar uno

o varios valores a cada uno de sus campos (también es posible dejar algunos
de ellos vacı́os). Los valores con los que se rellenan esos campos (tal y como
viene expresado en la tabla 2.4) pueden venir definidos por el usuario, o
pueden venir predefinidos en el propio formulario, pero en cualquier caso es
el usuario el responsable de establecer aquellos valores que le interesen para
su tarea. Por otra parte, puede haber campos de formularios que no son
manipulados (porque no los ha querido rellenar) o que no son manipulables
(porque están ocultos al usuario), en cuyo caso, conservan el valor con el que
vinieron rellenados por defecto en el formulario.
En el caso de la navegación manual, se trata de una labor semiautomáti-
ca asistida por el browser, donde la labor del usuario se reduce a interactuar
con los campos de los formularios. En el caso de la navegación automática, al
tratarse de un tratamiento especı́fico y dependiente de la estructura del for-
mulario, y de la tarea que lo desee rellenar, esta acción no se encuentra
pre-construida en una biblioteca genérica de la plataforma, por lo que debe
ser programada en código definido por el usuario. Normalmente la compleji-
dad del rellenado de cada campo es dependiente de la estructura interna de
representación de ese formulario, pues es normalmente sobre ella donde se
realizan estas modificaciones para después proceder a la orden de envı́o del
formulario, según la siguiente acción explı́cita. En el mejor de los casos, con
una buena representación donde exista una lista de campos recorrible y unas
primitivas de modificación acordes con la semántica de cada campo, esa labor
puede realizarse en una simple lı́nea de código para cada uno de esos campos.
67
2.2.5. Envı́o de formularios
Una vez que un formulario se encuentra ya relleno, la información recogida

en él puede ser enviada al servidor para que sea procesada.
En el caso de la navegación manual, se trata de una labor semiautomáti-
ca, asistida por el browser, donde la labor del usuario se reduce a seleccionar
un botón de envı́o (en el caso en el que haya varios) y pulsarlo. En el caso de
la navegación automática, esta acción se encuentra ya completamente
pre-construida por las primitivas de varias bibliotecas utilizables desde dis-
tintos lenguajes de programación para lanzar comandos GET o POST, por
lo que tı́picamente apenas se necesita programar y parametrizar la llamada a
esta primitiva.
2.2.6. Procesamiento de datos
Una vez que los datos del Web han sido recuperados, y homogeneiza-
dos a un formato estructurado, su manipulación no dista de la que puede
haber en cualquier tarea de tratamiento de datos (no necesariamente invo-
lucrada en el Web). Operaciones tales como comparaciones, acumulaciones,
reordenaciones, operaciones aritméticas o lógicas o de procesamiento de tex-
tos pueden ser combinadas según las necesidades especı́ficas de manipulación
de información que requiera la tarea.
En el caso de la navegación manual, el procesamiento que tı́picamente
realizan los browsers a las páginas que recuperan del Web se limita a la mera
visualización en las pantallas de los ordenadores, facilitando, eso sı́, el control
de todos los aspectos visuales y permitiendo al usuario la posibilidad de
solicitar nuevos documentos del Web mediante el resaltado en la visualización
de zonas activables del documento por el usuario mediante teclado o ratón
para el seguimiento de enlaces. Cualquier otro tipo de procesamiento queda
delegado en el usuario.
Muchas veces, ciertamente, estos tratamientos de datos en el Web son
comparaciones sencillas o labores que manejan poca información, pero, cuan-
do el volumen de datos es algo elevado, o cuando el tratamiento que se pre-
tende realizar con esos datos empieza a incluir operaciones aritmético-lógicas
un poco más complicadas que las simples comparaciones detectables a simple
vista y que escapan del fácil cálculo mental, el procesamiento manual de esos
datos se convierte en una labor realmente tediosa.
En el caso de la navegación automática pueden definirse rutinas que pro-
68
cesen esos datos de otra forma más adecuada para las tareas. Mediante la
programación de rutinas definibles por el usuario, que reciban por argumen-
to los datos obtenibles durante la navegación, el tratamiento de estos datos
puede ser realizado por el ordenador. Simplemente deberán procesarse los da-
tos relevantes que se encuentran almacenados en repositorios programables,
conforme a los objetivos establecidos en la tarea. También es posible que
esos procesamientos puedan estar ya implementados en alguna herramienta
externa. En esos casos, el tratamiento consistirá en invocar a esa herramienta
como un proceso externo, enviarle los datos para que los procese y esperar de
ella los resultados. En el mejor de los casos, el procesamiento puede ser tan
sencillo como la simple impresión por pantalla de unos simples datos obteni-
dos, para lo cual es posible programar esos comportamientos con sentencias
sencillas dentro del mismo programa principal. La elección sobre dónde pro-
gramar este tipo de comportamientos dependerá de la complejidad de los
mismos, del hecho de que ya pudieran estar programados en algún programa
legado y de la capacidad del programador para reutilizar ese código.
En el caso de la navegación manual basada en browsers, el usuario es
el responsable de realizar este procesamiento de datos, normalmente de for-
ma mental y sin soporte por parte del browser. En el caso de la navega-
ción automática, al tratarse de un tratamiento especı́fico y dependiente de
los datos, y de la tarea que lo va a utilizar, esta acción no se encuentra
pre-construida en una biblioteca genérica de la plataforma, por lo que debe
ser programada en rutinas definidas por los usuarios, que no necesariamente
serán dependientes de la cambiante estructura de las páginas al haber sido
los datos convenientemente estructurados en una fase anterior.
2.3. Subsanación de las faltas de soporte de

la plataforma de navegación
Finalmente, tal y como se verá en el apartado 3, no todas las plataformas
tienen un soporte completo a la ejecución de aspectos de navegación. Por
ejemplo, muchas plataformas carecen de soporte a la interpretación de ruti-
nas JavaScript, que se encuentran habitualmente embebidas en las páginas
visitadas. En estas plataformas no está soportada, por lo tanto, la navega-
ción basada en JavaScript, en la que las URL que deben visitarse no figuran
explı́citas en los enlaces que se pretende seguir, sino que dichas direcciones
deben computarse por alguna rutina JavaScript activable por algún evento
provocado por el usuario con el ratón o el teclado. Para poder navegar en
69
estos sitios desde este tipo de plataformas, el programador debe subsanar
con sus propias lı́neas de código las acciones que simulen el comportamiento
de esas rutinas JavaScript. En otras plataformas no existe un conveniente
soporte de las cabeceras HTTP o una adecuada creación del conveniente
query-string a partir de cada formulario relleno, por lo que el usuario de-
be programar estos comportamientos implı́citos con su propio código. Todas
aquellas acciones que, no teniendo soporte en la plataforma, sean significati-
vas para la navegación, deben ser suplidas con código definido por el usuario.
Dicho código suele tener un coste significativamente elevado. Por esta razón,
y para minimizar este coste, es importante, por lo tanto, escoger una buena
plataforma de navegación.
Soporte de los browsers a las acciones básicas explı́citas
Tal y como puede verse en la tabla 2.5, en la navegación manual, el

browser da un soporte semiautomático a tres de las acciones más sencillas
(seguimiento explı́cito de enlaces y rellenado y envı́o de formularios), dejando
al usuario la responsabilidad de realizar las otras acciones sin ningún tipo de
asistencia por parte del browser. Desde la extracción de datos relevantes hasta
el procesamiento que pueda necesitar realizarse sobre esos datos, el usuario
que utiliza browsers es quien debe encargarse de todo.
70
Capı́tulo 3
Estado de la cuestión
En este capı́tulo se realiza un repaso de los principales conceptos y técni-

cas desarrolladas hasta el momento en el ámbito de la integración de datos
semiestructurados, ası́ como de otras técnicas, no ya de automatización de
tareas en el Web, sino, más genéricamente, de navegación automática en el
Web.
3.1. Consideraciones previas

Antes de comentar esos trabajos aplicados al tema especı́fico de la auto-
matización de tareas en el Web, conviene mostrar cómo algunos sitios Web
afrontan actualmente el uso de sus aplicaciones.
Algunos sitios Web, muy pocos en términos relativos, proporcionan

aplicaciones ejecutables alternativas a los browsers para proporciona-
lidad una mayor facilidad de manejo a aquellos usuarios que realizan
un número elevado de transacciones. En estos casos, lo habitual sue-
le ser que los desarrolladores de la aplicación proporcionen al usuario
una forma de acceso indirecto a la aplicación con la que interactúan
de forma que el interfaz no esté basado en el browser, sino que en un
programa ejecutable capaz de automatizar varias de estas transacciones
minimizando parcial, pero sensiblemente, la interactividad solicitada al
usuario. Por ejemplo, eBay [6] o el antiguo QXL (recientemente fusiona-
do con Aucland [1]) han proporcionado a sus mejores vendedores una
aplicación ejecutable (para uso exclusivo en entornos Windows) que
permite la publicación de múltiples subastas en la red con un sólo click
71
de ratón. Por otro lado, algunas operadoras de contratación de accio-
nes en bolsa, como por ejemplo Consors [4] proporcionan a sus clientes
una interfaz Java (normalmente un applet ejecutable en el navegador)
para facilitar a sus usuarios más activos una plataforma de introduc-
ción de órdenes de compra-venta más manejable que el browser cuando
se trata de un número elevado de operaciones o se requieren algunas
funcionalidades como información en tiempo real. Si bien la elección
de la plataforma tecnológica puede ser muy dispar (existen igualmente
soluciones basadas en controles ActiveX y otras variantes), lo cierto es
que este tipo de aplicaciones a veces no proporcionan una funcionalidad
completa, ya que en ocasiones se limitan las opciones de la versión in-
teractiva basada en HTML y en la comunicación a través del browser,
por lo que fácilmente pueden no contemplar todas las funcionalidades
que desean los usuarios.
Por otro lado, muchas de las páginas que necesitan ser accedidas, no
tienen una interfaz especialmente amigable cuando se les usa desde otro
tipo de browser distinto a aquél para el que han sido diseñadas. Dicho
de otra forma, sus páginas son poco accesibles.
En cualquier caso, pocos diseñadores de sitios Web están dispuestos a

facilitar que sus páginas sean navegadas por programas automatizados (ro-
bots) en lugar de por personas usando browsers. Sin duda influyen más ra-
zones sociológicas (miedo a perder atracción en la publicidad, miedo a que
los contenidos propios sean aprovechados por terceros para hacer negocio sin
que el verdadero propietario reciba beneficios, ...) que técnicas (miedo a ver
sobrecargada la capacidad de respuesta de los servidores).
3.2. Automatización de aplicaciones interac-

tivas
Sin duda, estos problemas (el de la menor funcionalidad de las opciones
no interactivas de las aplicaciones y el de la baja amigabilidad del interfaz de
algunas aplicaciones) afectan al ámbito de la automatización, pero no sólo
a la del Web, sino, en general, al de cualquier aplicación diseñada para ser
usada de forma interactiva. Dado que la problemática de la automatización
de aplicaciones interactivas [149] es anterior al nacimiento del mismo Web,
conviene sin duda analizar algunas de sus conclusiones más relevantes para
aprovechar ası́ la experiencia desarrollada.
72
3.2.1. Lenguaje Expect
Aunque existen múltiples trabajos enfocados en la automatización de

aplicaciones interactivas en varios entornos, de todos ellos destaca sin du-
da expect [84]. En expect, mediante la utilización de un nuevo lenguaje
de scripting especı́fico similar al de un shell, se permite realizar fácilmente el
control de programas interactivos lanzados en entornos Unix que estén prepa-
rados para leer del teclado de una terminal. A diferencia de una shell normal,
expect resulta especialmente útil para emular al usuario desde el teclado
cuando este tipo de fuente de datos no puede ser fácilmente redireccionado
a un fichero para lectura o cuando es necesario responder adecuadamente
a un prompt en un diálogo con la aplicación interactiva, con peticiones del
programa y respuestas que deben introducirse por teclado en el momento en
el que el programa interactivo las solicita.
Tal y como reza en ese trabajo, los tradicionales shells Unix tienen, sobre
las aplicaciones que invocan, un control que se limita a la creación, espera y
destrucción de procesos, ası́ como las opciones con las que deben ser invocados
al principio y el redireccionamiento a/desde ficheros pero no tienen apenas
control sobre aquellos programas que necesitan interactividad durante su
ejecución, dejando esa tarea relegada a que el usuario introduzca esos datos
desde teclado. Mediante una filosofı́a de lanzamiento de ejecuciones similar
a la de los shells, pero con extensiones para controlar la ejecución interactiva
de estos programas, aplicaciones que hasta ese momento sólo podı́an usarse
de forma interactiva, como telnet, ftp, passwd, rlogin, crypt, fsck, sudo
o incluso otras para las que podı́a emular al usuario ante otro usuario, como
por ejemplo talk, y en general, cualquier aplicación (incluyendo las que se
pudiera construir el usuario por su cuenta) que pudiera ser usada de modo
interactivo desde teclado, pueden ser controladas automáticamente desde un
programa capaz de entender y proporcionar los datos que cada una de esas
aplicaciones muestran y solicitan del usuario de forma interactiva. Para ello,
se emula al usuario sustituyéndolo por la aplicación de un conjunto de reglas
condicionales capaces de detectar los distintos casos de peticiones esperables
por las aplicaciones interactivas y ası́ asociar a cada regla un conjunto de
acciones de respuesta.
El lenguaje desarrollado en ese trabajo, llamado expect, actualmente ins-
talado en muchas distribuciones de sistemas Unix, está basado en la sintaxis
de TCL [97] y, entre las conclusiones reflejadas en [84] destaca, para ilustrar
su uso con un ejemplo, como el script de la figura 3.1, diseñado para controlar
mediante el diálogo interactivo con la aplicación Unix ftp el acceso a un sitio
ftp anónimo, sustituyó a un programa equivalente (que hacı́a lo mismo) es-
73
crito en lenguaje C, pero que tenı́a un tamaño aproximado de 60K. El script
de la figura 3.1 espera a recibir la palabra Name del programa ftp antes de
enviarle la palabra anonymous de la misma forma a la que espera a estar
identificado correctamente antes de lanzar una petición de transferencia de
ficheros.
#! /usr/bin/expect -f
spawn ftp [index $argv 1]
expect "*Name*"
send "anonymous\r"
expect "*Password:*"
send [exec whoami]
expect "*ok*ftp>*"
send "get [index $argv 2]\r"
expect "*ftp>*"
Figura 3.1: Script Expect para controlar ejecución interactiva de ftp
Quizá lo más llamativo de expect como lenguaje sea sin duda la gran di-
ferencia de tamaño existente entre la solución escrita en él y la escrita en C,
ambas para solucionar el mismo problema. La diferencia de tamaño se puede
justificar en el hecho de que C es un lenguaje de programación imperativo de
uso genérico, mientras que expect es un lenguaje de scripting de alto nivel
de programación y orientado al mantenimiento del control del diálogo con
cualquier aplicación y capaz de proporcionar distintas respuestas a la aplica-
ción dependiendo de lo que ella muestre a su salida. expect es, por lo tanto,
un claro ejemplo de lenguaje con un nivel de abstracción lo suficientemente
elevado como para poder ser usado casi a nivel de especificación de requisitos.
Sin embargo, un lenguaje para la automatización, pese a que disponga de
un alto nivel de abstracción, para poder ser aplicable a cualquier herramienta
interactiva, debe ser capaz de controlar aspectos de bajo nivel. Para mostrar
la flexibilidad del lenguaje expect en este sentido, el script de la figura 3.2
ilustra la capacidad de emulación de un usuario ficticio capaz de dialogar con
otro (en un diálogo muy sencillo, pero que podrı́a ser fácilmente adaptable)
mediante el uso de la conocida herramienta talk de entornos Unix. El nivel
de control de talk en este caso llega incluso a controlar aspectos como un
modelo de tiempos variables entre pulsaciones de las teclas, dando al usuario
que está al otro extremo de la comunicación la ilusión de que realmente
está dialogando con una persona pese a que en realidad no deja de ser un
programa que emula a un usuario. No ya en una aplicación como talk sino
en cualquiera donde el número de posibles salidas pueda ser conocido, un
conjunto completo de reglas y acciones que actúen en consecuencia pueden
74
automatizar completamente la gestión de una aplicación interactiva.
#! /usr/bin/expect -f
spawn talk usuario@dominio
set timeout 200
expect "*established*"
set send_human {.1 .3 1 .05 2}
send -h "This is only a test.. I swear \ Please don’t bust me with expect"
expect "*\r*"
exec sleep 5
send -h "Ok, well see ya tomorrow . Bye\n"
exec sleep 3
Figura 3.2: Script Expect para controlar ejecución interactiva de talk
En resumen, expect aporta, para el manejo de aplicaciones interactivas,

un lenguaje de scripting con las siguientes caracterı́sticas:
Alto nivel de abstracción
Con orientación al diálogo con aplicaciones existentes
Que reduce sustancialmente el tamaño y, por lo tanto el esfuerzo para

crear y mantener, de aplicaciones capaces de automatizar a otras
Capaz de automatizar prácticamente cualquier aplicación interactiva

textual (no gráfica)
Capaz de analizar la información que proporcionan las aplicaciones

interactivas y estructurar su comportamiento basándose en esos casos
Capaz de asociar acciones a cada uno de los casos que se espera que
proporcione la aplicación interactiva
Capaz de permitir al usuario gran flexibilidad para que defina sus pro-
pias reglas y sus propias acciones
Capaz de emular al usuario controlando aspectos de bajo nivel
Basado en la sintaxis de algún estándar conocido
Estas caracterı́sticas han sido tenidas en cuenta para la automatización

de tareas en el Web en el apartado 6.
75
3.3. Web Semántico
Uno de los grandes problemas del Web actual, desde el punto de vista
de su procesamiento automatizado, es que está basado principalmente en
HTML (formato difı́cil de entender por las máquinas al estar muy orientado
a la mera visualización conforme al apartado 1.4.3). Teniendo esto en cuenta
junto al hecho de que se espera que XML aún tarde varios años en implantarse
como formato para los documentos en el Web, desde el W3C se ha estado
promoviendo en los últimos años una ambiciosa iniciativa denominada el Web
Semántico [32].
El objetivo del Web Semántico es el de permitir la navegación automati-
zada por parte de programas capaces de entender el significado de los datos
que aparecen en las páginas del Web, gracias al hecho de que a éstas les acom-
pañan unos metadatos (tı́picamente basados en RDF [123] u OWL [140])
capaces de asociar un significado a cada una de las partes del documento,
describiendo con ontologı́as los datos que aparecen en las páginas Web. Las
páginas ası́ descritas con los correspondientes metadatos pueden ser asimila-
bles a bases de datos procesables por cualquier tipo de programa. Ası́ pues,
un agente inteligente basado en motores de inferencia capaces de procesar
los metadatos descriptivos de una página puede encontrar para el usuario la
información que satisfaga sus requisitos de búsqueda con un mayor criterio
que la simple búsqueda por palabras clave, cuando se busca en un conjunto
de páginas unidas entre sı́ por hiperenlaces.
Siendo el Web Semántico una opción realmente prometedora para el futu-
ro del Web y de la construcción dinámica de caminos de navegación, guiada
por la consecución de objetivos, lo cierto es que todavı́a es una tecnologı́a
incipiente a la que aún le falta por demostrar sus capacidades en entornos
complejos, habiendo sólo sido probada en entornos sencillos como [102]. En
[64] se cuestiona cómo un Web dinámico puede tener asociadas páginas de
metadatos estáticas, estableciendo diferencias entre las semánticas estáticas
de estos ficheros declarativos creados aparte por personas y las semánticas
dinámicas necesarias para manejar los datos del Web, que normalmente se
dan en el contexto de un lenguaje de programación, abogando ası́ por so-
luciones no precisamente declarativas. Por otro lado, las necesidades de los
usuarios son mucho más complejas que aquellas a las que puede dar res-
puesta un buscador. Una vez delante de la página en la que debe empezar
a trabajar, es necesario desarrollar una tarea cuyos pasos son normalmente
conocidos por los usuarios y no es necesario que sean deducidos.
En lugar de definir programas envoltorio, comúnmente conocidos como
76
wrappers para cada fuente de datos accedida, el Web Semántico propone la
utilización de programas de navegación genérica capaces de autoprogramar
su navegación a cualquier sitio Web conforme a la información suministrada
por los metadatos de ese sitio Web. Ello supone, en la práctica, delegar
cualquier automatización de tareas en la construcción de una adecuada meta-
información de un sitio Web, capaz de dirigir el comportamiento de estos
programas de navegación genérica por ese Web de forma similar a la que lo
navegarı́a un programa envoltorio.
El Web Semántico está en un estado aún inmaduro y carece del soporte
necesario de muchas herramientas. Por otro lado, la mayorı́a de las páginas
del Web también carecen de los correspondientes metadatos, y eso es algo
que tardará tiempo en paliarse aun cuando el Web Semántico recale en la
construcción de Webs. Por todo ello, es previsible que la utilización de las
técnicas del Web Semántico tardarán aún bastante tiempo en poder explo-
tarse masivamente en Internet para la automatización de tareas en el Web.
3.4. Mecanismos de construcción de progra-

mas de navegación automatizada
Los siguientes trabajos abordan de una u otra medida el tema de la au-
tomatización de la navegación en el Web.
En buena parte de los proyectos en los que se desarrollan trabajos para la
especificación de aplicaciones para la Web, la gran mayorı́a de los esfuerzos
se vuelcan en la especificación de aplicaciones accesibles desde el Web que
sean funcionales y no produzcan errores a sus usuarios. Ejemplos de esta
alternativa son XL [59] y Dicons [27] donde se definen lenguajes de especifi-
cación para la Web, pero en el lado del servidor, no en el lado de un cliente
que desee automatizar el uso de esas mismas aplicaciones. Otros trabajos,
como WebML [50] intentan aplicar el modelo Entidad-Relación de las bases
de datos relacionales a ciertas páginas del Web. Tal modelado resulta enri-
quecedor en el sentido de que aporta una visión muy descriptiva y detallada
del esquema de datos usado al publicar muchas de las páginas Web existen-
tes hoy en dı́a. Sin embargo, estas aproximaciones no son utilizables en los
casos en los que las páginas y los datos contenidos en las mismas no siguen
unas normas establecidas asimilables a las de un modelo Entidad-Relación.
WebML se presenta como una aportación desde el punto de vista de los di-
señadores Web y de la publicación estructurada y descriptiva de las páginas,
sin abordar el tema de la integración de datos semiestructurados por parte
77
de sus usuarios o lectores.
Ya en el terreno del desarrollo de clientes Web que naveguen automática-
mente, las herramientas más usadas para la automatización de la navegación
de enlaces en el Web suelen ser programas completos (disponibles con múlti-
ples opciones de ejecución) para descargar documentos del Web o realizar
otro tipo de acciones sencillas desde la Web superficial. Muy usado en este
sentido es Wget [20], pese a que sólo sirve para descargar documentos. Al-
gunas herramientas como Curl [5] permiten un uso más avanzado al ofrecer
al usuario la posibilidad de manejar también formularios además de enlaces,
eso sı́, solicitando al usuario datos de bajo nivel como el query-string que se
debe enviar, en lugar de crearlo él a partir de una estructura de datos que
represente a un formulario relleno. Estas últimas no ofrecen la posibilidad de
recibir establecido el guión de una sesión completa HTTP más allá de una
sola transacción, por lo que la secuencia de acciones de la tarea sólo puede
ser especificada desde fuera de la herramienta, mediante llamadas a la mis-
ma, tı́picamente en un lenguaje de intérprete de comandos (shell) del propio
sistema operativo, y siempre que no sea necesario el manejo de aspectos de
bajo nivel, como son las cookies [95].
Algunas herramientas, como Veriweb [30], sı́ son capaces de seguir más
de un enlace y formulario en una única ejecución, pero se limitan a realizar
pruebas de ejecución sobre herramientas accesibles desde el Web, siguiendo
sus enlaces y testeando que los caminos o tareas que cada una de esas aplica-
ciones permite realizar desde cada una de sus páginas no produzca errores en
la aplicación del servidor ni provoque que al cliente le lleguen páginas de error
(que son indeseables para muchos sitios comerciales porque menguan futuras
visitas al site). En cualquier caso, no permiten al usuario la automatiza-
ción de una tarea concreta, sino que recorren todos los caminos encontrables
probando con distintos datos para rellenar los formularios, por lo que sus
algoritmos de fuerza bruta no resultan adecuados para la automatización de
tareas condiderables de utilidad para los usuarios.
Por otro lado, existen varias bibliotecas [39, 35, 23, 112, 118] sobre varios
lenguajes de programación (Prolog, Perl, Java, C, ...) que sı́ permiten la
ejecución de una secuencia preprogramada de transacciones Web, combinada
a su vez con la extracción de datos desde documentos XML obtenidos por la
red. En ocasiones, más que bibliotecas para algún lenguaje de programación,
se proponen lenguajes propiamente de consulta para el Web [26, 51, 37,
93, 85]. Sin embargo, la gran mayorı́a de estas bibliotecas o lenguajes no
permite el diálogo con servidores del Web legado por su falta de manejo de
ciertas acciones implı́citas que realizan los browsers sin que el usuario sea
78
consciente de ello, como las mencionadas en el apartado 2.1. También suelen
aplicar técnicas de extracción de datos como son las expresiones regulares
y la definición de analizadores léxicos que tratan a esas páginas como texto
plano, sin estructura y que han sido utilizadas en trabajos como [47, 46, 57,
49, 100, 99, 98, 48, 45, 88]. Sin embargo, ninguna de estas soluciones propone
una extracción de datos semiestructudados basada en XPath. A lo sumo,
algunas de ellas, como [29, 80] definen sus propias primitivas de extracción
de datos, pero en ningún caso basadas en el estándar del W3C.
Otras técnicas, como [81, 54, 80] resuelven bien la parametrización de
acciones implı́citas (ver apartado 2.1). Sin embargo, dejan no muy bien cu-
biertos desde el punto de vista de la mantenibilidad, aspectos tan importantes
como lo es la extracción de datos del Web, una vez que la página que contiene
finalmente los datos ha sido recuperada.
Desde el punto de vista de las aportaciones hechas por el W3C, varias
técnicas, como XSLT [130] o DEL (Data Extraction Language) [133] han sido
propuestas para la obtención en formato XML de datos extraı́bles de otros
documentos XML mediante reglas de extracción y transformación. Ambas
definen etiquetas para crear fácilmente lenguajes de script que sean fácilmente
interpretables. Sin embargo, carecen de mecanismos para indicar la forma de
obtención de los documentos de los cuales deben extraerse los datos.
Por una parte, resulta interesante el enfoque que toman [54, 133, 130,
82] de definir lenguajes de programación sobre sintaxis XML en donde hay
etiquetas capaces de representar variables, bucles, condiciones, y otros tipos
de acciones. Este tipo de lenguajes de programación, definidos sobre esta
sintaxis es fácilmente interpretable por varios programas y muy fácilmente
analizable.
En el W3C, el tema de la extracción de datos se ha centrado últimamente
en la definición del lenguaje de consulta XQuery, una extensión de XPath 2.0
(en realidad un superconjunto) que permite la consulta para la extracción de
datos de cualquier documento XML, con funcionalidades avanzadas similares
a las de otros lenguajes de consulta de bases de datos relacionales, como SQL
[78]. Sin embargo, estas iniciativas, pese a que ofrecen muy buenas soluciones
para ese problema (de hecho ésa es la razón por la que en esta tesis se haya
partido de XPath 2.0 para crear un lenguaje de consulta y manipulación),
no se enfrentan al tema de cómo obtener los documentos XML del Web
ni tampoco acerca de cómo integrar los datos que aparezcan repartidos en
distintos documentos.
De entre los últimos proyectos más avanzados para ser aplicados al Web
legado, puede destacar [94, 111], en el que se aplican modernas técnicas de
79
extracción de datos semiestructurados a las páginas HTML, a páginas co-
rregidas con Tidy [104]. En [94] se usa XSLT y en [111, 25] se considera al
Web como una base de datos lo suficientemente estructurada como para po-
der usar lenguajes de consulta de bases de datos como XQL, un lenguaje de
consulta predecesor de XQuery. Gracias a herramientas como Tidy, algunos
usuarios pueden usar herramientas de evaluación de expresiones XPath como
[21] sobre el Web legado. Sin embargo, tres importantes factores no han sido
tenidos suficientemente en cuenta por estos trabajos.
En primer lugar, no solventan adecuadamente las dificultades que

afronta escoger XSL como lenguaje de manipulación de datos (se gene-
ran documentos de salida en lugar de manipular el árbol del documento
y permitir el almacenamiento de sus partes en repositorios programa-
bles).
En segundo lugar, no incorporan mecanismos de mejora a la robustez
ante fallos, como los muy convenientes Service Combinators [40], siendo
poco adecuados para la extracción de datos en páginas con estructuras
de marcado cambiantes e irregulares.
En tercer lugar, ninguno tampoco se ha enfrentado aún al uso del nuevo
borrador de XPath 2.0 definido por el W3C para este fin, que incluye
muchas e importantes mejoras respecto de la versión actual del estándar
que salió a la luz en 1999.
Otros trabajos, como RoadRunner [55], pretenden aplicar algoritmos para

generar automáticamente wrappers a partir de documentos de entrada. Pese
a que ello supone un interesante enfoque capaz de minimizar los problemas
de la generación manual y del mantenimiento de estos wrappers, la casi total
falta de estructura esperable en los documentos del Web provocan que este
tipo de soluciones sólo funcionen adecuadamente con ejemplos muy sencillos
y muy regulares en su estructura, lo cual no siempre se puede es fácilmente
encontrable en las aplicaciones del Web cuyo uso se desea automatizar.
Finalmente, uno de los más completos trabajos realizados hasta el mo-
mento en el campo de la integración de datos en el Web corresponde sin duda
a [31], donde se tienen en cuenta muchos factores adecuadamente escogidos
que facilitan el desarrollo de programas envoltorio por personas con pocas
capacidades de programación. Una herramienta de fácil utilización permi-
te dotar a estos programas de la conveniente robustez ante cambios en las
páginas, minimizando los costes de su mantenimiento. En ese trabajo, dos
lenguajes han sido desarrollados y soportados para dos propósitos bien dis-
tintos, pero complementarios entre sı́: la obtención de documentos del Web
80
(mantenimiento del diálogo en una sesión HTTP con servidores Web) y la
extracción de datos relevantes de cada uno de esos documentos. El primero
de los lenguajes, NSEQL, es un lenguaje de alto nivel de abstracción en el que
se indica la secuencia fija y preestablecida de acciones que deben activarse en
un módulo navegador, una tras otra, para obtener del Web los documentos
involucrados en una tarea. En dicha secuencia de acciones, se hace tı́pica-
mente una referencia implı́cita al elemento o documento activo seleccionado
por alguna acción anterior, de forma que, además de las acciones de segui-
miento de enlaces, envı́o de formularios y rellenado del valor de sus campos,
se contemplan otras más propias de la orientación a un browser como la
focalización de documentos, formularios o elementos que quedan selecciona-
dos como activos para que las siguientes acciones los puedan tomar como
referencia. Otro lenguaje, llamado DEXTL se encarga de extraer los datos
relevantes de cada una de esas páginas, de forma que el uso combinado de
ambos lenguajes permite la automatización de prácticamente casi cualquier
tarea en el Web.
Sin embargo, algunas caracterı́sticas de estos lenguajes podrı́an ser mejo-
rables.
Para empezar, DEXTL es un lenguaje desarrollado para un generador

de analizadores léxico-sintáctico propio, basado en expresiones regula-
res y en reglas gramaticales que indican la estructura esperada del texto
para ser ası́ correctamente reconocido y de esa forma poderle aplicar las
correspondientes reglas de extracción de datos. Una opción quizá más
interesante, podrı́a haber sido la de aplicar tecnologı́as como XPath
para poder seleccionar adecuadamente los nodos relevantes del docu-
mento. Ello supondrı́a cierta pérdida de flexibilidad (XPath no podrı́a
ser aplicable a cualquier fichero de formato textual, como DEXTL sı́ lo
permite), pero habrı́a proporcionado quizá un mayor grado de robustez
a las expresiones de extracción de datos en documentos HTML, puesto
que una expresión XPath ocupa tı́picamente una única lı́nea de código
fácilmente entendible, en lugar de las varias que se necesitan para poder
crear una expresión DEXTL equivalente.
Por otra parte, el API de primitivas desarrolladas para NSEQL está de-
masiado particularizado para los eventos propios de un navegador. Pe-
se a que proporcionan un avanzado esfuerzo por representar adecua-
damente en el correcto nivel de abstracción las acciones que forman
parte de la secuencia de eventos que un usuario genera con un browser
durante un proceso de navegación, es decir de acciones básicas como
las mencionadas en la tabla 2.5, este API podrı́a haber sido un poco
81
más simplificado, ortogonalizado para hacerlo independiente de los ele-
mentos concretos de HTML y sus posibles eventos, y reorientado a la
robustez. Dado que NSEQL no se basa en un modelo de datos como el
de XPath, sino en los elementos y documentos activos que un navega-
dor puede tener en cada momento, muchas de las funcionalidades del
API se basan en la aplicación de algún evento a algún tipo concreto de
elemento o atributo de HTML. Existe una función para seguir enlaces
de anchors, que sin embargo no sirve para seguir enlaces de otro tipo
de elementos, como areas (es decir, mapas de imágenes), que también
tienen enlaces que a veces interesa poder seguir.
La existencia de una referencia implı́cita al elemento o documento pre-

viamente seleccionado, y la ausencia de asociación explı́cita de nom-
bres a las páginas previamente visitadas, impide, por ejemplo, que una
misma página visitada con anterioridad a la página actual pueda ser
reutilizada sin tener que abandonar el contexto de la actual. Por ejem-
plo, dentro de un bucle en el que ciertas páginas con formularios deban
ser revisitadas para emprender con ellas el procesamiento de un nuevo
conjunto de datos en una labor repetitiva, resulta necesario emular la
acción Back del navegador, que puede implicar traerse una nueva ver-
sión de la página en lugar de reutilizar la que previamente habı́a sido
obtenida.
Por otro lado, buena parte de las funciones del API necesitan recibir
combinaciones de tres datos, tı́picamente un texto, un booleano y un
número entero, indicando que se desea escoger el enésimo elemento de
una lista de posibles que cumplan el tener al texto, bien contenido de
forma exacta, bien contenido como subcadena, bien como texto, bien
quizá en algún atributo concreto, todo ello dependiendo del argumento
booleano y del nombre concreto de la función a la que se invoque. Dicho
de otro modo, existen funciones para buscar elementos por texto o por
algunos atributos, pero no para seleccionar elementos que cumplan una
combinación arbitraria de cualquier nivel de complejidad con varios
de ellos, abstrayéndose de nombres concretos de etiquetas o atributos
particulares de HTML, como sı́ permiten los predicados de XPath.
Por otro lado, el rellenado de formularios se plantea igualmente con

un conjunto predefinido de funciones, cada una de las cuales permite
realizar una acción concreta y predefinida sobre un tipo concreto de
campo de formulario, cuando serı́a mucho más simple y flexible, aunque
quizá también de más bajo nivel, permitir la modificación genérica de
cualquiera de sus atributos. Por ejemplo, una de las funciones permite
82
rellenar un campo de texto de un formulario (modificando su atributo
value, se entiende). Otras funciones permiten seleccionar la opción de
una lista de opciones posibles. Por el contrario, no existen funciones
para cambiar otros tipos de atributos influyentes en los campos de
formularios, como checked o disabled.
En prácticamente casi todas las funciones, es imprescindible la indica-
ción de un número entero que indique la posición del elemento que se
desea direccionar dentro de una lista de otros que cumplan una serie
de caracterı́sticas. Ası́, por ejemplo, se puede seguir el séptimo enlace
de una página, por ejemplo. Sin embargo, el criterio de la posición de
un elemento dentro de su página es altamente sensible a cambios en
las páginas HTML, pues en el momento en el que la página del servi-
dor añada una nueva opción a la lista de opciones, las posiciones de
éstas se ve irremediablemente trastocada, provocando que en la labor
de mantenimiento de estos programas se deba proceder a la actuali-
zación de estos valores numéricos. Una selección basada en contenidos
independientes de posiciones es más robusta o, en cualquier caso, más
fácilmente mantenible.
En cualquier caso, el API está más orientado a los eventos que espera
recibir un browser gráfico como lo es Microsoft Internet Explorer, que al
propio diálogo HTTP que espera el servidor al que se accede remotamente,
puesto que no se dialoga directamente con el servidor sino que de delega esta
labor a este browser concreto. Sin embargo, el uso de un browser gráfico en
la plataforma de ejecución le aporta una indudable ventaja: y es que este
sistema tiene incorporada la ejecución de rutinas JavaScript, algo que no
tienen todas las plataformas de navegación automatizada.
3.4.1. Uso de APIs estándares

Por otro lado, programar con APIs estándares tampoco es una garantı́a
de éxito si ello implica la utilización inadecuada de la tecnologı́a. Por ejemplo,
en [115] se explica lo dificultoso que puede ser realizar un programa Java que
extraiga datos de un documento XML tan sencillo como el de la figura 3.3.
Un programa Java que use DOM y quiera extraer las direcciones (elemen-
tos address) de aquellas personas que coinciden con su argumento puede ser
el que aparece en la figura 3.4.
Teniendo en cuenta que existe una expresión XPath
//address[child::addressee[text() = ’Jim Smith’]] capaz de
83
<addressbook>
<address>
<addressee>John Smith</addressee>
<streetaddress>250 18th Ave SE</streetaddress>
<city>Rochester</city>
<state>MN</state>
<postalCode>55902</postalCode>
</address>
<address>
<addressee>Bill Morris</addressee>
<streetaddress>1234 Center Lane NW</streetaddress>
<city>St. Paul</city>
<state>MN</state>
<postalCode>55123</postalCode>
</address>
</addressbook>
Figura 3.3: Ejemplo de documento XML sencillo
public Node findAddress(String name, Document source) {

Element root = source.getDocumentElement();
NodeList nl = root.getChildNodes();
// iterate over all address nodes and find the one that has the correct addressee
for (int i=0;i<nl.getLength(); i++) {
Node n = nl.item(i);
if ((n.getNodeType() == Node.ELEMENT_NODE) &&
(((Element)n).getTagName().equals("address"))) {
// we have an address node, now we need to find the
// ’addressee’ child
Node addressee = ((Element)n).getElementsByTagName("addressee").item(0);
// there is the addressee, now get the text node and compare
Node child = addressee.getChildNodes().item(0);
do {
if ((child.getNodeType()==Node.TEXT_NODE) &&
(((Text)child).getData().equals(name))) {
return n;
}
child = child.getNextSibling();
} while (child != null);
}
}
return null;
}
Figura 3.4: Programa Java que extrae datos de documento XML con DOM
84
obtener la dirección completa de Jim Smith y que existen bibliotecas Java
capaces de evaluar expresion XPath, una buena opción podrı́a ser reescribir
en programa de la figura 3.4 por el de la figura 3.5.
public Node findAddress(String name, Document source) throws Exception {
XPathHelper xpathHelper = new XPathHelper();

NodeList nl = xpathHelper.processXPath(
"//address[child::addressee[text() = ’"+name+"’]]",
source.getDocumentElement());
return nl.item(0);
}
Figura 3.5: Programa Java que extrae datos de documento XML con XPath
Como puede verse, el programa resulta mucho más sencillo por hacer
uso de XPath. XPath, del que se detallan ventajas e inconvenientes en el
apartado 4.2, suele usarse normalmente embebido en un lenguaje anfitrión
que normalmente es XSLT. Una hoja XSLT que realiza lo mismo que el
programa Java anterior es la que aparece en la figura 3.6. Como puede verse,
una hoja XSLT puede ser también muy verbosa y demasiado compleja incluso
para tareas sencillas y saber escoger un estándar adecuado es primordial para
mantener bajo el coste de mantenimiento de los programas.
Por otro lado, XML-Binding [34] resulta una tecnologı́a novedosa pa-
ra la manipulación de documentos XML con un interfaz más simple que el
proporcionado por DOM. La idea principal de XML-Binding consiste en ge-
nerar clases compilables en un lenguaje de programación, tı́picamente Java,
automáticamente a partir de su descripción en XML Schema [134]. De es-
ta forma, los documentos que validen con ese XML Schema son fácilmente
procesables por objetos de la clase correspondiente. Ello es útil en entornos
donde DOM ofrece un acceso costoso a los programadores que quieren tener
una visión lógica de los datos en lugar de una visión en árbol del documento.
Su utilidad es aplicable especialmente en entornos donde los lenguajes XML
Schema son desconocidos a priori o pueden sufrir modificaciones, de forma
que esos cambios quedan ocultados por la aplicación generadora de clases.
Sin embargo, este tipo de trabajos no es directamente aplicable al Web legado
basado en HTML.
85
<?xml version=’1.0’?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:output method="xml"/>
<xsl:variable name="doc-file">http://mymachine.com/changed.xml</xsl:variable>


<xsl:template match="* | @*">
<xsl:copy><xsl:copy-of select="@*"/><xsl:apply-templates/></xsl:copy>
</xsl:template>

<xsl:template match="//address">
<xsl:param name="addresseeName">
<xsl:value-of select="addressee"/>
</xsl:param>
<xsl:choose>
<xsl:when test="document($doc-file)//addressee[text()=$addresseeName]">
<xsl:copy-of select="document($doc-file)//address[child::addressee[text()=$addresseeName]]"/>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>
Figura 3.6: Hoja XSLT que extrae datos de documento XML
86
3.5. Conclusiones del estado de la cuestión
La tabla 3.1 refleja un resumen de las tecnologı́as mencionadas en este
capı́tulo, comparando unas con otras respecto a varios criterios comunes. La
primera columna corresponde a las soluciones ad hoc, como [26, 51, 37, 93, 85],
basadas en expresiones regulares y en plataformas creadas especı́ficamente
para resolver problemas concretos. La segunda columna se corresponde con
la opción de usar un parser genérico tipo DOM al estilo del empleado en la
figura 3.4, utilizable en una biblioteca utilizable desde un lenguaje de pro-
gramación. La tercera columna, muy similar a la segunda, refleja la opción
de usar JavaScript circunscribiéndose a un browser, en tanto que también
usa DOM, salvo que con otra sintaxis distinta a la de Java. La cuarta opción
se corresponde con plataformas al estilo de Xalan [62], es decir, parsers tipo
DOM pero capaces de evaluar expresiones XPath, lo cual simplifica mucho
la labor de programación, tal y queda reflejado en la figura 3.5. La quin-
ta columna, se corresponde con la opción de usar WebL [80] y la sexta se
corresponde con los resultados de esta tesis a efectos comparativos.
Ad hoc Parser JavaScript Xalan WebL XPlore

Estándar Exp. Reg. DOM DOM XPath+DOM No MSC+XPath
Extracción Bajo Bajo Alto Alto Alto Alto
Navegación Alto Alto Browser Alto Alto Alto
Plataforma Mala Mala Browser Mala Media Buena
Simplicidad No No Sı́ Sı́ Sı́ Sı́
Rutinas Sı́ Sı́ Sı́ Sı́ Sı́ Sı́
Robustez No No No No Sı́ Sı́
Localización Sı́ No Sı́ Sı́ Sı́ Sı́
Legibilidad Mala Buena Buena Buena Buena Buena
HTML legado Ad hoc Tidy Sı́ Tidy Sı́ Tidy
XML Ad hoc Sı́ No Sı́ Sı́ Sı́
Cuadro 3.1: Resumen de las tecnologı́as utilizables
Como puede apreciarse, la extracción de datos presenta un bajo nivel de

abstracción cuando se emplean expresiones regulares o un parser tipo DOM
sobre lenguajes de programación convencionales (salvo la contada excepción
de JavaScript). A pesar de que todas las opciones presentan un nivel de abs-
tracción adecuado para representar las acciones navegacionales del protocolo
87
HTTP, pocas de ellas ofrecen un buen soporte a los aspectos de más bajo ni-
vel de dicho protocolo (acciones implı́citas mencionadas en el apartado 2.1),
por lo que no son utilizables para el establecimiento de sesiones con servido-
res Web. Por otro lado, aunque de uno u otro modo, sea posible la utilización
de rutinas de usuario para las acciones más complejas, no siempre es posible
definir de forma simple el comportamiento en las acciones más sencillas. Por
ejemplo, las soluciones ad hoc suelen basar casi todo su funcionamiento en
rutinas definibles por el usuario. En cuanto a la robustez ante fallos en la co-
nexión, pocas opciones ofrecen mecanismos de recuperación ante fallos. Por
otro lado, la facilidad de localización de las zonas de código afectadas por un
posible cambio en la estructura de las páginas puede ser complicada si se usa
un parser tipo DOM, (debido al alto número de lı́neas de código involucradas
en cada acción) teniendo en cuenta, no obstante, que su legibilidad suele ser,
pese a esa verbosidad, aceptable. Algo completamente distinto suele ocurrir
con las expresiones regulares, que suelen concentrar en una zona de código
muy concreta el lugar afectado por un cambio en las páginas, aunque sin
embargo proporcionan una mala legibilidad de las mismas debido a su bajo
nivel de abstracción. Finalmente, unas u otras opciones son aplicables a cual-
quier formato, tanto HTML del Web legado como XML, pudiendo requerir
para ello herramientas externas como [104].
Como resumen, las soluciones actuales mencionadas en este capı́tulo ado-
lecen de uno o varios de los siguientes problemas:
No basadas en estándares
La mayorı́a de los trabajos relacionados suelen afrontar el problema de la

integración de datos semiestructurados desarrollando lenguajes ad hoc para
propósitos especı́ficos, cada uno de ellos adaptado a sus propios propósitos
especı́ficos. La gran mayorı́a de ellos suelen estar basados en analizadores léxi-
cos basados en expresiones regulares, aplicadas sobre los documentos como si
fueran ficheros de texto plano, ignorando la estructura lógica de marcas del
documento, al contrario que como ocurre con la utilización de otros estánda-
res conocidos. Muchos de estos proyectos, o bien han sido abandonados, o
bien han tenido poco éxito o repercusión en la comunidad, o bien están sien-
do explotados bajo un elevado coste de mantenimiento. Por el contrario, una
solución basada en estándares resulta más fácilmente mantenible debido a
una mayor legibilidad y un mayor nivel de difusión.
88
Bajo nivel de abstracción
Los trabajos que sı́ suelen optar por una solución basada en estándares
suelen muchas veces tropezar con una inadecuada elección de la tecnologı́a
que va a utilizar. Ası́ pues, de los proyectos relacionados que sı́ han optado
desde un principio por la utilización de estándares XML en sus desarrollos,
la gran mayorı́a ha escogido usar tecnologı́as como SAX [86], DOM [131] (o
similares) [77, 72] o XSLT [130]. Cada una de estas tecnologı́as presenta dife-
rencias importantes en cuanto a la potencia, eficiencia y nivel de abstracción.
Por ejemplo, SAX tiene un nivel de abstracción muy bajo pero eficiente (útil
para tareas sencillas sobre datos voluminosos), mientras que el de XSLT es
más elevado. Por otro lado, DOM resulta ser la técnica más potente de las
tres, pero también la que requiere más conocimientos y experiencia, y por lo
tanto, dedicación y recursos. XSLT, diseñado como un lenguaje de especifi-
cación de transformaciones y, pese a su gran aceptación, resulta demasiado
sofisticado y verboso cuando las reglas de transformación que maneja adquie-
ren un poco de complejidad (muchos bucles, variables tipadas, condicionales
y expresiones calculando valores temporales para ciertos cálculos), en cuyo
caso un lenguaje de programación imperativo puede ser mejor opción. En
cualquier caso, estas tres tecnologı́as adolecen de un mismo problema, y es
que todas ellas comparten el hecho de requerir varias lı́neas de código para
una operación que en principio podrı́a ser considerada como sencilla.
Baja escalabilidad
Los sistemas desarrollados hasta el momento no intentan minimizar la

complejidad del código particularizado de acceso a los servidores Web (códi-
go envoltorio) [83], por lo que los sistemas desarrollables con estas técnicas
resultan ser muy poco escalables, es decir, muy costosos de desarrollar y
mantener en cuanto el número de servidores a los que se accede crece.
Baja adaptabilidad ante cambios
Los sistemas desarrollados hasta el momento no intentan favorecer, en

las aplicaciones desarrollables con ellos, la adaptabilidad ante cambios en las
páginas del Web. Por esa razón, es común, que estas aplicaciones desarro-
lladas con estas técnicas acaben dejando de funcionar por la aparición de
pequeños y frecuentes cambios, muchos de ellos incluso imperceptibles para
los usuarios si se accede con un browser.
89
Limitaciones en la capacidad de construcción
Buen número de funcionalidades, principalmente acciones implı́citas ne-

cesarias para mantener correctamente la sesión con servidores Web, no están
completamente contempladas por la gran mayorı́a de plataformas de desa-
rrollo existentes, por lo que muchos programas desarrollados acaban por no
poderse utilizar de forma efectiva en numerosos servidores del Web legado.
Alto coste de mantenimiento
Los productos tienen una vida corta, normalmente hasta que el Web al
que acceden cambie algo que rompa con las suposiciones establecidas implı́ci-
tamente por el programador del código envoltorio, por lo que necesitan ser
revisados cada poco tiempo, siendo además costoso localizar y corregir en
el código del programa el cambio que ha provocado que la aplicación ha-
ya dejado de funcionar. Como el Web es un ente cambiante que evoluciona
dinámicamente, resulta bastante imprevisible el momento en el que se va a
detectar un fallo o el impacto que un cambio va a suponer en un algoritmo
de navegación.
Navegación superficial
El denominado deep Web [110, 105], esto es, el Web obtenible del vol-
cado de bases de datos, está aún por explotar convenientemente, ya que los
sistemas de navegación existentes apenas permiten seguir enlaces fácilmente
obtenibles, como los que tienen una URL estática o aquellos para los que no
hace falta rellenar apenas formularios.
3.6. Limitaciones de las tecnologı́as actuales

Buena parte de los proyectos que abordan el tema de la automatización
de la navegación en el Web, al igual que este trabajo, reconociendo igual-
mente que quizás los beneficios de iniciativas como las de XML o la mejora
de la accesibilidad tardarán en poderse apreciar, plantean sus propias solu-
ciones directamente sobre las páginas HTML del Web legado. Buena parte
de esos trabajos plantean sus principios considerando a las páginas Web co-
mo ficheros de texto plano, de forma que a las páginas Web obtenidas se les
extraen los datos aplicando patrones basados en expresiones regulares ba-
90
sadas en el código HTML que rodea a cada dato que se desea extraer. Si
bien la aplicación de expresiones regulares resulta ser una técnica lo sufi-
cientemente potente como para poder ser aplicada también a otros tipos de
formatos textuales, lo cierto es que las expresiones regulares resultan ser una
técnica de bajo nivel de abstracción, donde, toda vez que pequeños aspectos
sintácticos tales como la aparición inhabitual de múltiples espacios en blanco
o fines de lı́nea, la ambivalencia de comillas dobles y simples, la indistinción
de mayúsculas y minúsculas o el orden de aparición de los atributos de una
etiqueta hayan podido ser superados, la legibilidad de esas expresiones se
complica notablemente. Por otro lado, mediante el uso de esas expresiones
regulares, la estructura de árbol de la página HTML no es considerada. Este
hecho puede no suponer un problema si la estructura de la página HTML y
la consulta que se le desea efectuar son lo suficientemente simples. No obs-
tante, es deseable a veces poder aplicar patrones de extracción de datos a
determinados fragmentos especı́ficos de la página, es decir, a cierto número
de subárboles que cumplan determinadas propiedades (porque se sabe que
sólo se desea buscar en determinadas zonas relevantes de la página), en lugar
de a todo el documento. Para estos casos, las expresiones regulares resultan
ser bastante limitadas.
Los últimos proyectos que abordan estos problemas han descubierto en la
familia de especificaciones XML una tecnologı́a adecuada con el que poder
enfrentarse al problema anterior de una forma mucho más elegante y robus-
ta. Para poder aplicar este tipo de soluciones se necesita, no obstante, de un
software capaz de reparar los errores sintácticos habituales en una gran can-
tidad de páginas Web. Dichos errores sintácticos, tales como la falta de cierre
de etiquetas, el incorrecto anidamiento de las mismas o la ausencia de en-
trecomillado en los atributos deben ser corregidos en las páginas según éstas
van siendo obtenidas de los servidores. Los documentos HTML ası́ obtenidos
quedan transformados en sus equivalentes documentos XHTML [117] antes
de poder aplicarles cualquier técnica XML. Si bien existen numerosos progra-
mas [58, 146] capaces de obtener una versión de la página donde se cumplan
los principios de buena formación de XML, esto es, conforme a la sintaxis
básica de XML, la herramienta Tidy [104] suele ser la más habitualmente
usada.
Los pocos trabajos que emplean el enfoque de reparación sobre la marcha
de la sintaxis de los documentos (con herramientas como [104, 58, 146]), sue-
len aplicar a las páginas Web obtenidas, una vez ya corregidas, bien parsers
tipo DOM [131] sobre los que aplicar directamente código programado en len-
guajes convencionales de programación (tı́picamente Java), o bien hojas de
estilo XSLT [130] para extraer de las páginas la información que les interesa.
91
Cuando las hojas de estilo XSLT no ofrecen toda la funcionalidad deseable
para el problema que desean afrontar, estos sistemas suelen permitir la apli-
cación de funciones de usuario escritas en algún lenguaje de programación
convencional. Si bien la estructura declarativa de las hojas XSLT permite de-
finir un gran número de tratamientos aplicables a los documentos XHTML
de entrada, muchas veces el tratamiento aplicable a ciertas páginas requiere
algo más que la simple extracción de datos en documentos de salida. Esa
extracción por sı́ sola puede ser suficiente en tareas simples de recuperación
de información, pero es insuficiente en aquellas tareas que deban manejar es-
tructuras de datos que recopilen datos del usuario, como son los formularios.
En ocasiones resulta necesaria la manipulación mediante inserción y borrado
de nodos y/o atributos o la manipulación repetida de esos atributos en un
mismo documento. Los formularios Web son muchas veces un claro ejemplo
que demuestra, para la tarea de ser rellenados múltiples veces, la necesidad de
una manipulación sencilla y eficiente de pequeñas partes de un documento,
donde la referencia de un único árbol accesible representativo del documento
sea constantemente visible sin la necesidad de estar creando y destruyendo
subárboles mediante la aplicación de sucesivas hojas XSLT.
Si bien XSLT es una solución entendible por numerosos programadores, el
actual borrador de XPath 2.0 [141] está suponiendo serios replanteamientos
acerca de lo que se espera que serán las futuras versiones de XSLT. Gran
parte de la expresividad de XSLT 1.0 está sustentada en la capacidad de
la robusta extracción de datos de XPath 1.0. XPath 2.0, gracias a la incor-
poración de nuevos operadores que no aparecı́an en la anterior versión y su
integración dentro del marco de XQuery [142] como lenguaje de consulta,
está constituyéndose como un potente mecanismo de direccionamiento de
datos en documentos XML, suficiente por sı́ mismo como para no necesitar
la funcionalidad extra de XSLT a la hora de realizar integradores de datos
semiestructurados. De hecho, XPath puede considerarse, a pesar de ciertas
limitaciones de las que adolece, como un mecanismo de extracción y direc-
cionamiento de mayor nivel de abstracción que el mero uso de expresiones
regulares. Una de las contribuciones de este trabajo, de hecho, consiste, apar-
te de una plataforma de implementación que evalúa expresiones del borrador
de XPath 2.0, en un conjunto de extensiones propuestas para extender XPath
2.0 con el fin de convertirlo en un lenguaje completamente funcional y eficaz
para esta labor y otras, como la manipulación de documentos.
Por otro lado, buena parte de los trabajos relacionados mencionados en
la bibliografı́a han hecho uso de clientes simples del protocolo HTTP, la ma-
yorı́a de ellos disponibles fácilmente desde diversas bibliotecas o programas
y en diversos lenguajes de programación. Si bien la mayorı́a de ellos son ca-
92
paces de proporcionar una funcionalidad básica aceptable, lo cierto es que
muchas de las técnicas actualmente empleadas por algunos servidores Web
para mantener el concepto de sesión con los clientes que a ellos se conectan,
resultan no ser tenidas en cuenta por estas soluciones. Si bien las cookies
suelen tener un comportamiento genérico normalizado y es posible su fácil
implementación en los clientes HTTP al estar bien recogidas y localizadas
entre las cabeceras de este protocolo, otras técnicas, como ciertos identifica-
dores de sesión, que se pueden encontrar ocultos entre los parámetros de las
páginas Web, pueden fácilmente hacer malfuncionar el comportamiento de
un cliente HTTP que no los contemple debidamente. Dicho de otro modo, los
actuales clientes HTTP utilizables para los procesos de navegación automáti-
ca tienen un bajo nivel de soporte para el conjunto de acciones implı́citas que
otras herramientas como los browsers gráficos sı́ realizan bien. Cabe destacar
que aquellos enlaces que no figuran explı́citos según las habituales normas
de HTML, sino que funcionan como resultado de la computación de algu-
na rutina de JavaScript o similares, resultan especialmente problemáticos en
tanto en cuanto prácticamente no existe ningún tipo de soporte para estos
lenguaje en muchos de estos clientes HTTP. Ello provoca que para muchos
usuarios la única forma de acceder a determinados contenidos sea a través
de un browser.
Existen numerosos proyectos que han abordado la temática de la navega-
ción automática y de la integración de datos del Web a lo largo de los últimos
años. Todos ellos, incluyendo el presente, se centran en la creación de wrap-
pers o código de programa especializado en el tratamiento particularizado de
cada fuente de datos. Afrontar el problema desarrollando un único programa
capaz de navegar en cualquier sitio Web, capaz a su vez de solventar todas
las heterogeneidades de cada servidor, resulta algo impracticable en tanto en
cuanto se necesita para ello introducir semántica necesaria para poder au-
todetectar la información necesaria para la navegación, manejando aspectos
como sinónimos y reconociendo al momento los enlaces que se deben seguir
y los formularios (campos incluidos) que se deben rellenar, lo cual resulta
demasiado complicado incluso para tareas sencillas. El Web Semántico es
una buena alternativa que intenta basar este reconocimiento semántico en el
uso de metadatos que permitan ser utilizados para la deducción acerca de
cómo efectuar las acciones básicas explı́citas de la navegación (ver apartado
2.2). Sin embargo, el Web Semántico aún tiene importantes flecos que deben
resolverse, y, en cualquier caso, no parece estar enfocado al Web legado, sino
a un nuevo Web creado a partir de esos metadatos.
93
94
Capı́tulo 4
Selección de tecnologı́as para la

automatización de tareas en el
Web
En este capı́tulo se realiza un análisis acerca de las tecnologı́as concretas

que han sido estudiadas para ser utilizadas en este trabajo y que de alguna
u otra manera han planteado alguna contribución para facilitar la automati-
zación de tareas en el Web. Todas ellas ya existı́an antes de la realización de
este trabajo y pueden ser consideradas como estándares en sus respectivos
campos de actuación, razón por la cual, este capı́tulo no presenta una con-
tribución especial a esas técnicas, sino tan sólo una breve descripción de las
mismas. Si acaso, una contribución original de este trabajo sı́ puede consistir
en la adecuada combinación de cada una de ellas para resolver de la mejor
manera posible el problema de la automatización de tareas en el Web, pero
eso es algo que aparece desarrollado en los capı́tulos 5 y 6. Buena parte de
las ideas reflejadas en esos capı́tulos proceden de las tecnologı́as descritas en
éste.
Estas técnicas están clasificadas en un método formal (Message Sequence
Charts), cinco estándares del W3C, algunos de ellos ya evolucionados, como
DOM, o XSLT (aunque existen borradores más avanzados de la versión que
ha sido objeto de este estudio), otros aún en fase de borrador, como XPath
2.0, XPointer y XQuery, y finalmente un estándar de facto como lo es el inter-
faz SAX para programación sobre XML orientada a eventos. Hay que añadir
que éstas no han sido las únicas tecnologı́as que han influido en el diseño
de la solución propuesta en esta tesis para la construcción de agentes Web.
Otras tecnologı́as como el lenguaje de programación WebL o las expresiones
95
regulares con las que se pretende contemplar el vacı́o que en ese aspecto tiene
XPath, han influido igualmente realizando su propia aportación.
4.1. MSC
Los Message Sequence Charts o Cuadros de Secuencias de Mensajes son

representaciones gráficas de especificación de requisitos de diseño de sistemas
concurrentes y que muestran el intercambio temporizado de mensajes entre
los componentes de un sistema. Los MSC constituyen representaciones abs-
tractas, capaces de ser usadas en muy diversos ámbitos y siendo además fáci-
les de entender por mucha gente, incluso no expertos. Aunque en su nacimien-
to, los MSC estuvieron inicialmente pensados para representar el intercambio
de señales entre componentes electrónicos de sistemas de telecomunicaciones,
su incorporación a los formalismos establecidos por la ITU (International Te-
lecommunication Union) de la mano de otro formalismo bien conocido como
SDL (Specification and Description Language) [75] supuso una gran acep-
tación por muy diversos colectivos y muy variados usos, llegando a realizar
importantes aportaciones al mundo de la ingenierı́a del software, como lo
demuestra su decisiva influencia sobre la representación gráfica de los dia-
gramas de secuencia de UML [108], que pueden ser considerados como una
versión orientada a objetos de los MSC con pequeñas diferencias que están
intentando ser solventadas por las revisiones de ambas especificaciones. En
esa misma referencia bibliográfica se apunta, por ejemplo, que los diagramas
de secuencia son una particularización algo más práctica y orientada a la pro-
gramación con objetos, mientras que los MSC tienen un fundamento mucho
más teórico, vienen acompañados de una semántica formal y son aplicables
a más campos que el de la orientación a objetos. De hecho, los MSC pueden
aplicarse en otros muchos contextos aparte de los ya contemplados por SDL.
Además de la importancia que conceden a la representación gráfica, los
MSC incorporan la valiosa aportación de poder ser representados textual-
mente, de forma que resultan igualmente modificables y analizables por he-
rramientas no gráficas. Dicha representación textual sirve de base para la
definición de la semántica formal que incorporan los MSC y que les permite
estar sujetos a la demostración automatizada de algunas propiedades de los
escenarios reproducidos, como por ejemplo la imposibilidad de que determi-
nado mensaje A sea enviado con antelación a la recepción de otro evento en
el sistema, como la recepción de otro mensaje B en algún otro componente
o la ejecución de alguna acción.
96
Los MSC se han convertido en una potente técnica de especificación del
comportamiento de un sistema desde el punto de vista de las interacciones de
sus componentes. Al ser fácilmente entendible por no expertos en programa-
ción, suelen formar parte de los documentos de especificación de requisitos
que se intercambian ingenieros y analistas con sus clientes, constituyendo una
representación visual muy descriptiva de la interacción bajo distintos esce-
narios entre diversos componentes, especialmente entre aquellos que forman
parte de un sistema distribuido. Los MSC pueden ser usados desde los pri-
meros pasos del diseño del software, gracias a lo cual, los errores detectados
mediante su uso adelantado son resueltos con un menor coste que en etapas
posteriores. En los últimos tiempos se ha motivado mucho el desarrollo de
algoritmos para una variedad de análisis de MSC consistentes en la detec-
ción de condiciones de carreras, conflictos de tiempos, toma de decisiones no
locales, o incluso capacidad de generación de autómatas finitos concurren-
tes que simulen el sistema modelado por el MSC, por lo que son varias las
herramientas utilizables para analizar los problemas derivables en etapas de
diseño gracias al examen de los MSC.
Desde el año en el que nacieron (1992) hasta la actualidad, los MSC
ha venido incorporando nuevas funcionalidades en sucesivas ampliaciones re-
visadas por la ITU, la entidad que lo ha estandarizado. Los MSC se han
convertido en una tecnologı́a particularmente útil en el modelado de las in-
teracciones propias de protocolos en las comunicaciones, ası́ como también
para la representación de llamadas a procedimientos o métodos, incluyendo
RPC. Su interés ha suscitado también en los últimos tiempos, el desarrollo de
herramientas capaces de transformar representaciones de MSC en otros tipos
de formalismos de especificación, como SDL, Statecharts [71], o Promela [73].
Incluso, los MSC ya han sido empleados como método de especificación en el
desarrollo de aplicaciones alojables en servidores Web, como ocurre con [27].
Los MSC presentan mejores habilidades para representar aspectos de inte-
racción, intercambio de mensajes y concurrencia que otros métodos formales
para el caso del Web frente a otros métodos formales como LOTOS [33],
Estelle [116] or SDL [75].
A continuación se mencionan los componentes más importantes que se
pueden encontrar en un MSC.
4.1.1. Entidades
Están representadas por lı́neas verticales, y modelizan cada uno de los
componentes (hardware o software) que forman parte del sistema. Las lı́neas
97
verticales que representan a los componentes sirven a su vez como eje tempo-
ral, de forma que aquellos eventos que se representan en la parte superior del
dibujo de un componente le suceden a éste con anterioridad a los que están
representados en las partes inferiores. Ello implica que ningún mensaje debe
ser enviado o recibido y ninguna acción debe ser ejecutada por un componen-
te del sistema hasta que, desde el punto de vista de su representación gráfica,
no se hayan procesado todos los eventos anteriores que consten previamente
en su representación. Una representación de tres entidades puede encontrarse
en la figura 4.1.
Figura 4.1: Entidades de un MSC
4.1.2. Mensajes
Están representados por las flechas, horizontales o diagonales, que nacen
de una entidad y mueren en otra. El esquema permite a su vez la repre-
sentación de mensajes intercambiados con el entorno externo del sistema
representado, ası́ como posibles mensajes enviados perdidos por el camino
e incapaces de llegar a sus destinos. Un mensaje representado por una fle-
cha horizontal entre dos componentes indica que su tiempo de latencia es
poco considerable, mientras que otro mensaje que aparezca con mayor dia-
gonalidad representa un mayor retardo desde el momento del envı́o por el
componente emisor hasta el momento de la llegada al componente receptor.
Una representación del intercambio de mensajes entre varios componentes
puede encontrarse en la figura 4.2.
4.1.3. Acciones
Otros tipos de elementos representables en un MSC lo constituyen las
acciones que cada componente puede realizar sin interacción con las demás
entidades, consistentes en cómputos internos. Estos procesamientos de datos
pueden ser realizados para dar respuesta a una petición codificada en un
98
Figura 4.2: Mensajes de un MSC
mensaje, para preparar el lanzamiento de nuevos mensajes que ser lanzados

a otras entidades, o para analizar el resultado de respuestas recibidas. Las
acciones se representan en los MSC con rectángulos. Las acciones pueden
involucrar la ejecución de sentencias como llamadas a funciones o procedi-
mientos ejecutados por la propia entidad y sólo se consideran terminadas
cuando los cómputos terminan o esas llamadas a funciones o procedimientos
retornan. Una representación de una acción ejecutada entre la recepción de
un mensaje a y el envı́o de una respuesta b puede contemplarse en la figura
4.3.
Figura 4.3: Acciones de un MSC
4.1.4. Temporizadores
Si bien el eje vertical de cada uno de los componentes de un sistema
representa la secuenciación relativa de los eventos que suceden en ese com-
ponente, lo cierto es que en dicho eje no existe medida alguna que represente
temporizaciones ni medidas acerca del momento exacto en el que se espera
que ocurran los eventos. En un MSC se refleja el orden posible de los eventos
que ocurren globalmente en el sistema, pero no necesariamente se dan medi-
das acerca de los tiempos que deben transcurrir entre dichos eventos. En la
figura 4.3 aparece claramente representado un sistema de dos entidades i y j
de forma que presentan el requisito de que, en primer lugar, la entidad j envı́a
99
un mensaje a a la entidad i, la cual realiza una acción y a continuación envı́a
un mensaje de respuesta b a la entidad j. Sin embargo, en ningún lugar del
modelo aparecen restricciones acerca de cuál debe ser el tiempo transcurrido
entre dichos eventos, ni es tampoco predecible ni acotable el tiempo existente
entre el envı́o del mensaje a y la recepción del mensaje b por la entidad j.
Para poder contemplar en el modelo la duración máxima de estos interva-
los entre eventos, los MSC permiten definir temporizadores, de forma que al
vencimiento de un temporizador en una entidad se pueda provocar el com-
portamiento de una acción especial en dicha entidad que haga un tratamiento
de la situación. Los MSC ofrecen para ello operadores para crear y desactivar
temporizadores, ası́ como una marca para señalar el evento de activación del
temporizador. Distintos tipos de operadores de temporizadores, cada uno de
ellos nombrado con un nombre distinto, y para los cuales hay distintos com-
portamientos representados (establecimiento, desactivación, vencimiento, ...)
pueden contemplarse en la figura 4.4.
Figura 4.4: Temporizadores de un MSC
4.1.5. Corregiones
En ocasiones, el orden de los eventos de un MSC no está completamente
determinado, sino un conjunto de eventos pueden ocurrir en cualquier or-
den, de forma no determinista. En aras de que las representaciones sean lo
suficientemente flexibles y permitan representar en un mismo gráfico todas
las posibles variantes de esas ordenaciones, tı́picamente atribuibles a aspec-
tos no controlables como retrasos impredecibles en las comunicaciones, en
la recepción o el envı́o de varios mensajes, los MSC permiten la definición
de zonas especı́ficas en las entidades, llamadas corregiones representadas por
fragmentos dibujados con trazos discontinuos en las entidades, de forma que
100
los mensajes que parten o llegan a una corregión pueden ser enviados o re-
cibidos en cualquier orden posible respecto del resto de los eventos definidos
dentro de la misma corregión. Ası́ pues, dentro de una corregión con n even-
tos, se estarán representando los n! casos posibles de ordenación de una sola
vez. Un ejemplo de corregión definida para el componente j puede contem-
plarse en la figura 4.5.
Figura 4.5: Corregiones en un MSC
4.1.6. Condiciones
Una condición es el cumplimiento de una expresión de verdad, y sirve para
indicar que el sistema ha entrado en un cierto estado. Una condición, que
desde el punto de vista de programación se puede asociar con una expresión
booleana, puede afectar a más de una entidad en un sistema. El sı́mbolo de
condición en un MSC, que es un hexágono, aparece superpuesto a todas las
entidades a las que afecta. Las demás entidades no afectadas por la condición
se dibujan sin intersecar con el sı́mbolo de la condición, o bien aparecen
superpuestas a él. En la figura 4.6 aparece representado un MSC donde la
primera condición afecta a las entidades i y k, la segunda condición afecta
sólo a la entidad i y la tercera condición afecta a todas las entidades del
sistema.
4.1.7. Creación y destrucción dinámica de entidades

Las entidades pueden estar creadas antes del momento del que parte el
modelado del MSC y seguir existiendo después del momento en el que termina
el modelado. En ese caso, se las considera entidades de creación estática, y su
creación y destrucción no forma parte del modelado del sistema. No obstante,
algunas entidades también pueden ser creadas y destruidas dinámicamente
101
Figura 4.6: Condiciones de un MSC
en tiempo de ejecución, dentro del modelado del sistema, como por ejemplo,
como respuesta a algún tipo de evento. Tanto la creación como la destrucción
de este tipo de entidades puede ser representada en un MSC fácilmente. La
creación de mensajes se representa con una flecha discontinua desde la enti-
dad creadora (la que invoca la creación) a la entidad creada (la que aparece
como resultado de la invocación anterior). La destrucción de mensajes se re-
presenta al final de cada entidad con unas aspas en forma de cruz, momento
a partir del cual, la entidad deja de existir. Una representación de la creación
de dos entidades y la muerte de dos de ellas puede contemplarse en la figura
4.7.
Figura 4.7: Creación y destrucción dinámica de entidades en un MSC
102
4.1.8. Expresiones inline
Una expresión inline es una parte especial de un MSC sobre la cual
está definido un operador que conjuga la forma en la que deben aparecer
los eventos que forman parte de la expresión. Por ejemplo, una expresión
inline de bucle indica que los eventos que forman parte de ella pueden ser
ejecutados en secuencia varias veces.
Existen varios ejemplos posibles de operadores, que aparecen en la ta-
bla 4.1. Por ejemplo, existen operadores para indicar que dos o más partes
de un MSC deben ejecutarse en paralelo (concurrentemente), o para indicar
que, de varias partes de un MSC, se debe escoger sólo alguna, quizá incluso
dependiendo de una condición que determine cuál es la parte que responde
al modelado de los siguientes eventos. Existen operadores también para in-
dicar repetitividad, es decir, que la secuencia de eventos producidos en un
fragmento de un MSC se deben repetir varias veces hasta que se cumpla una
condición de salida del bucle.
Expresión inline Significado

alt Bloques alternativos
loop Bucle
opt Bloque opcional
par Acciones ejecutadas concurrentemente
exc Excepciones
Cuadro 4.1: Tipos de expresiones inline
Las expresiones inline están representadas por rectángulos, donde los ope-
randos están separados por lı́neas horizontales discontinuas, y donde el nom-
bre del operador aparece en la esquina superior izquierda del rectángulo. Las
estructuras inline pueden anidarse unas dentro de otras. Una representa-
ción de varias expresiones inline de un MSC, una de ellas anidada dentro de
otra, puede contemplarse en la figura 4.8.
4.1.9. Descomposición modular

Es habitual que en los sistemas más complejos, el nivel de complejidad
de un MSC presente dificultades de legibilidad en la representación gráfica.
103
Figura 4.8: Expresiones inline en un MSC
El número de eventos y de expresiones inline puede fácilmente llegar a ser

demasiado grande, o la estructura de anidamientos puede presentar dema-
siados niveles, por lo que suele ser necesario simplificar la representación con
construcciones más sencillas, encapsulando las partes de más bajo nivel para
que puedan ser convenientemente referenciadas, de la misma forma en la que
se usan procedimientos y funciones en los lenguajes de programación. Des-
de el punto de vista de los MSC, la solución habitual consiste en distribuir
la información del modelo en varios MSC más simples de forma que unos
puedan ser referenciados por otros. Tales referencias se representan con unos
rectángulos con las esquinas redondeadas, cubriendo dichos rectángulos aque-
llas entidades que intervienen en el MSC referenciado. Una representación de
un MSC que referencia a otros dos MSC externos puede contemplarse en la
figura 4.9.
La figura 4.10 representa un ejemplo de MSC en el que se combinan varios
de los elementos anteriores.
4.2. XPath
XPath es una recomendación del W3C para el direccionamiento de datos
en documentos XML. El actual estándar es la versión 1.0 [129], recomendada
desde noviembre de 1999. No obstante, a lo largo de los últimos años los
grupos de trabajo del W3C de XML Query y de XSL han estado trabajando
104
Figura 4.9: Referencias a otros MSC
Figura 4.10: MSC
105
en una nueva versión del estándar, la versión 2.0 [141], que actualmente
está todavı́a en fase de borrador.
Sin llegar a tener toda la funcionalidad de un lenguaje de consulta tan
potente como XQuery (ver apartado 4.5), XPath permite una especificación
clara y funcional de consultas de datos en documentos y colecciones de ele-
mentos XML, pudiendo por tanto ser utilizable para las labores de extracción
de datos mencionadas en el apartado 2.2.1. La expresividad de XPath permi-
te que las especificaciones de expresiones de consulta sean lo suficientemente
potentes como para resolver la mayorı́a de las consultas usando apenas una
expresión simple y fácilmente entendible que ocupa normalmente una úni-
ca lı́nea de texto. Ello ha permitido, por ejemplo, que actualmente se utilice
XPath como lenguaje de consulta en bases de datos XML tales como [24, 63].
Por otro lado, XPath sirve como base de muchos otros lenguajes que recorren
la estructura de documentos XML, tales como XPointer [138], XSLT [130],
XQuery [142] o XUpdate [148].
Una importante caracterı́stica de XPath es que no dispone de todas las
caracterı́sticas necesarias para poder ser utilizado por sı́ sólo como un lengua-
je de programación completo. XPath está diseñado para ser utilizado dentro
de un lenguaje anfitrión, el cual deberá ser capaz de proporcionar a XPath
un entorno de ejecución con acceso a las variables del entorno y capaz de
encargarse de todas aquellas tareas ajenas a la labor para la que XPath ha
sido diseñado. Por ejemplo, XPath no contempla funcionalidades relaciona-
das con la transferencia de documentos en la Red, el acceso al sistema de
ficheros, el envı́o de formularios, la comunicación con programas externos,
la petición de datos al usuario ni tampoco la presentación de datos a éste.
Todas esas funcionalidades son ajenas a XPath, y por lo tanto, quedan dele-
gadas como labores del lenguaje anfitrión en el que XPath esté hospedado.
Los únicos repositorios que reconoce XPath para almacenar datos son varia-
bles en memoria capaces de ser accedidas y modificadas tanto por él como
por el lenguaje anfitrión en el que está hospedado XPath. Ejemplos de co-
nocidos lenguajes anfitrión de XPath son XSLT y XUpdate, pero no son
los únicos posibles. La existencia de varios posibles lenguajes anfitriones no
debe sorprender, puesto que la sintaxis compacta de XPath está orientada
precisamente a facilitar su hospedaje en varios posibles lenguajes anfitriones,
especialmente los basados en XML, donde las expresiones XPath son idóneas
para ser almacenadas en atributos de etiquetas XML. Sin duda, gran parte
del éxito de aceptación de XSLT es debido a que buena parte de su fun-
cionalidad recae sobre XPath aprovechando este sencillo y elegante tipo de
hospedaje.
106
La presencia de XPath, desde que apareció su primera versión, ha estado,
pese a sus múltiples posibilidades, principalmente limitada a dos campos.
Por una parte, XPath ha sido usado en varias bases de datos XML, donde es
empleado como lenguaje de consulta para la extracción de elementos XML
resultado. Por otra parte, y de una manera quizá mucho más destacada por
su mayor impacto de utilización en un mayor número de personas, XPath
ha sido una de las bases de las hojas de estilo XSLT. En XSLT, XPath es
empleado para seleccionar los nodos del documento de entrada a los que se
les debe aplicar las plantillas de transformación declaradas en una hoja de
estilo.
El aumento de expresividad adquirido en los borradores de la última
versión de XPath (concretamente en la versión 2.0, actualmente en fase de
borrador donde aún hay aspectos en fase de discusión) ha sido realmente im-
portante en los últimos años. Estos aumentos de expresividad, que aparecen
destacados en negrita en la figura 4.11 sobre los de la versión 1.0 de XPath,
permiten a XPath 2.0 ser usado, más que un simple lenguaje de construcción
de expresiones sencillas de direccionamiento de datos en documentos XML,
prácticamente como un pequeño mini-lenguaje de programación de funcio-
nalidades muy recortadas. Pese a que ambas versiones son en el fondo muy
parecidas, la nueva versión no es aún completamente compatible con el ante-
rior estándar, lo cual está provocando numerosas revisiones y debates [122]
entre los grupos de trabajo del W3C donde se está llevando a cabo el proceso
de homogeneización.
La aplicación del nuevo borrador de XPath 2.0 para el direccionamiento
de datos en las páginas Web no ha sido contemplada por los trabajos rela-
cionados en el capı́tulo 3, ni por prácticamente ningún trabajo recientemente
publicado, al menos en lo que concierne al autor de esta tesis. Una de las
razones principales que puede justificar esta falta de aplicación de XPath 2.0
reside en que éste es aún un borrador que no ha pasado a ser un estándar
consolidado por el W3C, razón por la cual los desarrolladores prefieren usar
la versión recomendada de XPath 1.0, preferentemente en algún entorno am-
pliamente conocido como lo son las hojas de estilo XSLT. Por otra parte, la
gran mayorı́a de las páginas Web no cumplen las reglas básicas necesarias
para poderles ser aplicadas tecnologı́as XML, por lo que aplicar XPath sobre
ellas directamente resulta, en primera instancia, impracticable.
XPath 2.0 tal y como aparece definido, es un lenguaje funcional basado en
expresiones que necesita estar hospedado por un lenguaje anfitrión que sea
capaz de albergarlo proporcionándole un conjunto de funcionalidades bási-
cas, tales como mantenimiento de un entorno de ejecución que secuencialice
107
adecuadamente la evaluación de las distintas expresiones XPath de consulta,
o que se encargue de la recuperación y lectura de las páginas a las que se de-
ben aplicar las expresiones XPath de consulta. Un tı́pico ejemplo de lenguaje
anfitrión para XPath es XSLT, el lenguaje de transformación de documentos
XML mediante hojas de estilo. Lenguajes de programación convencionales,
como Java, también pueden ser anfitriones de XPath, como ocurre cuando se
hace uso de bibliotecas capaces de evaluar expresiones XPath recibidas como
argumento [62] y que devuelven sus resultados en tipos de datos conforme a
un API como DOM [131], tal y como aparece en la figura 3.5. Sin embargo,
la gran mayorı́a de esos lenguajes anfitriones usan la versión recomendada
de XPath 1.0, y todavı́a no hay implementaciones fiables que sirvan para
calcular expresiones XPath 2.0.
XPath está definido como un lenguaje de expresiones, lo cual significa que
son éstas, las expresiones, los bloques básicos de construcción de XPath. El
lenguaje contempla varios tipos distintos de expresiones que pueden ser cons-
truidos con palabras clave, sı́mbolos y operandos. En general, los operandos
de una expresión construida con un operador son a su vez otras expresiones.
La figura 4.11 contiene un resumen de las más importantes destacando en
negrita las que son aportaciones de XPath 2.0 respecto de XPath 1.0. Las
siguientes secciones contienen una descripción detallada de cada una de ellas.
4.2.1. Secuencias
El valor de una expresión es siempre una secuencia de valores. Una secuen-

cia es una colección ordenada de varios valores, con un número de elementos
ilimitado, pero finito, incluyendo también el caso de la secuencia vacı́a, es de-
cir, la secuencia que no contiene ningún valor. Los elementos posibles de una
secuencia son valores de tipos denominados como atómicos, esto es, valores
simples no formados por la composición de otros valores. Ejemplos de valores
atómicos son los valores numéricos (de distintas subcategorı́as dependiendo
de su precisión, como valores enteros, decimales y de coma flotante), valo-
res lógicos (o booleanos) y las cadenas de caracteres (strings). Cuando una
secuencia tiene un único elemento se le denomina sigleton y el valor de la
secuencia se asimila al del único elemento que contiene. Es decir, para XPath
el valor efectivo de la secuencia (3), formada por un único elemento cuyo
valor numérico es 3, es asimilable a ese mismo valor numérico. Asimismo,
las secuencias deben ser todas planas, es decir, no se admite la definición
de secuencias cuyos elementos sean a su vez otras secuencias. Por otro lado,
mientras que en XPath 1.0 los tipos de datos atómicos son apenas unos po-
108
Ejes: Expr/Expr, Axis::NodeTest
Predicados: Expr[Expr]
Referencia a variables: $Var
Expresiones aritméticas: Expr + - * div mod Expr
Llamada a funciones: QName(Expr)
Expresiones lógicas: Expr or and Expr, not(Expr)
Comparaciones:
• Expr = != < <= > >= Expr

• Expr eq ne lt le gt ge Expr
• Expr is isnot Expr
Secuencias: Expr , union | intersect except Expr
Sentencias condicionales: if Expr then Expr else Expr
Iteraciones: for Var in Expr return Expr
Expresiones cuantificadas
• some Var in Expr satisfies Expr

• every Var in Expr satisfies Expr
Figura 4.11: Funcionalidades de XPath 2.0 comparadas con las de XPath 1.0
109
cos posibles, básicamente los mencionados anteriormente junto con los nodos
(referencias a elementos del documento XML, incluyendo el elemento raı́z
o página), en los posteriores borradores del estándar el conjunto de tipos
básicos posibles ha sido ampliados con la incorporación de tipos de datos
provenientes de XML Schema (como fechas, duraciones, URIs, ...). Ello ha
dotado al lenguaje de una mayor riqueza al incluir ası́ tipos especializados
que, con frecuencia, aparecen en los documentos que se publican en el Web.
4.2.2. Variables
Las variables son repositorios en memoria que albergan resultados de ex-
presiones XPath y que constituyen la forma de comunicar XPath con su
entorno. Gracias a las variables, expresiones XPath pueden utilizar los resul-
tados de otras expresiones XPath. El acceso al valor de una variable dentro
de XPath se representa con el sı́mbolo del dólar $ seguido del nombre de la
variable. Las variables de XPath son accesibles por el lenguaje anfitrión de
XPath de forma que éste también es capaz de manipular los resultados de
expresiones XPath.
4.2.3. Operadores aritmético-lógicos y de comparación

XPath permite especificar operaciones aritméticas (sumas, restas, mul-
tiplicaciones, divisiones, ...) ası́ como operaciones lógicas (and, or, not) y
comparaciones de diversos tipos (igualdad, menor que, menor o igual que,
mayor que ...), incluyendo también operadores para comparar el orden de
aparición de nodos dentro del documento. Todo ello permite la creación de
expresiones sencillas capaces de calcular operaciones habituales de análisis
de datos en páginas XML que pueden ser combinadas fácilmente.
4.2.4. Ejes de navegación

Los ejes de navegación son indicadores acerca de los caminos que de-
ben seguirse para saltar de un nodo a otro dentro del árbol del documento.
Normalmente esta navegación necesita hacerse en varios saltos, razón por la
cual las expresiones XPath están divididas en distintos steps o pasos, deli-
mitados por barras inclinadas /. Dentro de cada paso, los saltos entre nodos
están condicionados por los denominados ejes de navegación que indican la
relación vecinal existente entre el nodo de origen y el nodo destino de cada
110
salto. Estas distintas formas de proximidad vecinal son contempladas por el
estándar de forma que sean ası́ explorables todos los nodos, tanto internos
a un nodo cualquiera (child y descendant), como externos al mismo (pa-
rent, ancestor, preceding-sibling y following-sibling). El acceso a los
atributos XML de un nodo se puede realizar atravesando el eje attribute.
XPath proporciona a su vez una sintaxis abreviada para cada uno de esos
ejes de navegación, lo cual permite la construcción de expresiones más cortas
y legibles. La tabla 4.2 muestra un listado de los ejes de XPath.
Eje Nodos considerados

ancestor Cualquier nodo en el camino hacia la raı́z
ancestor-or-self Lo mismo, pero incluyéndolo
attribute Sólo los nodos atributo del árbol
child Los nodos directamente contenidos por el nodo actual
descendant Los nodos del subárbol cuya raı́z es el nodo actual
descendant-or-self Lo mismo, pero incluyéndolo
following Los nodos posteriores al actual, excluyendo descendientes
following-sibling Nodos hermanos posteriores al actual
parent El ascendiente directo de un nodo
preceding Los nodos anteriores al actual, excluyendo ancestros
preceding-sibling Nodos hermanos anteriores al actual
self El nodo actual
Cuadro 4.2: Ejes de XPath partiendo de un nodo contexto
4.2.5. Predicados
Si bien suele ser necesario a menudo atravesar varios nodos antes de po-
der llegar a los elementos que interesa finalmente acceder, lo cierto es que
muchas veces el atravesamiento de ciertos de esos nodos que aparecen di-
reccionables por un eje de navegación resultan no deseables. El uso de los
ejes de navegación, aunque esté bien combinado con una adecuada elección
de los nombres de los elementos, resulta muchas veces insuficiente para evi-
tar la navegación por nodos no deseados. Por esa razón, XPath proporciona
mecanismos adecuados para permitir la selección, conforme a criterios espe-
cificables por el usuario, de los elementos de una secuencia obtenida en cada
paso de una expresión XPath, de manera que sólo sean seleccionados del
111
documento XML aquellos componentes que cumplan un conjunto de requi-
sitos establecidos, siendo descartados aquellos elementos de la secuencia que
no cumplan esa propiedad. Las funciones encargadas de filtrar o seleccionar
aquellos elementos de una secuencia que cumplen las propiedades especifi-
cadas en una condición se denominan predicados, y son una parte muy
importante de XPath, pues en ellos reside gran parte de su expresividad. Los
predicados se representan en XPath rodeados de corchetes [] que, situados a
la parte derecha de cada paso, rodean la condición que deben cumplir cada
uno de los elementos seleccionados en ese paso para poder formar parte del
resultado final.
4.2.6. Llamadas a funciones

Con el fin de poder especificar tratamientos especializados, XPath permite
la llamada a funciones parametrizables con argumentos. Dichas funciones
aparecen detalladas en una biblioteca definida para el lenguaje, e incluye
múltiples tipos de tratamientos para cada uno de los distintos tipos de datos
manejables en XPath. No obstante, el conjunto de funciones llamables resulta
un tanto limitado ya que XPath no permite la definición de funciones de
usuario y la biblioteca utilizable tiene un conjunto cerrado de primitivas.
4.2.7. Constructores de datos secundarios

Por otro lado, si bien la idea básica de XPath es la de permitir la ex-
tracción y direccionamiento de datos tal cual éstos aparecen en el documento
XML (datos primarios), el estándar contempla además operadores capaces de
obtener datos que, no figurando como tales en el documento XML de entra-
da, sı́ son capaces de ser computados mediante sencillos algoritmos a partir
de los datos que aparezcan en el documento. Ejemplos de estos operadores
sencillos son la media, la suma, el mı́nimo y el máximo, aunque la lista es
más extensa.
4.2.8. Modificaciones introducidas en XPath 2.0 res-

pecto de XPath 1.0
El actual borrador de esta técnica es el de XPath 2.0, que, desde su pri-
mera publicación en diciembre de 2001, ha sufrido varias revisiones, siendo
[141] la más reciente de ellas. Desde entonces, el borrador de XPath ha in-
112
corporado una serie de modificaciones importantes que le han dotado de una
mayor expresividad y capacidad de especificación. Algunas de ellas son las
siguientes:
Generalización del concepto de secuencia
En XPath 1.0 el tipo básico de datos es el node-set, en el que el orden de

los elementos es el mismo que en el documento y no se admiten elementos
repetidos. Por el contrario, en XPath 2.0, el concepto de node-set ha sido
sustituido por otro más abierto como es la secuencia, donde, a diferencia de su
predecesor, se permite la aparición de elementos repetidos y se pueden definir
otros criterios de ordenación distintos al de la aparición en el documento.
Expresiones condicionales y de iteración (if y for)
XPath 2.0 incorpora también novedades respecto a su versión anterior

en el campo del control de flujo para la evaluación de expresiones XPath,
algo que no aparecı́a en las versiones anteriores del estándar. Nuevos cons-
tructores de expresiones condicionales del tipo if-then-else y repetitivas del
tipo for-in han sido incorporados, gracias a la influencia de XQuery para
la definición de expresiones condicionales y repetitivas. No obstante, la defi-
nición de este tipo de expresiones no es la misma que cabrı́a esperar en un
lenguaje imperativo, ya que se trata de constructores de expresiones, más
que constructores de sentencias. Es decir, una expresión for de XPath, lejos
de constituir un conjunto de sentencias ejecutadas secuencialmente, en rea-
lidad construye una expresión en sı́ misma que tiene como valor la secuencia
formada por los elementos construidos en cada una de sus iteraciones.
Expresiones cuantificadas
Las expresiones cuantificadas sirven para comprobar que se cumple una

determinada propiedad en todos los elementos de un conjunto o al menos en
alguno de ellos. Para ello, proporciona dos cuantificadores, llamados some y
every, que, una vez aplicados a una propiedad o valor de verdad y a una lista
de elementos, determinan si la propiedad es cierta para, al menos alguno, o
para todos los elementos de la secuencia.
113
Operaciones de conjuntos
Otra de las novedades incorporadas en la nueva versión de XPath son los

operadores definidos para construir nuevas secuencias a partir de otras se-
cuencias preexistentes. De este modo, existen operadores para crear la unión
(union), la intersección (intersect) o la diferencia (except) de secuencias
como si fueran conjuntos, esto es, eliminando los elementos repetidos y dejan-
do de considerar la existencia de un orden entre sus elementos. La secuencia
formada por la unión o por la intersección de dos secuencias A y B es la
formada por aquellos elementos que pertenecen a A o/y pertenecen a B (res-
pectivamente).
4.2.9. Aportaciones de XPath

Una caracterı́stica importante del presente trabajo es la de ser el primero
que intenta, al menos en lo que el autor es consciente en la fecha de escritura
de este documento, utilizar en profundidad aquellas nuevas funcionalidades
de XPath 2.0, que no están en XPath 1.0, en el campo de la integración de
datos semiestructurados en el Web legado basado en páginas HTML. Para
ello se ha desarrollado una extensión de XPath 2.0 basada en un conjun-
to pequeño de nuevos, pero potentes operadores que mantienen al mı́nimo
las diferencias con el borrador de XPath 2.0 y que aparecen detalladas en
el apartado 5.5. Por otro lado, se ha proporcionado un lenguaje anfitrión,
detallado en el capı́tulo 6 distinto a los habitualmente usados para XPath
hasta el momento, que son XSLT o las bases de datos XML. Finalmente, se
ha proporcionado una plataforma de ejecución capaz de evaluar expresiones
de consulta descritas en la extensión propuesta de XPath de forma que los
resultados de esas expresiones de consulta sean utilizables por un lenguaje de
programación asequible al usuario y que le permita automatizar fácilmente
tareas en el Web.
XPath es un lenguaje funcional basado en expresiones que está definido
como una recomendación del W3C orientada al direccionamiento de partes
de documentos XML. XPath permite de una forma sencilla, y con alto ni-
vel de abstracción, tener una visión en forma de árbol del modelo de datos
del documento XML, de forma que la navegación entre los nodos del mismo
resulta sencilla, pudiendo estar enfocada directamente a las partes relevan-
tes del documento, sin que para ello tengan que ser tenidas en cuenta las
partes consideradas como no relevantes. El cometido para el que XPath ha
sido diseñado es el de permitir, de una forma clara, sencilla y no ambigua,
el direccionamiento de datos (textos, números, condiciones, y conjuntos de
114
informaciones semiestructuradas en general) dentro de documentos XML,
proporcionando una visión del documento similar a la de un árbol de direc-
torios en un sistema de ficheros, aunque con mayores capacidades de selección
y filtrado. XPath toma su nombre de su uso como una notación de path o
camino a través de la estructura jerárquica de los documentos XML.
4.3. XPointer
XPointer es un borrador del W3C [138] que está definido como una am-
pliación de XPath para permitir el direccionamiento de partes de XML que
no se corresponden con los nodos de un árbol de documento y que no podı́an
ser direccionadas con XPath. Para ello, XPointer expande la definición de
tipos utilizada en XPath con tres nuevos tipos de datos que se resumen a
continuación:
4.3.1. Puntos
Los puntos (point) se definen como posiciones entre dos componentes
dentro de los documentos XML. Un punto representa la posición anterior o
posterior a un elemento de datos del documento, como puede ser cualquier
carácter individual, entidad o nodo de un documento XML. Los puntos están
definidos como un par formado por un contenedor y un número entero no
negativo llamado ı́ndice, que indica la posición del punto dentro del conte-
nedor. Cuando el contenedor es un elemento que contiene texto, el ı́ndice
indica la posición en caracteres del punto dentro del contenedor. Cuando el
contenedor es un elemento que puede tener nodos hijos, el ı́ndice indica la
posición de aquél nodo hijo, cuya localización de inicio se corresponde con
el punto. La figura 4.12, tomada de la especificación de XPointer [138] del
W3C, refleja un ejemplo en el que aparecen detallados varios puntos y nodos
de texto, ası́ como su relación con los nodos contenedores de los mismos.
4.3.2. Rangos
Los rangos (range) se definen como los fragmentos de documento com-
prendidos entre dos puntos arbitrarios de un documento. Téngase en cuenta
que ello permite definir trozos de documento que no necesariamente están
dentro del mismo contenedor. Por ejemplo, puede definirse un rango que em-
pieza en la mitad de un párrafo y terminan en la mitad del párrafo siguiente.
115
Figura 4.12: Representación de elementos XPointer en un fragmento XML
Los rangos son asimilables a cualquier fragmento contiguo de un documento

XML, como el que fácilmente podrı́a ser seleccionado mediante una herra-
mienta visual haciendo una operación de drag & drop.
4.3.3. Patrones de texto
Una de las grandes necesidades en el campo del direccionamiento de datos

semiestructurados consiste en la posibilidad de reconocer textos mediante
expresiones regulares. XPath, enfocado principalmente al direccionamiento
de nodos, no proporciona, al menos en sus primeras versiones de XPath 2.0,
funciones capaces de devolver aquellas partes de los documentos XML donde
se cumple una concordancia entre el texto del documento y un patrón de
texto usado para hacer búsquedas o reconocimiento de textos basados en
expresiones regulares. Mediante la función string-range() de XPointer, esto
ya es una realidad, pero el string recibido por esta función como patrón es
buscado literalmente en el documento (sin posibilidad de ser interpretado
como una expresión regular), por lo que el tipo de búsquedas que se pueden
realizar con este patrón resultan algo limitadas.
116
4.3.4. Aportaciones de XPointer
Extender XPath con nuevas funcionalidades definiendo tal y como XPoin-
ter propone mediante nuevo lenguaje considerado como una extensión de la
parte básica de XPath es un buen enfoque, porque permite ampliar la fun-
cionalidad de un lenguaje preexistente dotándole de una mayor complejidad,
sin que para ello se retoque la parte básica del estándar, la cual puede ser, sin
embargo, suficiente para tareas más sencillas. Teniendo en cuenta el carácter
eminentemente especializado de los nuevos operadores sugeridos por XPoin-
ter, su relativamente bajo número (tres), su escasa relación con los operadores
de XPath y el hecho de que XPath por sı́ mismo es capaz ya de dar respuesta
a una buena parte de los problemas en los que es utilizado, no resulta ra-
ro darse cuenta de las razones por las cuales estas extensiones han formado
parte de una definición externa a XPath, en lugar de ser incorporadas al
borrador de XPath como nuevos conjuntos de operadores. Sin embargo, pese
a este flexible enfoque según el cual se podrı́a disponer de una tecnologı́a más
potente que la que ofrece XPath gracias a unas pocas, pero importantes ex-
tensiones de funcionalidad, XPointer presenta algunas caracterı́sticas que le
impiden ser considerada como una tecnologı́a apropiada para el desarrollo de
este trabajo. Ciertamente hay buenas ideas que aporta esta recomendación
de las que tomar buena nota, pero existen igualmente problemas, entre los
que se destacan unos a continuación:
La especificación de XPointer prohibe explı́citamente la definición de

funciones de usuario, lo cual supone una restricción inasumible para po-
der afrontar los objetivos de esta tesis, entre los cuales está la definición
de comportamientos encapsulables por parte de los usuarios.
string-range por sı́ sólo resulta presentar una funcionalidad algo limi-
tada, ya que sólo permite buscar texto tal cual dentro del documento,
sin permitir generalizar las búsquedas con expresiones regulares.
XPointer, desarrollado por un grupo de trabajo en el W3C distinto al de
la definición de XPath, está basado en la versión de XPath 1.0, y por lo
tanto no recoge las importantes ampliaciones de los nuevos borradores
de XPath 2.0. Ello probablemente dejará de ser un problema en cuanto
los diseñadores de XPointer empiecen a trabajar en una versión basada
en el nuevo borrador de XPath, pero no se tiene, por el momento,
constancia de que tal iniciativa se vaya a llevar a cabo. De hecho, los
avances que el grupo de XPointer ha conseguido por su cuenta no han
sido incorporados en los borradores de XPath que han aparecido con
posterioridad.
117
Finalmente, tampoco resulta interesante todas las nuevas funcionali-
dades de XPointer. Por ejemplo, la definición de puntos basada en
posiciones numéricas es muy poco tolerante a cambios en el documento
(la simple inserción de una palabra o un nodo inesperado provocará un
cambio en la posición del elemento que se desea extraer, lo cual implica
una reprogramación de las reglas basadas en posicionamientos expre-
sados con posiciones numéricas) y no todos los rangos definibles por
XPointer interesan.
Pese a estas mı́nimas diferencias, buena parte de las ideas con las que
XPointer extiende a XPath han sido tenidas en cuenta en el capı́tulo 5.5
para ampliar la funcionalidad de XPath en aquellos aspectos en los que la
experiencia ha demostrado que tales extensiones son convenientes. Para ello,
no obstante, se han restringido aquellas extensiones que no aportaban una
funcionalidad interesante para acometer los objetivos de esta tesis.
4.4. XSLT
XSLT [130] es un formato de hojas de estilo muy conocido que se utiliza

mucho para la transformación de documentos XML en otros documentos. A
diferencia de las tecnologı́as mencionadas en este capı́tulo (salvo quizá XUp-
date y una versión de XQuery orientada al procesamiento automatizado,
llamada XQueryX [135]), XSLT sigue una sintaxis XML, donde se utiliza el
concepto de plantilla para aplicar unas reglas de transformación a elemen-
tos de documentos XML direccionados con XPath. Precisamente esa buena
relación de complementareidad entre las hasta ahora utilizadas versiones de
XSLT y XPath (versiones 1.0 en ambos casos), se ha convertido en una de
las razones del éxito de aceptación de XSLT. No obstante, por debajo del
enfoque de simple transformación de XSLT, se esconde todo un lenguaje de
programación funcional capaz de ser un buen lenguaje anfitrión para XPath.
El modelo de trabajo de XSLT es sencillo. Basta con aplicar una a una el
conjunto de plantillas al modelo en árbol DOM del documento de entrada,
para ası́ ir generando los resultados deseados en el documento de salida. Pese
a usar la complejidad de DOM para acceder a un documento XML, XSLT
no permite la manipulación del documento XML de entrada, sino que sólo
genera nuevos documentos.
118
4.4.1. Aportaciones de XSLT
Pese a su aceptación por un gran conjunto de desarrolladores, XSLT resul-
ta ser un lenguaje limitado en varios aspectos que le impiden ser una solución
compatible con los objetivos de esta tesis. Para empezar, su sintaxis XML
le hace ser fácilmente procesable por aplicaciones, pero demasiado verbosa y
extensa, por lo que resulta difı́cil de mantener. De hecho, simples operaciones
programadas en el lenguaje pueden fácilmente requerir la programación de
bastantes lı́neas de código, razón por la cual los programas desarrollados con
XSLT acaban teniendo un tamaño similar al que podrı́a tener su equivalente
en un lenguaje de programación convencional. XSLT proporciona una visión
de alto nivel en el documento y su notación funcional le hacen ser un lenguaje
apropiado para tratamientos sencillos. Sin embargo, las hojas de estilo XSLT
resultan bastante poco flexibles para realizar tareas complejos.
Por otro lado, el nuevo borrador de XSLT 2.0 se encuentra ahora mismo
en un serio debate de reformulación debido a los conflictos de intereses que
han aparecido como consecuencia de la extensión de XPath 2.0. Actualmente
existen importantes problemas de integración con XPath 2.0 debido a que la
extensión de este último desde su recomendación anterior ha incluido varios
operadores cuya funcionalidad ya estaba siendo contemplada por operadores
similares de XSLT, lo cual ofrece múltiples fuentes de ambigüedad para los
desarrolladores. Es por ello que esta integración está siendo objeto de estudio
por el grupo de trabajo. A continuación se muestran algunos ejemplos que
ilustran este tipo de conflictos recientemente aparecidos:
1. En la figura 4.13 se muestran dos versiones del código XSLT necesario

para calcular el valor máximo de un par de variables. La primera versión
está basada en XPath 1.0, por lo que, dada la simplicidad del estándar,
casi toda la labor acaba recayendo en la funcionalidad proporcionada
por XSLT. La segunda versión, basada en XPath 2.0, resulta mucho más
simple y compacta por el simple hecho de traspasar la funcionalidad
de XSLT a XPath, quedando en una única lı́nea de código lo que en la
versión XSLT requerı́a varias.
2. En este ejemplo se puede comprobar el sensible aumento de expresivi-

dad y de nivel de abstracción experimentado por XPath experimentado
por sus expresiones cuantificadas. Ambas expresiones XPath intentan
determinar la condición de que, en un documento XML que refleja los
resultados de unas encuestas, los participantes de la misma no hayan
dejado ninguna pregunta (question) sin contestar (el atributo @value
deberá ser no nulo). Expresar esa condición resulta sencillo en XPath.
119
<xsl:variable name="max">
<xsl:choose>
<xsl:when test="$a > $b">
<xsl:value-of select="$a"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$b"/>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:variable name="max" select="if ($a > $b) then $a else $b"/>
Figura 4.13: Expresión XPath reformulada con el operador if
Para ello, la expresión en XPath 1.0 contabiliza el número de preguntas

efectivamente contestadas y comprueba que ese número coincide con el
número de preguntas de la encuesta. Esto, que es una solución perfecta-
mente válida implica realizar siempre dos contabilizaciones que pueden
ser muy costosas cuando el número de elementos es muy elevado. Por el
contrario, usando el nuevo cuantificador universal de XPath 2.0, la so-
lución, además de ser más eficiente de calcular en término medio, pues
en el momento en el que se encuentra una pregunta sin contestar pue-
de interrumpirse la búsqueda para dar un resultado negativo, resulta
más elegante, ya que simplemente se pregunta si todos los elementos de
la lista de preguntas cumplen la condición de estar respondidas. En la
figura 4.14 pueden comprobarse las formas de expresar una misma con-
dición, tanto en XPath 1.0, como en XPath 2.0, con el nuevo operador
cuantificado.
<xsl:if test="count(//question[
number(@value) > 0])=count(//question)">
<xsl:if test="every $question in

//question satisfies $question/@value > 0">
Figura 4.14: Expresión XPath reformulada con el operador every
120
4.5. XQuery
Paralelamente al lanzamiento de XPath 2.0, el mismo grupo de trabajo
de ese borrador ha estado trabajando en el lanzamiento de la primera versión
de XQuery [142], actualmente definido también como borrador (aún sujeto a
cambios). XQuery se define como un lenguaje de consultas estructuradas pa-
ra documentos XML de entrada de forma que los resultados se almacenan en
nuevos documentos XML de salida. XQuery 1.0 abarca a XPath 2.0 como un
subconjunto del lenguaje al que se le han añadido extensiones especı́ficas no
contempladas en XPath 2.0. Esto quiere decir que toda expresión XPath 2.0
es considerable a su vez como una expresión XQuery 1.0 y debe devolver el
mismo resultado. El lenguaje de consultas XQuery permite realizar consultas
a un documento XML como si éste fuera una base de datos relacional, dando
ası́ una visión muy estructurada del documento. Cuando el documento XML
no tiene una estructura asimilable a la de una tabla, entonces entran en juego
los operadores de XPath capaces de dar una visión en árbol. La compene-
tración entre XPath y XQuery está garantizada, no sólo por ser un objetivo
del grupo de trabajo que redacta ambas especificaciones, sino también por
el hecho de que buena parte de la funcionalidad de XQuery se encuentra ya
recogida en la de XPath, donde el conjunto de operadores que pertenecen a
XQuery y no pertenecen a XPath suponen una pequeña, aunque significativa
parte de la especificación. XQuery es el resultado del trabajo conjunto de
varias personas que han recopilado esfuerzos provenientes de varios proyec-
tos relacionados con la creación de lenguajes de consulta, tales como SQL
[78], XQL [107] o XML-QL [56] entre otros. El lenguaje mantiene un gran
parecido con SQL y define reglas de construcción del documento XML de
salida, que contendrá los resultados de la búsqueda.
4.5.1. Aportaciones de XQuery

Al estilo de XPointer, XQuery se presenta como una ampliación de XPath.
Sin embargo, pese a este flexible enfoque, según el cual se permitirı́a mante-
ner una especificación simple para solucionar la mayorı́a de los problemas y
una especificación más especializada para solucionar los problemas más com-
plejos, el enfoque de XQuery hacia las bases de datos estructuradas acaba
restando valor a XQuery para ser contemplado como una tecnologı́a válida
para afrontar los objetivos de esta tesis. A ello hay que añadir el hecho de que
XQuery está orientado, al igual que XSLT, a la creación de un documento
XML de salida que contiene los resultados de la búsqueda, pero no permite
realizar modificaciones directamente sobre el documento de entrada. No obs-
121
tante, XQuery aporta algo muy positivo de lo cual carece XPath, que es la
posibilidad de asociar expresiones XPath a distintas fuentes de documentos
ası́ como integrar los datos de varias de esas fuentes.
4.6. DOM
Sin duda alguna, DOM [131] ha sido, desde su nacimiento, el interfaz de
programación más conocido para el procesamiento de datos XML. Estan-
darizado casi desde el nacimiento del propio XML, el interfaz DOM define
un conjunto de primitivas sencillas y potentes que permiten la manipulación
flexible del documento XML, manteniendo en memoria una representación
en forma de árbol en la cual se pueden recorrer los nodos en varios sentidos y
direcciones, incluso de forma repetida si se desea. El almacenamiento en for-
ma de árbol tiene como ventaja añadida a su gran navegabilidad el hecho de
que es fácilmente modificable en memoria, siendo muy eficiente este modelo
para pequeñas modificaciones sobre grandes documentos. Sin embargo, entre
sus desventajas está un elevado consumo de recursos espaciales, de forma
que una representación en memoria, dicho sea de paso, puede ocupar signifi-
cativamente mucho más espacio que la versión serializada en un fichero. Sin
embargo, la visión del documento como un árbol en memoria permite una
gran facilidad de programación para modificaciones en la estructura arbórea
del documento. Por ejemplo, la inserción, el eliminado de nodos o la manipu-
lación repetida del valor de atributos, puede ser realizada de forma directa
atacando las partes del árbol afectadas sin que el resto sufra modificaciones,
siendo estos tratamientos a su vez muy eficientes en el tiempo, toda vez que
el principal consumo de recursos se realiza en el análisis inicial del documen-
to. Ası́ pues, DOM resulta ser una tecnologı́a especialmente adecuada para
realizar tareas para las que otras tecnologı́as mencionadas en este capı́tulo,
como XSLT o XQuery no son adecuadas. Además, dado que, los documentos
del Web no suelen ser demasiado grandes, el problema de esta los requisitos
de memoria de DOM pasan a estar en un segundo plano cuando se trata de
ser aplicado al tratamiento de páginas Web.
4.6.1. Aportaciones de DOM

Sin duda alguna, de todas las tecnologı́as de este capı́tulo, DOM es la más
potente y flexible para realizar tareas de integración de datos semiestructu-
rados en el Web. Su capacidad de permitir recorridos por el documento en
cualquier forma y sentido la convierten en ideal para poder realizar diversas
122
extracciones de datos de un mismo documento, algo, por otra parte habitual
en el ámbito de trabajo afrontado en esta tesis. La supuesta sobrecarga de
recursos necesarios para su procesamiento tampoco es en sı́ un problema, ya
que los clientes, muy al contrario que muchos servidores Web, tienen muchas
veces recursos más que suficientes para procesar las páginas del Web que van
consultando, las cuales, dicho sea de paso, tampoco suelen tener un tamaño
excesivo.
Ahora bien, si bien la idea de representar documentos en forma de árbol es
una aportación realmente importante para el trabajo de esta tesis, el interfaz
DOM en sı́ mismo presenta la importante desventaja de presentar al usuario
un nivel de abstracción bastante bajo, lo cual redunda en que, incluso para
las operaciones más sencillas, sean necesarias varias lı́neas de código. Además
su orientación imperativa precisa que cualquier tipo de navegación en el do-
cumento deba realizarse solicitando al programador todo lujo de detalles, en
lugar de usar expresiones de más alto nivel de abstracción. Una solución al
problema podrı́a ser la combinación de bibliotecas para XPath 2.0 usadas des-
de programas implementados conforme al interfaz DOM. Lamentablemente
no existen bibliotecas disponibles que implementen la funcionalidad de XPath
2.0, ya que las pocas existentes están definidas sobre la versión anterior de
ese estándar. En definitiva, DOM aporta una excelente forma de represen-
tar documentos navegables en memoria en forma de árbol, pero su interfaz
concreto tiene un nivel demasiado bajo para los programadores.
4.7. SAX
Al margen de las especificaciones del W3C, un grupo de programadores,
moderados por David Megginson en la lista de correo electrónico xml-dev ha
desarrollado un interfaz de programación orientado al procesamiento eficiente
de documentos XML. Para ello, en lugar de procesar todo el documento para
obtener una representación en memoria del mismo, este interfaz se encarga de
permitir al usuario definir el comportamiento del procesador del documento
ante el evento de leer cada una de sus partes según éstas van siendo obtenidas
del documento de entrada. Ello permite que el análisis de grandes documentos
XML pueda realizarse según los elementos del documento XML van siendo
procesados, uno a uno, sin necesidad de ir guardando todo lo leı́do hasta
el momento. SAX es un interfaz que permite, pues el análisis en secuencia
del documento XML de entrada y es muy recomendable para el análisis de
grandes documentos. Una de sus principales desventajas, sin embargo, se
deriva del hecho de que SAX no es un interfaz de programación adecuado
123
para la manipulación de documentos, ya que en el código de la programación
de cada evento ocurrido en el procesamiento, no se puede tener acceso a las
partes del documento procesadas con anterioridad.
4.7.1. Aportaciones de SAX

Aunque factible para realizar ciertas labores sencillas, SAX resulta ser
una tecnologı́a inapropiada para afrontar los objetivos de esta tesis. Su bajo
nivel de abstracción, demasiado particularizado a un tratamiento especı́fico
(el procesamiento secuencial orientado a eventos), le impide ser considera-
do como una tecnologı́a adecuada para la extracción de datos relevantes en
documentos XML, no sólo por la dificultad que impone el interfaz para el
acceso a estructuras de datos de complejidad media o alta, sino por el hecho
de que implica realizar programas con un elevado número de lı́neas de códi-
go, lo cual ofrece al programador pocas garantı́as de robustez ante cambios.
Por otro lado, aunque la eficiencia es un factor crı́tico, la mayorı́a de los do-
cumentos en el Web son páginas de tamaño relativamente bajo estando los
retrasos causados principalmente por la latencia en la respuesta de los servi-
dores y la red, más que el consumo de recursos de memoria de los clientes,
por lo que, aunque sin perder de vista el factor de la eficiencia, éste resulta
no ser algo crı́tico en los momentos actuales, al menos dentro del procesa-
miento de documentos XML. Sin embargo, SAX es una opción basada en el
uso de comportamientos definibles por el usuario y es muy adecuada para el
procesamiento de documentos de gran tamaño. Pese a que en los ejemplos
prácticos el tamaño de los documentos en el Web no suelen ser demasiado
voluminosos, un interfaz basado en este tipo de procesamiento puede ser de-
seable para automatizar tareas en el Web donde el volumen de los datos en
un mismo documento suponen un tamaño considerable, por lo que no deben
descartarse las aportaciones de SAX cuando sea necesario un tratamiento
más eficiente de los documentos.
124
Capı́tulo 5
XTendedPath: Lenguaje para la

consulta y modificación de
documentos XML
El lenguaje XTendedPath descrito en este capı́tulo es una propuesta de

lenguaje que tiene dos usos principales: la consulta y la modificación de
documentos XML, labores clave en el tratamiento automatizado de datos por
parte de tareas que navegan automáticamente por el Web. La consulta de
documentos es clave para la extracción de datos relevantes, una de las ac-
ciones básicas explı́citas mencionadas en el apartado 2.2. La modificación es
clave para otras acciones, como la eliminación de datos irrelevantes, la emu-
lación de comportamientos JavaScript cuando éstos afectan a la estructura
del documento o para otros comportamientos relacionados con formularios.
Por ejemplo, muchas veces, el documento Web no está formado sólo por con-
tenidos generados en el servidor, sino que otros son generados en el cliente
por JavaScript. Por otro lado, en ocasiones la mejor representación interna
de un formulario relleno es el propio subárbol del documento que contiene
ese formulario como elemento. Ası́ pues, realizar modificaciones en el relle-
nado de ese formulario requiere entonces poder realizar modificaciones en la
representación arbórea del documento.
XTendedPath, al contrario de otras propuestas ya existentes como las
mencionadas en el capı́tulo 3, está basada en varios estándares del W3C
especı́ficamente diseñados para el direccionamiento de datos en el Web, como
son el actual borrador de XPath 2.0 [141] y el estándar XPointer [138], aunque
también toma ideas de XQuery, DOM y XUpdate. Hasta el momento actual,
ningún trabajo conocido por el autor dentro del campo de la extracción de
125
datos del Web legado ha utilizado XPath 2.0. De los trabajos mencionados en
el capı́tulo 3, sólo los más avanzados, como [94] han usado apenas XPath 1.0,
que es la versión que está estandarizada actualmente, la cual se ha encontrado
normalmente embebida dentro de hojas de estilo XSLT 1.0, para extraer los
datos en forma de documentos. Otros trabajos, como [111] hacen uso de
XQuery como lenguaje de consulta, pero sólo son aplicables a páginas Web
muy estructuradas, asimilables a tablas y datos muy regulares, lo cual no
es siempre factible. Por el contrario, XTendedPath está diseñado para poder
ser usado en cualquier página HTML o XML pese a que ésta carezca de una
fuerte estructura.
5.1. Problemas de XPath 2.0

Un problema general de la actual especificación de XPath 2.0, al menos
tal y como está definido su actual borrador es que algunas tareas de extrac-
ción de datos no pueden ser realizadas con XPath 2.0. Por otro lado, otras
tareas sı́ pueden ser realizadas, pero de una forma muy ineficiente. Todo ello
está debido a ciertas carencias del lenguaje que son abordadas en esta sección
y para las que XTendedPath, descrito en el apartado 5.3 se presenta como
una solución, extendiendo a XPath 2.0 y a XPointer con un conjunto mı́nimo
de constructores para poder aumentar considerablemente su expresividad.
Si bien las carencias de XPath 2.0 a las que se hace referencia en este
apartado pueden ser resueltas mediante el uso de funcionalidades propias de
sus lenguajes anfitrión (normalmente plantillas XSLT), el hecho de delegar
en esos lenguajes externos la programación de estas tareas impide a XPath
ser usado por sı́ mismo como un lenguaje de consulta autocontenido y
utilizable en entornos legados. A continuación se muestran algunos ejemplos
de esos problemas, mencionados en [127]:
5.1.1. Procesamiento incremental

La expresión “for” en XPath 2.0 no puede ser usada cuando el resultado
de procesar cada elemento en una secuencia depende del procesamiento de
los elementos anteriores. Es posible que en algunos casos ese procesamiento
sı́ pueda realizarse, pero de una manera muy ineficiente. Por ejemplo:
Calcular el producto de todos los números de una secuencia

Invertir el orden de una secuencia o los caracteres de un string
126
Concatenar todos los elementos string de una secuencia en uno solo
Un ejemplo en el que una solución XPath 2.0 es difı́cil e ineficiente es el

siguiente:
Dada una secuencia de nodos book dentro de un documento XML que
refleja las ventas de una tienda, calcular la cantidad de dinero vendido por
cada libro (calculada como el producto de su precio por su número de unida-
des vendidas). El resultado debe devolverse en una secuencia de pares tı́tulo,
importe acumulado, donde tı́tulo es el tı́tulo de cada libro de la secuencia
e importe acumulado es el importe acumulado por las ventas de los libros
hasta ese momento, desde el principio de la secuencia de libros hasta el libro
correspondiente a cada posición.
Para obtener ese resultado, se puede usar la expresión escrita en XPath
2.0 que aparece en la figura 5.1:
for $i in (1 to count($items))
return ($items[$i],
sum( for $j in (sublist($items, 1, $i))
return (@price * @sales) ) )
Figura 5.1: Expresión XPath 2.0 que calcula importe de ventas con subtotales
parciales
La expresión de la figura 5.1 tiene complejidad cuadrática. Es decir, si

N es el número de elementos dentro de $items, se realizan N × (N + 1) /
2 sumas y N × (N + 1) / 2 multiplicaciones, lo cual es bastante ineficiente
desde un punto de vista de complejidad de algoritmos.
Para conseguir expresar el algoritmo con complejidad lineal, mucho más
eficiente, serı́a necesario usar una variable que acumulara las sumas parciales
realizadas hasta el momento, con el fin de no volverlas a recalcular en poste-
riores iteraciones. Ası́ pues, el algoritmo anterior deberı́a poder reescribirse
de una forma similar a la que aparece en la figura 5.2:
$s = 0;
for $i in (1 to count($items))
$s = $s + (@price * @sales);
return ($items[$i], $s)
Figura 5.2: Pseudocódigo basado en variables que calcula subtotales
127
Pese a lo que pudiera parecer, la expresión de la figura 5.2 no es una
expresión XPath. XPath es un lenguaje funcional basado en expresiones, no
un lenguaje imperativo basado en sentencias, por lo que no permite la posi-
bilidad de tener un bucle dentro del cual haya dos expresiones que deban ser
evaluadas una detrás de otra como sentencias imperativas. El constructor for
de XPath solamente admite una expresión return en su interior, que sirve
para devolver el elemento que debe formar parte de la secuencia resultado,
conforme se va recorriendo una secuencia de entrada. Por otro lado, pese a
que en los lenguajes imperativos sea algo común que una variable vaya siendo
sobreescrita con diversos valores a lo largo de la ejecución, los lenguajes fun-
cionales no permiten ese tipo de efectos laterales, porque se dedican a la mera
evaluación de expresiones funcionales en las que los resultados se obtienen
de aplicar funciones a unos argumentos. Dicho de otro modo, las variables en
XPath pueden ser consultadas fácilmente, pero no pueden ser sobreescritas
como en un lenguaje de programación imperativo. Por ese motivo, el código
de la figura 5.2 deberı́a en todo caso ser reconsiderado por uno que carez-
ca de este tipo de problemas de efectos laterales y que tenga una notación
completamente funcional, como el que aparece en la figura 5.3.
sumalibros = function ($items, $acum)
if $items = ()
then ()
else
let $primer = first($items),
$producto = $primer/@price * $primer/@sales in
($primer, $acum + $producto,
sumalibros(tail($items), $acum + $producto))
end
sumalibros($items, 0)
Figura 5.3: Pseudocódigo basado en funciones que calcula subtotales
Como puede apreciarse en la figura 5.3, el código que aparece tiene una
notación completamente basada en expresiones y no en sentencias, propio de
un lenguaje de programación funcional. Para ello se ha creado una función
auxiliar llamada sumalibros que devuelve la secuencia vacı́a cuando la secuen-
cia de entrada $items está vacı́a y genera el resultado de la forma deseada,
acumulando el producto de cada libro en un subtotal que se va acarreando
para el resto de los elementos de la secuencia.
Para construir el código de la figura 5.3 se han usado dos importantes
caracterı́sticas no existentes en XPath 2.0. Por un lado, se ha definido una
función auxiliar de usuario, denominada sumalibros de dos argumentos y
posteriormente se ha llamado a esa función para calcular el resultado final. En
128
términos de programación funcional al nombre sumalibros se le ha asociado
una expresión lambda [90] o función de usuario.
Los lenguajes funcionales suelen definir también variables con una cons-
trucción let en la que se declara una variable a la que se le asocia un valor
que es inmutable a lo largo de toda la ejecución, como por ejemplo en la
expresión: let $i = 3 in $i + $i, cuyo resultado serı́a 6. Sin embargo, ni las
expresiones lambda ni el constructor let forman parte del lenguaje XPath. El
constructor let (que a su vez también puede ser reescrito como una expresión
lambda) forma parte del lenguaje XQuery (basado en XPath 2.0), pero no
está considerado en XPath 2.0. Por otro lado, aunque en XPath está permi-
tida la llamada a funciones, éstas no tienen forma de ser construidas por los
usuarios y su uso se limita a un conjunto reducido de funciones localizables
en bibliotecas del lenguaje.
5.1.2. Dificultad para calcular valores agregados

XQuery permite la definición de funciones de usuario y del constructor let.
Sin embargo XQuery, al igual que XPath, presenta dificultades para calcular
valores agregados de una secuencia, especialmente cuando esos valores deben
ser calculados de una forma no trivial. Por ejemplo:
Obtener los nodos con máximo valor de una secuencia, especialmente

en el caso en el que el valor de cada nodo de esa secuencia deba ser
computado por una expresión compleja.
Obtener los nodos con distinto valor de una secuencia, especialmente
en el caso en el que el valor de cada nodo de esa secuencia deba ser
computado por una expresión compleja.
En XPath 2.0 no existe una forma genérica de evaluar este tipo de expre-
siones recibiendo como parámetro una función que evalúe esas expresiones
complejas a las que se hace referencia. Por esa razón, en XPath 2.0 deben es-
cribirse multitud de expresiones similares, cada una de ellas para cada posible
expresión compleja y sin posibilidad de ser reutilizadas. Estas repeticiones y
la falta de capacidad de reutilización del código provoca grandes consumos
de tiempo, propensión a errores y generalmente ocasionan la generación de
código difı́cilmente mantenible y poco reutilizable.
Ejemplos de problemas de este tipo son los siguientes:
Obtener la suma de los cuadrados de los números de una secuencia
129
Extraer aquellos números de una secuencia, para los cuales f(item) es
mı́nimo
Para una función f(), comprobar que todos los valores f(item) de una
secuencia son mayores que cero (o menores o iguales a cualquier otro
valor)
Para una función f(), comprobar que todos los valores f(item) de una
secuencia aparecen en orden creciente
Para las expresiones anteriores, aunque es posible encontrar una solución

basada en XPath, ésta será difı́cil e ineficiente. Además, para cada posible
función f() deberá reescribirse cada expresión, ya que las funciones no pueden
ser pasadas como argumentos a otras funciones.
5.1.3. Combinar dos o más secuencias en una nueva

Es posible querer combinar dos o más secuencias en una sola. Dadas (a1 ,
a2 , ..., aN ) y (b1 , b2 , ..., bN ) con XPath no es sencillo calcular expresiones
como:
(a1 + b1 , a2 + b2 , ..., aN + bN ) (suma elemento a elemento)
(a1 × b1 , a2 × b2 , ..., aN × bN ) (producto elemento a elemento)
(a1 ∧ b1 , a2 ∧ b2 , ..., aN ∧ bN ) (conjunción lógica and elemento a

elemento)
...
5.1.4. XPath no puede expandirse indefinidamente

La complejidad de XPath ha crecido considerablemente en los últimos
tiempos, pasando de ser un sencillo conjunto de expresiones a un lenguaje
mucho más potente. Sin embargo, la capacidad de seguirse expandiendo re-
sulta un tanto limitada. Por otro lado, aunque en el grupo de trabajo están
trabajando en una homogeneización del lenguaje, existen ahora mismo varias
formas de expresar tareas similares. Ello indica hasta qué punto es necesario
reordenar la capacidad de expansión del lenguaje, y que actualmente está aún
en una fase inmadura y es compleja y difı́cil de organizar. Un lenguaje que
130
proporcione soporte al orden superior puede proporcionar una solución sim-
ple y elegante, a la vez que flexible y potente.
Serı́a deseable que las principales funcionalidades del lenguaje (operado-
res, constructores y funciones) pudieran ser reducidas a un mı́nimo mientras
que el lenguaje permita que nuevas funcionalidades puedan ser fácilmente
producidas y acumuladas en una biblioteca de funciones reusables de uso
general.
5.1.5. Poca flexibilidad para llamar a ciertas funciones

La llamada a funciones como sort o distinct-values resulta poco flexible ya
que no es posible especificar las funciones de comparación entre elementos.
Serı́a deseable poder ordenar una secuencia pudiendo especificar el criterio
de ordenación en una función definible por el usuario y con la que se pudiera
parametrizar el comportamiento de la función sort.
5.1.6. Poca reusabilidad para expresiones de tipo “for”

En la expresión de la figura 5.4, la expresión expression no puede ser
reutilizada, salvo que se copie y pegue en otro sitio, debiendo ser modificada
de forma que las referencias a la variable del rango que recorre la secuencia
sean convenientemente renombradas.
for $i in $sequence
return expression
Figura 5.4: Ejemplo de expresión de tipo for
Por el contrario, con soporte a funciones de orden superior, podrı́a usarse

la función map(f, $sequence) como equivalente a la de la figura 5.4 de forma
que el código de la función f() no deba ser modificado.
5.2. Soluciones basadas en funciones de or-

den superior
Suponiendo que en XPath se pudieran definir funciones de orden supe-
rior, los problemas listados en el apartado 5.1 podrı́an ser resueltos de forma
131
sencilla. Dado que, lamentablemente, no existe en XPath la posibilidad de
definir funciones de usuario, para demostrar la facilidad de programación
de esta aproximación y su fácil legibilidad por los usuarios programadores,
los siguientes ejemplos están proporcionados en lenguaje Haskell [113]. En el
apartado 5.5.2 se proporciona una reescritura de este tipo de funciones en
XTendedPath, la extensión de XPath que se presenta en el apartado 5.3. El
lenguaje Haskell se usa en este apartado solamente como ejemplo de conve-
niencia. En ningún caso se intenta recomendar con ello que su sintaxis sea
adoptada por XPath 2.0. Para comprender los siguientes ejemplos, algunas
convenciones de Haskell deben ser explicadas.
Convenciones de representación en Haskell
Definir una función en Haskell es muy sencillo. La expresión f x y = x *

y define una función f que devuelve el producto de sus dos argumentos.
La expresión [1, 2, 3] expresa una lista formada por tres elementos, similar
a la secuencia (1, 2, 3) de XPath. [] denota la secuencia vacı́a, equivalente a
() en XPath.
Un operador infijo puede ser usado como una función cuando se le escribe
entre paréntesis. De esta forma: (+) 1 2 = 1 + 2 = 3.
El operador : es usado para indicar que un elemento está al principio de
una lista. De esta forma, x : xs define una lista donde x es el primer elemento
y xs es el resto de la lista.
La función flip toma como argumento una función y otros dos argumentos
y produce como resultado la llamada a esa función tomando los argumentos
en orden inverso. Ası́: flip f x y = f y x.
Igualmente, la recursión a lo largo de los elementos de una lista puede ser
definida como aparece en la figura 5.5. La función foldl toma tres argumentos,
una función f(), que toma dos argumentos, un valor z y una lista. foldl es una
de las funciones más generales que trabajan sobre listas. Recorre la lista de
izquierda a derecha, aplicando f() a cada elemento y al resultado acumulado
hasta el momento, que es tenido en cuenta para el siguiente elemento de la
lista. De una forma similar, también puede ser definida foldr.
Como puede comprobarse fácilmente, foldl (+) 0 xs es la suma de todos
los elementos que aparecen en la secuencia xs. De la misma forma, podrı́a
escribirse sum xs = foldl (+) 0 xs para definir la función sum. Análogamente,
se podrı́a definir product xs = foldl (*) 1 xs que calcuları́a el producto de
los elementos de una secuencia, lo cual serı́a una solución para uno de los
132
foldl f z [] = z
foldl f z (x:xs) = foldl f (f z x) xs
Figura 5.5: Ejemplo foldl en Haskell
problemas apuntados en el apartado 5.1.1.

Por otra parte, las funciones pueden usarse de forma currificada, lo cual
quiere decir que las definiciones anteriores podrı́an haber sido reescritas de
la siguiente forma: sum = foldl (+) 0 y product = foldl (*) 1.
Invertir el orden de una lista (problema apuntado en la sección 5.1.1)
puede ser fácilmente realizable con reverse = foldl (flip (:)) [].
Concatenar los elementos de una lista (problema también apuntado en la
sección 5.1.1) puede realizarse llamando simplemente a la función concat =
foldr (++) [] donde (++) es el operador de concatenación para listas.
Por otro lado, combinar dos listas de igual longitud en una sola puede ser
realizado con la función zip() que aparece en la figura 5.6. En ella, la función
f() es aplicada a cada par de elementos de la misma posición en ambas listas,
y el resultado de esa función forma el elemento que está en esa posición dentro
de la secuencia resultado.
zip f (a:as) (b:bs) = f a b : zip f as bs

zip _ _ _ = []
Figura 5.6: Ejemplo zip en Haskell
La función zip() resuelve directamente muchos de los problemas mencio-

nados en el apartado 5.1.3. Por ejemplo (a1 + b1 , a2 + b2 , ..., aN + bN ) es
solamente zip (+) as bs. (a1 × b1 , a2 × b2 , ..., aN × bN ) es solamente zip
(*) as bs.
Una función muy útil es scanl(), definida en la figura 5.7.
scanl f q ys = q : (case ys of
[] -> []
x:xs -> scanl f (f q x) xs)
Figura 5.7: Ejemplo scanl en Haskell
133
scanl es similar a foldl, salvo por el hecho de que crea una lista con todos
los resultados intermedios acumulados, de forma que el primer elemento de
la lista resultado es q y el último es el resultado acumulado de toda la lista
de entrada. La longitud de la secuencia de salida es superior a la de entrada
en una unidad.
En el caso en el que esté garantizado que la secuencia de entrada xs no
esté vacı́a, la siguiente función scanl1 puede ser definida, conforme a la figura
5.8.
scanl1 f (x:xs) = scanl f x xs
Figura 5.8: Ejemplo scanl1 en Haskell
scanl1 se comporta igual que scanl, salvo que no toma un argumento como
base o elemento neutro, sino que toma al primer elemento de la lista como
elemento base para calcular las acumulaciones. Como puede comprobarse,
scanl1 op xs produce una lista de longitud igual a la de xs en la que aparecen
los resultados acumulados de la operación op desde el principio de la lista
hasta la posición actual. Por ejemplo: scanl1 (+) [1, 2, 3] = [1, 1+2, 1+2+3]
= [1, 3, 6].
scanl1 puede ser usado en combinación con zip para resolver el problema
mencionado en el apartado 5.1.1. Por ejemplo, scanl1 (+) (zip (*) [1,2,3]
[2,2,2]) devuelve [2, 6, 12], que es básicamente lo que se querı́a calcular con
el problema de las ventas de los libros.
Si se asocia a la función filter el significado de los predicados de XPath,
de forma que filter p xs = [ x | x ∈ xs ∧ p x ], pueden encontrarse fácilmente
soluciones para los problemas mencionados en el apartado 5.1.2. Por ejem-
plo, se pueden calcular todos los elementos de una secuencia para los cuales
f(item) es mı́nimo con la expresión de la figura 5.9. En ella se declara ys como
una lista temporal que almacena el resultado de aplicar la función f() a la
secuencia de entrada, se declara fmin como el mı́nimo valor de esa secuencia,
y a continuación se seleccionan aquellos elementos de la secuencia de entrada
para los que f() da ese valor mı́nimo fmin. El punto es considerado en Haskell
como el operador de composición de funciones.
De una forma similar, en la figura 5.10 se puede comprobar si para to-
dos los elementos de una secuencia se cumple que una función f() devuelve
resultados positivos.
Finalmente, comprobar que, para una secuencia y una función f(), el re-
134
minvals f xs =
let ys = map f xs in
let fmin = minimum ys in
filter ((= fmin) . f) xs
Figura 5.9: Elementos para los que f() es mı́nimo
allFPositive f xs =
let ys = map (( > 0) . f) xs in
foldl and true ys
Figura 5.10: Determinar si para una secuencia se devuelve todo positivo
sultado de aplicar f() a la secuencia proporciona una secuencia ordenada

creciente, es igualmente sencillo. En la figura 5.11 aparece un ejemplo basa-
do en foldl y zip. En ella se declara zs como el resultado de aplicar f() a la
secuencia de entrada. Posteriormente, la lista zs es fragmentada en dos sublis-
tas. init zs contiene la sublista en la que se ha eliminado el último elemento
y tail zs contiene la sublista en la que se ha eliminado el primer elemento.
Para esas dos sublistas, se comprueba que los elementos están ordenados por
parejas y finalmente se dilucida si todas esas parejas cumplen el hecho de
estar ordenadas o si, por el contrario, hay algún elemento en desorden.
allFIncreasing f xs =
let zs = map f xs in
let ys = zip (<) (init zs) (tail zs) in
foldl and true ys
Figura 5.11: Para una secuencia se devuelve ordenado
5.3. Lenguaje XTendedPath: extensión de

XPath 2.0
XPath es muy útil para direccionar elementos en un documento XML,
cuando éstos son fácilmente ubicables en un árbol del documento, es decir,
cuando el direccionamiento sea sencillo y la extracción de datos que se deben
obtener no sea demasiado complicada y se corresponda con algún elemento o
atributo. Sin embargo, conforme a lo documentado en el apartado 5.1, XPath
135
resulta ser algo limitado para ser usado como mecanismo de direccionamien-
to de datos que no se corresponden exactamente con elementos completos o
atributos del documento, sino que son trozos de éste, o datos secundarios, es
decir, cuando son datos que deben ser procesados por algún cómputo espe-
cificable por el usuario. XTendedPath presenta algunas soluciones siguiendo
las ideas presentadas en el apartado 5.2.
Consulta de documentos XML
Por una parte, XTendedPath puede ser usado para la consulta de docu-
mentos XML, con el fin de obtener datos de esos documentos. Con XTended-
Path, las reglas de extracción de datos en el Web que aparecen mencionadas
en el apartado 2.2.1 resultan sencillas de construir y fáciles de mantener. De
esta forma, expresiones XTendedPath de consulta aplicadas a cualquier docu-
mento XML, son capaces de extraer los datos relevantes que cualquier tarea
pueda necesitar. Estas expresiones, al estar basadas en XPath 2.0, son apli-
cables a cualquier documento XML y mantienen siempre una misma sintaxis
uniforme e independientemente del lenguaje XML concreto que esté siendo
usado por cada documento. En esto se difiere de algunos API como [139]
que están exclusivamente enfocados al uso de un lenguaje XML concreto de-
finido en un DTD o XML Schema y que no son utilizables por lo tanto en
otro tipo de documentos. Gracias a esa generalidad, XTendedPath es aplica-
ble no sólo a lenguajes XML como WML, RSS, SVG, MathML o NewsML,
sino que es igualmente a las páginas HTML del Web legado, aunque se re-
quiere que éstas también sigan los principios de buena formación de XML.
La plataforma sobre la que se ejecuta XTendedPath proporciona al progra-
mador mecanismos adecuados para que éste fácilmente consiga pretratar los
documentos que no cumplen esta propiedad con el fin de transformarlos en
documentos equivalentes bien formados. Esta transformación se lleva a cabo
gracias a aplicaciones externas diseñadas para esa labor, como [104, 58, 146].
Modificación de documentos XML
Por otro lado, XTendedPath también puede ser usado para la modifi-
cación de la versión almacenada en memoria de los documentos XML. La
modificación de esta estructura del documento puede afectar sólo a los atri-
butos, manteniendo intacta la estructura arbórea de los elementos de un
documento, o puede afectar también a la disposición de los elementos de un
documento modificando su estructura arbórea mediante la inserción o borra-
do de algunos de los mismos. Ejemplos de ambas situaciones son descritos a
136
continuación:
Un ejemplo de modificación que afecta exclusivamente a los atributos

de los elementos de un documento puede ser el rellenado de formularios.
Dicho rellenado puede fácilmente llevarse a cabo modificando simple-
mente en la representación arbórea del documento los valores de sus
atributos, de forma que queden ası́ rellenos de otra forma distinta a
aquella en la que vienen por defecto. Basta con cambiar en una página
el valor de los atributos value o checked de ciertos elementos input o,
por otro lado, los atributos selected de ciertos elementos option den-
tro de un elemento select, para rellenar los campos de un formulario
con nuevos datos.
La modificación de documentos consistente en la inserción, modifica-

ción o borrado de elementos dentro del árbol de un documento puede
formar parte de muy diversas tareas. Por ejemplo, en una tarea dedi-
cada a eliminar la publicidad de ciertas páginas, se deseará el borrado
de ciertos nodos dentro del árbol de un documento. En otras ocasiones,
la modificación de la estructura de un documento realizada de forma
explı́cita puede estar motivada por la falta de soporte por parte de la
plataforma de ejecución de acciones implı́citas programadas en ruti-
nas JavaScript, algo que como ya se vio en el apartado 3.4 es bastante
habitual. En esos casos, la emulación del código de las rutinas JavaS-
cript puede ser necesaria por parte del programador de la tarea desde
su programa principal. Por ejemplo, se deseará insertar nuevos nodos
dentro del documento si se desea emular a la acción JavaScript docu-
ment.write, consistente en embeber en una página nuevos elementos
escritos dinámicamente por el browser. Acciones de borrado de nodos
son también realizables mediante XTendedPath.
Relación de XTendedPath con XPath 2.0
XTendedPath no puede ser considerado un pionero en la extensión de

XPath 2.0, puesto que existen otros lenguajes igualmente basados en ese
borrador del W3C. El lenguaje XQuery (ver apartado 4.5) es un supercon-
junto de XPath 2.0 para la extracción de datos de documentos y bases de
datos XML. XQuery es usado como lenguaje de consulta en documentos y
bases de datos XML, pero no ha sido considerado para este trabajo porque
está enfocado a la generación de nuevos documentos XML, en lugar de a
la estructuración de los datos obtenidos en repositorios programables. Para
137
las modificaciones de datos (inserciones, borrados, modificaciones, ...) se sue-
len usar otros lenguajes, como XUpdate [148]. El lenguaje XSLT 2.0 [143]
también está basado en XPath 2.0. Igualmente, XPointer (ver apartado 4.3)
también está basado en XPath, aunque su versión actual toma como base
la versión estándar XPath 1.0 [129] y no en el actual borrador XPath 2.0.
La tabla 5.1 muestra un resumen comparativo de los lenguajes basados en
XPath.
Lenguaje Estatus Relación con XPath Finalidad

XQuery W3C WD Extensión de XPath 2.0 Extracción de datos
XSLT 1.0 W3C Rec Anfitrión de XPath 1.0 Transformación
XSLT 2.0 W3C WD Anfitrión de XPath 2.0 Transformación
XPointer W3C WD Extensión de XPath 1.0 Direccionamiento de partes contiguas
XUpdate XML-DB WD Anfitrión de XPath 1.0 Modificación
XTendedPath Extensión de XPath 2.0 Consulta y modificación
Cuadro 5.1: Resumen de los lenguajes basados en XPath
XPath 2.0 es un lenguaje bastante potente, al que sucesivas revisiones

realizadas desde su nacimiento han ido incorporando cada vez una mayor
funcionalidad. Frente a la simplicidad de XPath 1.0 capaz de direcciona-
mientos sencillos pero fácilmente entendibles por personas que no necesaria-
mente tengan conocimientos profundos de programación, XPath 2.0 ha ido
incorporando un potente conjunto de constructores que han ido aumentando
sensiblemente su potencia como lenguaje de direccionamiento, asemejándolo
cada vez más a un lenguaje de programación. Un mayor detalle de esas di-
ferencias entre XPath 2.0 y XPath 1.0 puede ser encontrado en el apartado
4.2. Sin embargo, a pesar de esta mayor potencia de direccionamiento de
XPath 2.0 respecto de su antecesora XPath 1.0, XPath 2.0 presenta algunas
limitaciones debidas principalmente a su capacidad de direccionar exclusiva-
mente elementos y atributos de páginas (no pueden direccionar otras partes
del documento), y al limitado conjunto de funciones de obtención de datos
secundarios que ofrece una pequeña biblioteca que no es extensible por los
usuarios ni ofrece capacidades de manipulación adecuadas para tratamientos
más complejos de los contemplados por las primitivas accesibles en esas bi-
bliotecas. Por esta razón, XTendedPath ha sido creado como una extensión
lo más cercana posible de XPath 2.0. XTendedPath permite eliminar algunas
de las restricciones de XPath 2.0, permitiendo direccionar algunos datos que
138
XPath 2.0 no puede direccionar por sı́ solo y que no necesariamente deben
ajustarse a ser un elemento o un atributo, a la vez que permite mejorar la
construcción de expresiones definibles por el usuario. El conjunto de estas ex-
tensiones es relativamente pequeño, pero significativamente importante como
para aumentar significativamente la capacidad de expresión del estándar.
Asimismo, en XTendedPath han sido eliminadas algunas construcciones
de XPath 2.0 consideradas como prescindibles para los objetivos que se per-
sigue en este trabajo. Existen constructores definidos en XPath y no contem-
plados por XTendedPath (porque no han sido considerados imprescindibles),
de la misma forma que existen constructores definidos en XTendedPath y no
contemplados por XPath 2.0 (las extensiones para aumentar la flexibilidad
de XPath 2.0 y su habilidad para modificar documentos). Sin embargo, las
diferencias entre ambos lenguajes son relativamente muy pequeñas. Ambos
lenguajes coinciden en gran parte, permitiendo que muchas construcciones
puedan ser escritas de forma similar tanto en XPath 2.0 como en XTended-
Path sin apenas diferencias semánticas, tal como puede verse reflejado en el
apartado 5.4.
Una de las caracterı́sticas mejorables que ofrece XTendedPath y donde
reside la mayor parte de las diferencias con XPath 2.0 es su sintaxis. XTen-
dedPath está definido con una notación sintáctica de expresiones funcionales
parentizadas, algo bastante diferente a la sintaxis reflejada por XPath, forma-
da como una secuencia de pasos que implı́citamente toman como argumento
los resultados del paso anterior. Ambas notaciones, la parentizada de XTen-
dedPath y la original de XPath son directamente traducibles la una a la otra,
ya que, a fin de cuentas esta diferencia es simplemente sintáctica. De
hecho, en muchas de las funciones de XTendedPath que aparecen en el apar-
tado 5.4 se define la expresión XPath equivalente. La notación parentizada
en la que está definido el lenguaje XTendedPath no es quizá la mejor que
podrı́a haberse utilizado para definir los operadores del lenguaje. No obstan-
te, es la que la plataforma de navegación automatizada en su estado actual
ha permitido y, aunque mejorable, sus diferencias con respecto a la versión
original de XPath son meramente notacionales más que semánticas. Aunque
la notación parentizada es más verbosa, ésta resulta estar más enfocada a una
más sencilla traducibilidad ya que el árbol de llamadas de expresiones queda
en XTendedPath más parecido a otros lenguajes de programación gracias
a esa parentización. No obstante, muchos paréntesis que en otros lenguajes
no deberı́an aparecer, aquı́ deben escribirse para encerrar a los distintos ar-
gumentos de las funciones. La aplicación parcial de funciones currificadas
permite declarar más fácilmente algunas expresiones muy usadas en XPath
que no son evualuables en el momento sino que se evaluarán en el momento
139
en el que les corresponda cuando exista para ellos un conjunto no vació de
nodos de contexto a los que ser aplicadas. Las variables de XTendedPath,
por su parte, no van precedidas del sı́mbolo del dólar $ como en XPath. No
obstante, es esperable poder mejorar esta sintaxis en futuras versiones del
lenguaje gracias a una herramienta de traducción como las que se están de-
sarrollando en el marco de unas herramientas CASE como proyectos fin de
carrera dirigidos por el autor de este trabajo. Gracias a estos traductores,
estas diferencias sintácticas acabarán finalmente por ser salvadas.
XTendedPath toma como base una versión funcional parentizada de
XPath 2.0 a la cual se le añaden nuevas funcionalidades. Ası́ pues, para empe-
zar a definir XTendedPath se necesita empezar definiendo cómo se reescriben
en XTendedPath los distintos componentes que ya aparecen recogidos en el
estándar de XPath. El apartado 5.4 contempla esa parte común entre ambos
lenguajes, mientras que el apartado 5.5 enumera las principales extensiones
que forman parte de XTendedPath y no forman parte de XPath 2.0.
5.4. Componentes comunes con XPath 2.0
5.4.1. Tipos de datos comunes
Los tipos de datos de XTendedPath son prácticamente los mismos de

los de XPath, salvo por el hecho de que se han agrupado algunos de ellos
para ganar simplicidad, se les han impuesto algunas pequeñas restricciones
y se les ha ampliado con algunas extensiones. Por ejemplo, en XPath 2.0
las expresiones de tipo secuencia pueden albergar cualquier tipo de dato
atómico, por lo que a una misma secuencia pueden pertenecer tanto valores
numéricos como nodos de un documento. En XTendedPath, para simplificar
el procesamiento a los programadores, se ha impuesto la restricción de que
todos los elementos de una misma secuencia deben ser del mismo tipo de
datos, de forma que las secuencias puedan ser sólo de números, sólo de nodos
o sólo de cualquier tipo de dato. Al igual que en XPath, las secuencias de
secuencias están prohibidas, por lo que todas las secuencias deben ser planas.
La tabla 5.2 refleja un resumen de como los principales tipos de datos de
XPath se ven reflejados en XTendedPath.
140
XTendedPath XPath Ejemplo/Comentario
boolean boolean true, false
number decimal, float y double 1, -2, 0.5
string string, hexBinary, base64Binary “El precio es”
node node, document /*[3], /, //form
a* | a ∈ {otros tipos} secuencia node*, number*, string*, ...
no contemplado otros de XML Schema fechas, duraciones, ...
no contemplado item Tipos atomic | node de XPath
Cuadro 5.2: Reescritura de tipos de datos de XPath en XTendedPath
5.4.2. Consideraciones semánticas
Para proporcionar una semántica no ambigua a cada uno de los opera-

dores de XTendedPath, se definen a continuación unos operadores que no
forman parte del lenguaje XTendedPath. Como ya hicieron en [145, 144]
con XPath, sirven para explicar formalmente la semántica de muchos de los
operadores de XTendedPath.
Función name
La función name devuelve para una etiqueta, su nombre.

name: node → string
Función size
La función size devuelve para una secuencia (de cualquier tipo), su núme-
ro de elementos.
size: a* → integer
Función children
La función children devuelve los hijos de un nodo.

children: node → node*
141
Función parent
La función parent devuelve el padre de un nodo, que de existir es siempre

único. El padre del elemento raı́z es ∅.
parent: node → node{0,1}
Función attribute
La función attribute devuelve el valor de un atributo de un nodo. Si el

nodo no tiene ese atributo, el resultado es ∅.
attribute: string → node → string{0,1}
Función siblings
La función siblings devuelve los nodos que son hijos del mismo padre del
argumento.
siblings: node → node*
siblings(x) = {z | ∃ y ∈ parent(x) ∧ z ∈ children(y)}
Función properSiblings
La función properSiblings devuelve los nodos hermanos del argumento.

properSiblings: node → node*
properSiblings(x) = {y | y ∈ siblings(x) ∧ x 6= y}
Función self
La función self devuelve como resultado el conjunto formado por su pro-

pio argumento.
self: node → node1 / self(x) = {x}
Operador de orden en el documento
El operador infijo ≤doc indica si el primer elemento aparece antes que el

segundo dentro del documento.
142
≤doc : node → node → boolean
Operadores de cierre
Se definen igualmente los dos siguientes operadores de cierre.

r+ (x) = {z | ∃ y ∈ r(x) ∧ z ∈ r∗ (y)}
r∗ (x) = {x} ∪ r+ (x)
De esta forma, children+ (x) son todos los descendientes de x (sin incluir
a x), mientras que children∗ (x) son todos los descendientes de x (incluyendo
a x).
Con estas funciones auxiliares, se puede empezar a definir la semántica
de los operadores de XTendedPath.
5.4.3. Funciones de comparación
Para facilitar la programación de expresiones de comparación, estos ope-

radores se han reescrito como funciones currificadas. En la tabla 5.3 puede
verse el significado de esos operadores tanto en XPath como en XTended-
Path. Puede apreciarse también la existencia de paréntesis para separar los
operandos debido a que en la implementación actual todos los argumentos
de las funciones deben estar rodeados entre paréntesis. No obstante, esta
salvedad sintáctica seguramente será mejorada en futuras versiones.
Cabecera función XTendedPath XPath

EQ: a → b → boolean EQ(3)(4) 3=4
NE: a → b → boolean NE(3)(4) 3 != 4
LT: number → number → boolean LT(3)(4) 3<4
LE: number → number → boolean LE(3)(4) 3 <= 4
GE: number → number → boolean GE(3)(4) 3 >= 4
GT: number → number → boolean GT(3)(4) 3>4
Cuadro 5.3: Operadores de comparación en XTendedPath
143
5.4.4. Funciones lógicas
Para facilitar la programación de expresiones lógicas, varios de los conec-

tores lógicos más habituales también se han reescrito como funciones currifi-
cadas. En la tabla 5.4 puede verse el significado de esos operadores tanto en
XPath como en XTendedPath.
En cuanto a las operaciones aritméticas, como las sumas, restas, multi-
plicaciones y divisiones, se escriben en XTendedPath igual que en XPath y
en la gran mayorı́a de los lenguajes de programación.
Cabecera función XTendedPath XPath

NOTF: boolean → boolean NOTF(a) not($a)
ANDF: boolean → boolean → boolean ANDF(a)(b) $a and $b
ORF: boolean → boolean → boolean ORF(a)(b) $a or $b
Cuadro 5.4: Operadores lógicos en XTendedPath
5.4.5. Función TO: (generador de secuencias numéri-

cas)
La función TO sirve para generar secuencias de valores numéricos enteros.

Se corresponde con el operador infijo to de XPath. La tabla 5.5 refleja las
formas de escribirse ese operador con XPath y con XTendedPath.
TO: integer → integer → integer*
XTendedPath XPath Valor

TO(1)(4) 1 to 4 Secuencia de naturales entre 1 y 4
TO(4)(1) 4 to 1 Secuencia vacı́a
Cuadro 5.5: Generador de secuencias numéricas en XTendedPath
144
5.4.6. Funciones EVERY y SOME: (expresiones cuan-
tificadas)
Las expresiones cuantificadas EVERY y SOME sirven para dictaminar
si, bien todos, bien alguno, de los elementos de una secuencia cumplen una
determinada propiedad. La tabla 5.6 expresa la semántica de estas expresio-
nes.
EVERY: (a → boolean) → a* → boolean
SOME: (a → boolean) → a* → boolean
Significado XTendedPath XPath

EVERY(f)(b) ≡ ∀ x | x ∈ b ∧ f(b) = true EVERY(NE(3))(b) every $x in $b satisfies 3 != $x
SOME(f)(b) ≡ ∃ x | x ∈ b ∧ f(b) = true SOME(NE(3))(b) some $x in $b satisfies 3 != $x
Cuadro 5.6: Expresiones cuantificadas en XTendedPath
5.4.7. Funciones eje

Los ejes de XPath se corresponden con las siguientes funciones en XTen-
dedPath.
Función C: (eje child)
El eje de navegación child:: de XPath sirve para seleccionar los nodos

hijos de un nodo contexto. En XTendedPath es reescrito como una función
currificada, donde el primer argumento puede ser, o bien un string que in-
dica el nombre de los elementos que deben ser buscados como hijos, o bien
directamente una lista de nodos de la que se deben seleccionar exclusivamen-
te aquellos que sı́ cumplan la propiedad de ser hijos del nodo contexto. El
segundo argumento de la función es una lista de nodos contexto a partir de
los cuales debe empezar a evaluarse la expresión anterior de descendencia di-
recta. El resultado final es una secuencia de nodos. La cabecera de la función
es la siguiente:
C: (string|node*) → (node|node*) → node*
En la tabla 5.7 se detalla la semántica de la función C. En todos los casos
se asume que b: node*.
145
XTendedPath XPath Significado
C(“*”)(b) $b/child::* {x | ∃ y ∈ b ∧ x ∈ children(y)}
C(s)(b) $b/child::s {x | ∃ y ∈ b ∧ x ∈ children(y) ∧ name(x) = s}
C(a)(b) $b/child::$a a ∩ {x | ∃ y ∈ b ∧ x ∈ children(y)}
Cuadro 5.7: Semántica de la función C
A modo de ejemplo, la tabla 5.8 muestra el significado currificado de la

función C. En todos los casos se asume que b: node*, s: string, a: node*. El
valor, como cabe esperar es el de una expresión lambda como la que aparece
en la tercera columna de la tabla.

C(“*”) child::* λ b. {x | ∃ y ∈ b ∧ x ∈ children(y)}
C(s) child::s λ b. {x | ∃ y ∈ b ∧ x ∈ children(y) ∧ name(x) = s}
C(a) child::$a λ b. a ∩ {x | ∃ y ∈ b ∧ x ∈ children(y)}
Cuadro 5.8: Ejemplo de la aplicación de la currificación en la función C
Función D: (eje descendant)
El eje de navegación descendant:: sirve en XPath para seleccionar los

descendientes del nodo de contexto a cualquier nivel de profundidad. Dicho
operador se reescribe en XTendedPath de forma similar a como se reescribe el
eje child::, conservando, al igual que en las siguientes funciones, la forma de
expresión currificada, razón por la cual, no se va a detallar el uso currificado
de esas funciones de ahora en adelante en detalle. Su semántica es práctica-
mente la misma que la del eje child, salvo que se no restringe sólo al primer
nivel de descendencia directa, es decir, a los hijos, sino que se exploran todos
los niveles de descendencia.
D: (string|node*) → (node|node*) → node*
En la tabla 5.9 se detalla la semántica de la función D. En todos los casos
146
XTendedPath XPath 1er argumento Significado
D(“*”)(b) $b/descendant::* “*” ∈ string {x | ∃ y ∈ b ∧ x ∈ children+ (y)}
D(s)(b) $b/descendant::s s: string {x | ∃ y ∈ b ∧ x ∈ children+ (y) ∧ name(x) = s}
D(a)(b) $b/descendant::$a a: node* a ∩ {x | ∃ y ∈ b ∧ x ∈ children+ (y)}
Cuadro 5.9: Semántica de la función D
Función DORSELF: (eje descendant-or-self )
El eje de navegación descendant-or-self:: se reescribe en XTendedPath de

forma similar al eje descendant::, salvo por el hecho de que se incluye al nodo
contexto entre el resultado. La función DORSELF sirve para calcular esos
descendientes.
DORSELF: (string|node*) → (node|node*) → node*
En la tabla 5.10 se detalla la semántica de la función DORSELF. En
todos los casos se asume que b: node*.
XTendedPath XPath 1er argum. Significado

DORSELF(“*”)(b) $b/descendant-or-self::* “*” ∈ string {x | ∃ y ∈ b ∧ x ∈ children∗ (y)}
DORSELF(s)(b) $b/descendant-or-self::s s: string {x | ∃ y ∈ b ∧ x ∈ children∗ (y) ∧ name(x) = s}
DORSELF(a)(b) $b/descendant-or-self::$a a: node* a ∩ {x | ∃ y ∈ b ∧ x ∈ children∗ (y)}
Cuadro 5.10: Semántica de la función DORSELF
Función P: (eje parent)
El eje de navegación parent:: se reescribe en XTendedPath de forma si-

milar al eje child::, salvo por el hecho de que ya no se buscan nodos hijos
del actual, sino el nodos padre de cada nodo de la secuencia recibida como
segundo argumento. La función P devuelve la secuencia formada por estos
padres.
P: (string|node*) → (node|node*) → node*
En la tabla 5.11 se detalla la semántica de la función P. En todos los casos
147
P(“*”)(b) $b/parent::* {x | ∃ y ∈ b ∧ x ∈ parent(y)}
P(s)(b) $b/parent::s {x | ∃ y ∈ b ∧ x ∈ parent(y) ∧ name(x) = s}
P(a)(b) $b/parent::$a a ∩ {x | ∃ y ∈ b ∧ x ∈ parent(y)}
Cuadro 5.11: Semántica de la función P
Función A: (eje ancestor)
El eje de navegación ancestor:: se reescribe en XTendedPath de forma

similar al eje descendant::, salvo por el hecho de que ya no se buscan nodos
descendientes del actual, sino nodos ancestros del mismos. La función A sirve
para calcular esos ancestros.
A: (string|node*) → (node|node*) → node*
En la tabla 5.12 se detalla la semántica de la función A. En todos los
casos se asume que b: node*.

A(“*”)(b) $b/ancestor::* {x | ∃ y ∈ b ∧ x ∈ parent+ (y)}
A(s)(b) $b/ancestor::s {x | ∃ y ∈ b ∧ x ∈ parent+ (y) ∧ name(x) = s}
A(a)(b) $b/ancestor::$a a ∩ {x | ∃ y ∈ b ∧ x ∈ parent+ (y)}
Cuadro 5.12: Semántica de la función A
Función AORSELF: (eje ancestor-or-self )
El eje de navegación ancestor-or-self:: se reescribe en XTendedPath de

forma similar al eje ancestor::, salvo por el hecho de que se incluye al nodo
contexto entre el resultado. La función AORSELF sirve para calcular esos
ancestros.
AORSELF: (string|node*) → (node|node*) → node*
En la tabla 5.13 se detalla la semántica de la función AORSELF. En todos
los casos se asume que b: node*.
148
AORSELF(“*”)(b) $b/ancestor-or-self::* {x | ∃ y ∈ b ∧ x ∈ parent∗ (y)}
AORSELF(s)(b) $b/ancestor-or-self::s {x | ∃ y ∈ b ∧ x ∈ parent∗ (y) ∧ name(x) = s}
AORSELF(a)(b) $b/ancestor-or-self::$a a ∩ {x | ∃ y ∈ b ∧ x ∈ parent∗ (y)}
Cuadro 5.13: Semántica de la función AORSELF
Función PS: (eje preceding-sibling)
El eje de navegación preceding-sibling:: se reescribe en XTendedPath de

forma similar a los ejes anteriormente mencionados, salvo por el hecho de
que ya no se buscan nodos hijos del actual, sino los nodos hermanos que sean
anteriores al mismo. La función PS devuelve una secuencia formada por esos
nodos.
PS: (string|node*) → (node|node*) → node*
En la tabla 5.14 se detalla la semántica de la función PS. En todos los

PS(“*”)(b) $b/preceding-sibling::* {x | ∃ y ∈ b ∧ x ∈ properSiblings(y) ∧ x ≤doc y}
PS(s)(b) $b/preceding-sibling::a {x | ∃ y ∈ b ∧ x ∈ properSiblings(y) ∧ x ≤doc y ∧ name(x) = s}
PS(a)(b) $b/preceding-sibling::$a a ∩ {x | ∃ y ∈ b ∧ x ∈ properSiblings(y) ∧ x ≤doc y}
Cuadro 5.14: Semántica de la función PS
Función FS: (eje following-sibling)
El eje de navegación following-sibling:: se reescribe en XTendedPath de

forma similar a los ejes anteriormente mencionados, salvo por el hecho de
que ya no se buscan nodos hijos del actual, sino los nodos hermanos que sean
posteriores el mismo. La función FS devuelve una secuencia formada por esos
nodos.
FS: (string|node*) → (node|node*) → node*
En la tabla 5.15 se detalla la semántica de la función FS. En todos los
149
FS(“*”)(b) $b/following-sibling::* {x | ∃ y ∈ b ∧ x ∈ properSiblings(y) ∧ y ≤doc x}
FS(s)(b) $b/following-sibling::a {x | ∃ y ∈ b ∧ x ∈ properSiblings(y) ∧ y ≤doc x ∧ name(x) = s}
FS(a)(b) $b/following-sibling::$a a ∩ {x | ∃ y ∈ b ∧ x ∈ properSiblings(y) ∧ y ≤doc x}
Cuadro 5.15: Semántica de la función FS
Función PREC: (eje preceding)
La función PREC extrae de un documento todos aquellos nodos que apa-

recen antes del nodo contexto en el orden del documento, sin incluir a sus
nodos ascendientes, tal y como especifica el estándar de XPath para el eje
preceding.
PREC: (string|node*) → (node|node*) → node*
En la tabla 5.16 se detalla la semántica de la función PREC.

PREC(“*”)(b) $b/preceding::* {x | ∃ y ∈ b ∧ end(x) ≤doc beg(y)} − A(“*”)(b)
PREC(s)(b) $b/preceding::a {x | ∃ y ∈ b ∧ end(x) ≤doc beg(y) ∧ name(x) = s} − A(s)(b)
PREC(a)(b) $b/preceding::$a (a ∩ {x | ∃ y ∈ b ∧ end(x) ≤doc beg(y)}) − A(a)(b)
Cuadro 5.16: Semántica de la función PREC
Función FOLL: (eje following)
La función FOLL extrae de un documento todos aquellos nodos que apa-

recen después del nodo contexto en el orden del documento, sin incluir a sus
nodos descendientes, tal y como especifica el estándar de XPath para el eje
following.
FOLL: (string|node*) → (node|node*) → node*
En la tabla 5.17 se detalla la semántica de la función FOLL.
150
FOLL(“*”)(b) $b/following::* {x | ∃ y ∈ b ∧ end(y) ≤doc beg(x)} − D(“*”)(b)
FOLL(s)(b) $b/following::a {x | ∃ y ∈ b ∧ end(y) ≤doc beg(x) ∧ name(x) = s} − D(s)(b)
FOLL(a)(b) $b/following::$a (a ∩ {x | ∃ y ∈ b ∧ end(y) ≤doc beg(x)}) − D(a)(b)
Cuadro 5.17: Semántica de la función FOLL
Función AT: (eje attribute)
El eje de navegación attribute::, se utiliza para direccionar en XPath a los

atributos del nodo de contexto. Este eje es reescrito en XTendedPath como
una función currificada, donde el primer argumento es un string que almacena
el nombre del atributo seleccionado. El segundo argumento de la función es
una secuencia de nodos contexto para los cuales se busca el atributo cuyo
nombre está en el primer argumento. Como de cada nodo contexto sólo se
puede sacar al menos un atributo con el nombre del valor del atributo igual
al especificado como argumento, el resultado final es una secuencia de strings
con una longitud menor o igual a la del segundo argumento. La cabecera de
la función es la siguiente:
AT: string → (node|node*) → string*
En la tabla 5.18 se detalla la semántica de la función AT. Se asume que
b: node*.

AT(s)(b) $b/attribute::s {x | ∃ y ∈ b ∧ x ∈ attribute(s)(y)}
Cuadro 5.18: Semántica de la función AT
Función TEXT: (texto)
La función TEXT extrae el texto (sin etiquetas) de los nodos que recibe
por argumento y los devuelve concatenados en el resultado. Para ello, se tiene
en cuenta el texto de todos sus nodos descendientes, eliminando marcado, co-
mentarios y atributos. Téngase en cuenta que el texto resultado aparecerá en
el mismo orden que en el documento sólo si la secuencia de entrada está en
ese mismo orden. Ası́ pues, la cabecera de la función aparece en la tabla 5.19.
151
XTendedPath Cabecera XPath Cabecera
TEXT(a) node* → string $a/text() node → string
Cuadro 5.19: Texto de nodos en XTendedPath
5.4.8. Función F: (predicados)
Los predicados en XPath se escriben como expresiones booleanas entre

corchetes a la derecha de cada paso o step que forma una expresión XPath.
Los predicados sirven para establecer una condición de filtro de forma que
se seleccionan exclusivamente aquellos nodos contexto que superen una con-
dición, descartándose ası́ aquellos que nodos que no la cumplan. Por ejemplo,
la siguiente expresión forma en XPath la secuencia de números pares entre 1
y 10.
(1 to 10)[. mod 2 = 0]
Desde el punto de vista de XTendedPath, los predicados son funciones,
tı́picamente anónimas (no tienen nombre, sino que se especifican in situ), que
se aplican al nodo contexto para dictaminar si éste cumple las condiciones
de pertenecer o no a la secuencia resultado. Dicho de otra forma, se trata
de expresiones lambda construidas para la ocasión por el programador que,
tomando como argumento una secuencia de nodos contexto o de elementos
de cualquier otro tipo, devuelve un valor booleano para cada uno de ellos
que decide si el elemento forma parte del resultado o si por el contrario
no forma parte del mismo. Si la aplicación de la función recibida sobre un
elemento contexto devuelve un valor booleano de cierto, el elemento pasa a
formar parte del resultado del predicado. Si la aplicación de la función sobre
el elemento contexto devuelve un valor booleano de falso, el nodo contexto
no forma entonces parte del resultado. Los predicados se pueden aplicar al
resultado devuelto por otros predicados aplicados previamente.
En XTendedPath los predicados se reescriben como una función currifi-
cada, donde el primer argumento es la función de filtro que debe aplicarse
cada vez sobre los distintos elementos individuales que forman parte de la
secuencia recibida como segundo argumento. El resultado final es el subcon-
junto de elementos del segundo argumento que cumplen como caracterı́stica
haber recibido un valor de verdad de cierto cuando se les evaluó con la fun-
ción recibida como primer argumento. La cabecera de esta función aparece a
continuación.
F: (a → boolean) → a* → a*
Ahora bien, los predicados en XPath también tienen otra cabecera po-
152
sible, esto es, otra semántica bien distinta que también es considerada en
XTendedPath. Cuando el primer argumento de la función F, en lugar de ser
una función que devuelva cierto o falso para cada nodo de contexto, es un
simple valor numérico entero, el resultado de la función F debe ser el elemento
de la secuencia del segundo argumento que está en la posición indicada por el
primer argumento, empezando por el valor 1 y terminando por el valor de la
longitud del segundo argumento (valor last()). Dicha semántica de función se
corresponde con la siguiente cabecera. Nótese, que, en este caso, el tipo final
de resultado ya no es una secuencia, sino un único elemento de la misma.
F: integer → a* → a
Finalmente, existe una tercera forma de reescribir los predicados de XPath
en XTendedPath, que es mediante la aplicación de una función que, al con-
trario de la primera, en lugar de devolver un booleano para cada elemento
de la secuencia, lo que devuelve es una secuencia de cualquier tipo de datos,
tı́picamente del mismo tipo que los del resto de la secuencia que recibe de
entrada, pero no necesariamente. Si esa secuencia está vacı́a, se asimila que
el elemento no debe formar parte del resultado, pero sı́ debe formar parte
de ese resultado en el caso en el que esa secuencia sı́ tenga algún elemento.
Esta forma de expresión es usada habitualmente para seleccionar nodos de
elementos que cumplen la propiedad de tener ciertos descendientes o ascen-
dientes que a su vez puedan cumplir otras propiedades definidas con otros
predicados. La ventaja de poder componer predicados es que permite al pro-
gramador definir funciones que deben aplicarse a elementos que aún no han
sido calculados. La cabecera de esta forma es la siguiente.
F: (a → c*) → a* → a*, donde tı́picamente a: node ∧ (c: node ∨ c:
string)
En la tabla 5.20 se detalla la semántica de la función F en estas tres
posibilidades. Se asume que b es una secuencia de elementos de tipo a.
XTendedPath XPath 1er argumento Significado

F(f)(b) $b[f] f: a → boolean {x | x ∈ b ∧ f(x) = true}
F(n)(b) $b[n] n: integer {x | x ∈ b ∧ size({y | y ∈ b ∧ y ≤doc x}) = n}
F(g)(b) $b[g] g: a → c* {x | x ∈ b ∧ g(x) 6= ∅}
Cuadro 5.20: Semántica de la función F
153
5.4.9. Elemento raı́z del documento
El elemento raı́z de un documento, que normalmente se representa en
XPath como una barra inclinada (/), también tiene su correspondiente re-
presentación en XTendedPath. Ası́ pues, en XTendedPath se ha definido la
función ROOT la semántica que aparece en la tabla 5.21.
XTendedPath Cabecera XPath Significado

ROOT(a) ROOT: node → node fn:root($a) x | x ∈ parent∗ (a) ∧ parent(x) = ∅
Cuadro 5.21: Elemento raı́z del documento
5.4.10. Funciones de datos secundarios

Las siguientes funciones sirven para extraer datos secundarios de un do-
cumento. Los datos secundarios son aquellos que no residen fı́sicamente en
el documento del que son extraı́dos, sino que son computados a partir de
un subconjunto de datos primarios (que sı́ residen en el documento y por
lo tanto son directamente extraı́bles sin computaciones). Al igual que en
XPath, XTendedPath define las siguientes funciones de datos secundarios,
cuya semántica puede verse en la tabla 5.22.
Cabecera XTendedPath XPath Significado

MIN: number* → number MIN(a) xf:min($a) x|∀y∈a∧x≤y
MAX: number* → number MAX(a) xf:max($a) x|∀y∈a∧y≤x
P
SUM: number* → number SUM(a) xf:sum($a) a
COUNT: a* → number COUNT(a) xf:count($a) size(a)
P
AVG: number* → number AVG(a) xf:avg($a) ( a) ÷ size(a)
Cuadro 5.22: Funciones de datos secundarios
5.4.11. Operaciones con secuencias

Al igual que XPath, XTendedPath usa operaciones que trabajan con se-
cuencias, para realizar operaciones de unión, intersección y diferencia de con-
juntos, conforme a la tabla 5.23. En las tres expresiones (unión, intersección
154
y diferencia) se eliminan los elementos que ya estén replicados, de forma que
formen parte del resultado una única vez. En XTendedPath, las operaciones
se han definido como funciones currificables, en lugar de operadores infijos
como en XPath.
Cabecera XTendedPath XPath Significado

U: a* → a* → a* U(a)(b) $a | $b ó $a union $b a∪b
I: a* → a* → a* I(a)(b) $a intersect $b a∩b
E: a* → a* → a* E(a)(b) $a except $b a−b
Cuadro 5.23: Expresiones con secuencias
La siguiente expresión XTendedPath (a continuación figura la expresión

XPath equivalente) calcula los elementos que deben procesarse para rellenar
un formulario HTML almacenado en la variable f1.
U(D(“input”)(f1))(U(D(“select”)(f1))(D(“textarea”)(f1)))
$f1//input | $f1//select | $f1//textarea
5.5. Extensiones propias de XTendedPath

El presente apartado presenta, dentro del marco del lenguaje XTended-
Path, un conjunto de extensiones que no forman parte del actual borrador
de XPath y que incrementan sensiblemente la expresividad y capacidad de
direccionamiento y añadiendo nuevas funcionalidades. Estas extensiones son
respetuosas con la forma en la que se han reescrito en XTendedPath los prin-
cipales componentes de XPath, tal y como queda reflejado en el apartado 5.4.
Esas extensiones pueden ser clasificadas dentro de los siguientes ámbitos.
1. Por un lado, se han analizado las ventajas e inconvenientes de algunos

de los operadores genuinos de XPointer, y se han seleccionado aque-
llos que aportaban alguna funcionalidad útil que no estuviera presente
en XPath. Gracias a esa selección, se han incorporado a XTendedPath
dos nuevos tipos de datos no contemplados en XPath: los puntos y
los rangos. Estos nuevos tipos de datos permiten un mejor direccio-
namiento de trozos de documentos que no se corresponden con elemen-
tos, atributos, textos simples o secuencias. Además, se han establecido
155
también algunas restricciones enfocadas, por una parte a mejorar la
robustez de las reglas de extracción que manejan esos nuevos tipos
de datos, conservando la semántica definida de aquellos operadores de
XPath que tienen correspondencia con primitivas de XTendedPath, y
por otra, asegurando que las operaciones definidas sobre los nuevos ti-
pos de datos sólo pueden dar resultados correctamente procesables y
conformes a la buena formación de XML. El apartado 5.5.1 contempla
la descripción de estas extensiones dentro del lenguaje XTendedPath.
2. En segundo lugar, para mejorar la capacidad de encapsulación y reuti-

lización del código de las expresiones XTendedPath, se les ha dotado a
éstas de una forma de definir funciones de usuario sin nombre, esto
es, expresiones lambda conforme a las recomendaciones mencionadas
en el apartado 5.2, a las que se las ha acompañado de una biblioteca
extensible de funciones de orden superior. Por supuesto, con el
constructor let es posible asociar nombres a esas expresiones lambda
para crear ası́ funciones con nombre. Estas funciones definibles por el
usuario permiten que el usuario pueda reutilizar su propio código encap-
sulándolo en funciones ubicadas en sus propias bibliotecas de usua-
rio, algo que no es realizable en XPath. El apartado 5.5.2 contempla
la descripción de estas extensiones dentro del lenguaje XTendedPath.
3. En tercer lugar, se contemplan las extensiones para la modificación

de documentos XML, enumeradas en el apartado 5.5.3.
5.5.1. Extensiones provenientes de XPointer

Las extensiones provenientes de XPointer son de muy variado tipo. Hay
algunas que, modelizando una idea simple, resultan muy útiles para pro-
porcionar robustez. Otras, permiten mejorar con nuevos tipos de datos la
granularidad de los resultados accesibles, pero sólo un subconjunto de esos
nuevos tipos de datos resultan interesantes, pues hay algunos de ellos que no
pueden participar en ciertas operaciones, razón por la cual su incorporación
a XTendedPath viene acompañada de un conjunto de restricciones.
Evaluación alternativa
La evaluación alternativa es un concepto muy sencillo que, apareciendo

en la recomendación de XPointer, no aparece sin embargo en la de XPath 2.0.
El principio básico de la evaluación alternativa consiste en permitir el acceso
156
a un dato, estableciendo, no una, sino varias expresiones de acceso alternati-
vas. Mediante la utilización de varias expresiones de consulta alternativas, si
alguna falla en su cometido, otra expresión puede ser evaluada en su lugar,
obteniendo el resultado esperado por otro camino o forma de acceso.
En XPointer, las distintas expresiones que forman parte de una misma
expresión alternativa, se representan concatenadas una a continuación de la
otra en una secuencia. El resultado será la secuencia vacı́a sólo si todas las
expresiones que forman la secuencia dan ese mismo resultado. La primera
expresión por la izquierda que dé un resultado distinto de la secuencia vacı́a
es considerada como satisfactoria, razón por la cual no se considera necesaria
la evaluación de las expresiones que están a la derecha de ésta. A la hora de
evitar posibles ambigüedades al incorporar esta expresión en XTendedPath,
se ha elegido el uso de un operador binario denominado EVALALT, que
recibe dos argumentos, tal y como figura su descripción en la tabla 5.24. La
evaluación de más de dos expresiones alternativas se puede realizar combi-
nando el operador con el uso de los paréntesis.
XTendedPath XQuery (let no es operador de XPath) Significado

EVALALT(a,b) let $c = a in if $c != () then $c else b (a | a 6= ∅) , (b | a = ∅)
Cuadro 5.24: Operador de evaluación alternativa
Tipo punto
Los puntos (point) se definen como posiciones concretas dentro de los

documentos XML. Un punto en XPointer representa la posición interme-
dia entre dos componentes del documento, dondequiera que cualquiera de
esos componentes pueden ser caracteres de una zona de texto, entidades o
nodos (elementos) de un documento XML. Los puntos, al ser simples posi-
ciones intermedias, no albergan por sı́ mismos ningún dato y, por lo tanto
no tienen, en principio, interés desde el punto de vista de la integración de
datos semiestructurados (razón por la cual no forman seguramente parte del
la especificación de XPath). Sin embargo, pueden ser útiles para definir los
lugares en los que pueden aplicarse modificaciones puntuales a documentos
XML o pueden servir como delimitadores de los rangos, esto es, de fragmen-
tos de documentos que aparecen como una generalización del concepto de
nodo y que aparecen comentados más adelante en este documento, también
como extensión proveniente de XPointer para XTendedPath. Por otro lado,
157
no todos los puntos tienen la misma relevancia a la hora de ser convenien-
temente direccionados. Poder definir todos y cada uno de ellos implica en
XPointer la utilización de constructores basados en posiciones numéricas que
al ser posiblemente cambiantes en futuras versiones del documento, por lo
tanto, resultan ciertamente poco robustos como modelo para direccionarlos.
Sin embargo, otros puntos sı́ pueden ser más robustamente direccionables y
no sufrir tanto las variaciones ante cambios producidos en los documentos.
El mismo XPointer establece ası́ una clara distinción entre los node-points y
los character-points, los cuales merecen las siguientes consideraciones.
Los character-points no tienen vı́nculos con la estructura arbórea de

XML, sino con los fragmentos de texto alrededor de los cuales están
definidos. En términos generales, la estructura arbórea de un documen-
to XML suele mantenerse relativamente estable en el tiempo frente a las
modificaciones que suelen afectar al resto del documento. Para mejorar
la robustez ante las modificaciones que sufre el documento, se puede
tomar como referencia algún contenido textual que, se pueda esperar
que aparezca invariantemente en el documento. De esta forma, se define
un character-point de la siguiente forma.
character-point ≡ {posiciones intermedias entre el texto PC-
DATA de un documento}
Los node-points, al contrario de los character-points, sı́ están vincula-

dos a la estructura arborescente del documento XML. En XPointer, al
igual que ocurre con los character-point, los node-points aparecen de-
finidos como una tupla formada por un contenedor de referencia y un
número entero no negativo que indica la posición relativa del punto en-
tre los hijos directos de ese nodo. Esta forma de modelización permite
ciertamente mucha flexibilidad a la hora de poder direccionar cualquier
posible punto del documento, pues todo punto tiene asociada, gracias
a esa formalización, al menos una expresión que lo define. No obstan-
te, no todos los puntos tienen la misma robustez de direccionamiento.
En general, resultan más robustamente direccionables aquellos puntos
que aparecen justamente adyacentes al principio o al final de etique-
tas de apertura o de cierre de elementos que cambien poco dentro de
la estructura arbórea del documento. Estas consideraciones permiten
redefinir la modelización de puntos, simplificando la definición original
de XPointer como una tupla formada por un nodo cualquiera y un va-
lor de entre cuatro posibles que indiquen los cuatro puntos tangentes a
las etiquetas de inicio y fin de ese nodo, tal y como aparece definido a
continuación.
158
node-point ≡ (node,
{firstchild|lastchild|prevsibling|nextsibling})
Cualquier nodo con contenido no nulo define ası́ cuatro puntos vinculados
al mismo, que son los puntos adyacentes a sus etiquetas de apertura y de
cierre, y que aparecen reflejados en la tabla 5.25. Sin embargo, cuando el
nodo está formado por una etiqueta vacı́a, el número de puntos se reduce a
dos, pues la misma etiqueta sirve como etiqueta de apertura y de cierre del
nodo. En el caso de que exista una etiqueta de apertura y otra de cierre, pero
el contenido del nodo sea la cadena vacı́a, el número de puntos direccionables
es en realidad de tres, puesto que los dos más internos del mismo, es decir, los
referentes a firstchild y a lastchild hacen referencia en realidad a un mismo
punto. De este modo, menos puntos resultan definibles que en XPointer,
pero los que sı́ lo son resultan más interesantes desde el punto de vista del
programador y además son más robustamente direccionables.
bege(x) point(x,prevsibling) Punto anterior a etiq. inicio

begi(x) point(x,firstchild) Punto posterior a etiq. inicio
endi(x) point(x,lastchild) Punto anterior a etiq. fin
ende(x) point(x,nextsibling) Punto posterior a etiq. fin
Cuadro 5.25: Puntos adyacentes de un nodo x
Ası́ pues, los puntos se definen como la unión de los node-point y los
character-point.
point ≡ node-point ∪ character-point
Tipo range
Los rangos (range) se definen en XPointer como un nuevo tipo de da-

tos que extiende la noción de nodo. Los rangos son fragmentos que están
comprendidos entre dos puntos de un documento, tal y como se menciona
en la descripción de XPointer en el apartado 4.3. Conforme a esa idea, debe
tenerse en cuenta que, en XPointer, se pueden definir rangos que empiecen
a mitad de un párrafo y terminen a la mitad del siguiente, no participando,
por lo tanto, de la estructura arbórea de XML. Ello, pese a que quizás pueda
ser interesante desde el punto de vista de una herramienta de visualización
159
(como las de un drag & drop), sin embargo no está permitido dentro de XTen-
dedPath, donde todo tipo de datos debe estar sujeto a la estructura arbórea
del documento. Para que los rangos puedan ser insertados o borrados de un
documento XML sin alterar las reglas de construcción de árboles, se necesita
que esos rangos sigan el principio de buena formación, tal y como está ex-
presado en la condición de la figura 5.12. En ella se indica que todo rango
delimitado por un par de puntos p1 y p2 debe cumplir que, para cualquier
nodo, el nodo debe estar contenido dentro del rango, o bien el rango debe
estar contenido dentro del nodo, o bien el nodo figura o bien antes o bien
después del rango en el documento sin intersecarlo en ningún punto.
∀ (p1 , p2 ) ∈ range, ∀ n: node (p1 ≤doc bege(n) ∧ ende(n) ≤doc p2 ) ∨ (bege(n)

≤doc p1 ∧ p2 ≤doc ende(n)) ∨ p2 ≤doc bege(n) ∨ ende(n) ≤doc p1
Figura 5.12: Restricción que debe cumplir todo rango en XTendedPath
Los rangos de XTendedPath son aquellos rangos de XPointer que cumplen

la restricción definida en la figura 5.12. De ello se deduce que los puntos
delimitadores del rango, tanto el de inicio como el del final, deben estar
definidos en un mismo contenedor del árbol, para que el rango pueda ser
insertado o borrado manteniendo la estructura arbórea del documento. Es
decir, un documento XML al que se le inserte o borre algún rango debe
seguir siendo un documento XML bien formado. La validez respecto de un
DTD o XML Schema no está garantizada con el uso de estas operaciones.
Otra caracterı́stica importante de los rangos definidos de esta forma es
que son un superconjunto de los nodos, es decir, los nodos son subconjuntos
de los rangos.
string-range ≡ (character-point, character-point)
ranges ≡ nodes ∪ string-ranges
No obstante, debe tenerse claro que, aunque los rangos respeten la estruc-
tura arbórea del documento XML, no forman parte de la misma, y por lo
tanto no son accesibles por los ejes de XPath. Ningún rango se puede conside-
rar hijo o descendiente de ningún nodo de la misma forma en la que tampoco
ningún nodo o rango se puede considerar a su vez hijo o descendiente de
ningún rango dentro del cual esté definido. Las relaciones de descencencia y
parentesco no son aplicables a los rangos por el hecho de que ellos no forman
parte de la estructura arbórea. Debe tenerse en cuenta que en un árbol de
un documento son múltiples los posibles rangos que pueden ser definidos en
cualquier momento (tantos como parejas de puntos ordenados puedan esta-
blecerse de forma que se cumpla la peculiaridad de estar definidos ambos
160
puntos en un contenedor común) y que la construcción de un rango no in-
volucra ninguna operación especial aparte del hecho de anotar los puntos de
inicio y de fin de dicho rango.
Patrones de texto
Los patrones de texto son un tipo especial de constructores de rangos.

La delimitación de los mismos no viene dada ya por la definición explı́cita
de sus puntos de inicio y de fin, tal y como aparece en sus constructores,
sino que tal delimitación viene dada de una manera implı́cita, especificando
una propiedad de coincidencia respecto a un patrón de texto o plantilla. El
rango será aquella parte del documento cuyo contenido de texto se ajuste a
un patrón especificado. Los patrones de texto vienen definidos en XPointer
mediante su constructor string-range() y permiten definir como rangos aque-
llas porciones de documento en las que el texto embebido (el PCDATA) sea
idéntico al argumento del constructor. Es decir, el argumento string recibido
por este constructor como patrón es buscado literalmente en el documento
como un substring, sin la posibilidad de aplicar expresiones regulares que
flexibilicen ese patrón. Ası́ pues, el tipo de búsquedas textuales en XPointer
resultan ser algo limitadas.
XPath 2.0 no proporciona, al menos en sus primeras versiones, funcio-
nes capaces de devolver aquellas partes de los documentos XML donde se
cumpla una concordancia entre el texto del documento y un patrón de texto
usado para hacer búsquedas o reconocimiento de textos basados en expre-
siones regulares. No obstante, tras varios meses de deliberaciones desde el
inicio de la etapa del nuevo borrador, desde su versión del 16 de agosto de
2002 se incluye un nuevo operador que pretende aplicar expresiones regula-
res a los documentos, pero que aún deja algunos aspectos sin definir, como
la sintaxis de esas expresiones. En cualquier caso, sin desatender un posible
cambio en la especificación de XPath 2.0, para ir solventando el problema, se
ha incorporado a XTendedPath un constructor propio de rangos basado en
patrones de texto que utilizan expresiones regulares basadas en Perl5 [147].
Futuras definiciones de la semántica del operador recientemente introducido
en XPath para manejar esta misma funcionalidad replantearán seguramen-
te la existencia de este constructor en XTendedPath. Sin embargo, se le ha
incluido de momento con el fin de poder formular consultas basadas en co-
rrespondencias con patrones de texto mientras tanto, intentando mantener
su interfaz lo más simple posible. La cabecera de la función de patrones de
texto, tal y como está definida en XTendedPath, es la siguiente:
161
STRPAT: string → integer → (range|range*) → range*
Básicamente, la función STRPAT se define como una función currificada
que devuelve una secuencia de rangos en el documento en los que se cumple
que el texto de dichos rangos se ajusta a la expresión regular almacenada
en su primer argumento. El segundo argumento de la función es un núme-
ro entero que indica cuál es la parte de la expresión regular que debe ser
considerada a la hora de devolver los resultados. En Perl5, las expresiones re-
gulares admiten la posibilidad de definir partes posteriormente recuperables
de forma aislada con ese número. Cuando la expresión regular no fragmenta
en zonas o subapartados la entrada, ese número debe ser el valor numérico 0.
Sin embargo, si la expresión regular recibida como primer argumento define
varias posibles zonas de subdivisión, el valor numérico sirve para distinguir
cuál de ellas es la que contiene el dato de interés. En ese caso, el número indi-
ca la posición de esa zona de interés, empezando por el el 1 y siguiendo en el
orden de aparición en la expresión regular. Finalmente, el tercer argumento
de la función recibe el conjunto de rangos del documento sobre el cual se va
a aplicar la expresión regular de búsqueda. La tabla 5.26 contiene ejemplos
de la aplicación de esta función que, aplicada sobre una lista de rangos de un
documento, es capaz de devolver una lista de rangos de texto de un documen-
to en los que se representen dı́as, meses o años, descritos en formato textual,
encontrados en las fechas detectadas por la expresión regular entrecomillada.
Entrada Expresión Significado

“La fecha es 25-Dic-2002” STRPAT(“(\d\d)-(\w*)-(\d*)”)(0) “25-Dic-2002”
“La fecha es 25-Dic-2002” STRPAT(“(\d\d)-(\w*)-(\d*)”)(1) “25”
“La fecha es 25-Dic-2002” STRPAT(“(\d\d)-(\w*)-(\d*)”)(2) “Dic”
“La fecha es 25-Dic-2002” STRPAT(“(\d\d)-(\w*)-(\d*)”)(3) “2002”
Cuadro 5.26: Operador de patrones de texto
Funciones auxiliares
Para mejorar la capacidad de programación y de acceso a determinados

datos asequibles a partir de los documentos, se han incluido además, las
siguientes funciones adicionales que realizan labores auxiliares útiles para el
programador:
162
Cabecera Significado para nodo Significado para rango no nodo
MARKUP: range → string Marcado con todas las etiquetas Marcado con todas las etiquetas
CONTENT: range → string Marcado sin etiquetas delimitadoras MARKUP
ISNODE: range → boolean cierto falso
Cuadro 5.27: Funciones auxiliares
MARKUP La función MARKUP devuelve como resultado un string con

el marcado de un rango en el documento, incluyendo su texto y todas
sus etiquetas de marcado, tanto internas como delimitadoras del nodo,
en el caso de el rango que sea tal. Dicho string puede usarse posterior-
mente para replicar el rango en nuevos documentos o para analizar su
contenido interno como si fuera simple texto plano.
CONTENT La función CONTENT devuelve como resultado un string con

el marcado de un rango en el documento, incluyendo su texto y las eti-
quetas de marcado internas, pero sin incluir las etiquetas delimitadoras
del nodo, en el caso de que el rango sea tal. Dicho string puede usarse
de forma similar al que devuelve la función MARKUP, con la salvedad
de que ya se sabe que no incluye las etiquetas de inicio y de fin para
los nodos.
ISNODE La función ISNODE aplicada a un rango indica si dicho rango

se corresponde con un nodo o no.
En la tabla 5.28 aparecen unos ejemplos de rangos direccionables en un

simple elemento de una página XHTML, de forma que se puede apreciar el
significado resumido de los operadores anteriores. En esa misma tabla, se
muestran algunos rangos de ‘‘<a>Hello Madam, bye</a>".
Operadores jerárquicos
Como consecuencia de la introducción en XTendedPath de nuevos con-

ceptos y tipos de datos provenientes de XPointer que no figuraban en XPath
(los puntos y los rangos), se han incluido además, unos operadores jerárquicos
que figuran en esta sección, para representar relaciones de contenido entre
rangos de un documento. Los operadores jerárquicos suponen una generali-
zación de los ejes de navegación de XPath, para cuando se manipulan rangos
en vez de nodos. Ası́ pues, cuando estos operadores se aplican a nodos, su
163
Rango MARKUP(Rango)
range(point(a, firstchild), point(a, lastchild)) ‘‘Hello Madam, bye"
range(point(a, firstchild), point(b, prevsibling)) ‘‘Hello ‘‘
range(point(a, firstchild), point(b, nextsibling)) ‘‘Hello Madam"
range(point(a, prevsibling), point(a, nextsibling)) ≡ a ‘‘<a>Hello Madam, bye</a>"
range(point(b, firstchild), point(b, lastchild)) ‘‘Madam"
range(point(b, prevsibling), point(a, lastchild)) ‘‘Madam, bye"
range(point(b, prevsibling), point(b, nextsibling)) ≡ b ‘‘Madam"
range(point(b, nextsibling), point(a, lastchild)) ‘‘, bye"
STRPAT(“Hello Madam,”)(0) ‘‘Hello Madam,"
Cuadro 5.28: Algunos ejemplos de rangos
semántica concuerda con la de algún operador XTendedPath previamente

definido de los que contemplaban los ejes de navegación y que aparecen men-
cionados en el apartado 5.4. Sólo cuando alguno de sus operandos no son
nodos, sino rangos, se extiende el significado del eje para dotarle al operador
de un mayor grado de generalidad.
INSIDE: (range*, range*) → range*

El operador INSIDE recibe un par de secuencias de rangos y devuelve
como resultado la secuencia formada por rangos del primer argumento
que cumplen la condición de estar definidos dentro de algún rango
contenido en el segundo argumento. Cuando el primer y el segundo
argumento están formados exclusivamente por nodos, el operador IN-
SIDE tiene la misma semántica que la función D de XTendedPath. La
tabla 5.29 refleja la semántica de INSIDE, dependiendo de los tipos de
sus argumentos.
Condición Valor
a ∈ node* ∧ b ∈ node* D(a)(b) = F(A(b))(a)
a∈
/ node* ∨ b ∈
/ node* {x ∈ a | ∃ y ∈ b ∧ x 6= y ∧ bege(y) ≤doc bege(x) ∧ ende(x) ≤doc ende(y)}
Cuadro 5.29: Semántica de la expresión INSIDE(a,b)
La tabla 5.30 muestra dos ejemplos de uso de la función INSIDE pa-

ra calcular una secuencia de rangos de texto formados por aquellas
164
palabras que estén en itálica y en negrita a la vez (independientemen-
te del orden de anidamiento de estas dos etiquetas) dentro del rango
almacenado en la variable P.
Expresión
INSIDE(STRPAT(“\w+”)(0)(P),U(D(“b”)(D(“i”)(P)), D(“i”)(D(“b”)(P))))
I(INSIDE(STRPAT(“\w+”)(0)(P), D(“b”)(P)),INSIDE(STRPAT(“\w+”)(0)(P), D(“i”)(P)))
Cuadro 5.30: Ejemplos de uso del operador jerárquico INSIDE
CONTAIN: (range*, range*) → range*

El operador CONTAIN recibe un par de secuencias de rangos y de-
vuelve como resultado la secuencia formada por rangos del primer ar-
gumento que cumplen la condición de contener algún rango pertene-
ciente al segundo argumento. Cuando el primer y el segundo argumento
están formados exclusivamente por nodos, el operador CONTAIN tie-
ne la misma semántica que la función A de XTendedPath. La tabla
5.31 refleja la semántica de CONTAIN, dependiendo de los tipos de
sus argumentos.
Condición Valor
a ∈ node* ∧ b ∈ node* A(a)(b) = F(D(b))(a)
a∈
/ node* ∨ b ∈
/ node* {x ∈ a | ∃ y ∈ b ∧ x 6= y ∧ bege(x) ≤doc bege(y) ∧ ende(y) ≤doc ende(x)}
Cuadro 5.31: Semántica de la expresión CONTAIN(a,b)
Gracias a los operadores jerárquicos, la fórmula de la figura 5.12 puede

reescribirse conforme a la de la figura 5.13.
∀ r = {(p1 , p2 ): range}, ∀ n: node r ⊆ INSIDE(r,n) ∨ r ⊆ CONTAIN(r,b) ∨

p2 ≤doc bege(n) ∨ ende(n) ≤doc p1
Figura 5.13: Restricción de rangos reescrita con operadores jerárquicos
165
5.5.2. Orden superior
Las extensiones de este apartado permiten usar XTendedPath como len-
guaje de programación funcional. Básicamente, ello se consigue definiendo
constructores de expresiones lambda y una biblioteca de rutinas de orden
superior.
Constructor FUN: (expresiones lambda)
El constructor FUN sirve para definir expresiones lambda [90]. Las expre-
siones lambda son un elemento muy importante dentro de la programación
funcional que permite la definición de expresiones que, aplicadas a unos argu-
mentos, devuelven unos resultados. Las expresiones lambda se pueden usar
como funciones anónimas a las que, opcionalmente, se les puede dar nombre,
que es como normalmente se usan en los lenguajes de programación conven-
cionales. Las expresiones lambda forman sin duda una de las extensiones más
importantes de XTendedPath. Para ello, se puede usar el constructor FUN
que figura a continuación:
FUN: (a,b) → (a → b) / FUN(a,b) ≡ λa.b
Por ejemplo, FUN(x,2*x) define una función que devuelve el doble de su
argumento.
Constructor LET: (definiciones locales)
El constructor LET permite definir localmente una variable con el valor

de una expresión dentro de otra.
LET(variable,value,expr) ≡ (λvariable.expr)(value)
Por ejemplo, LET(doble,FUN(x,2*x),doble(3)) calcula el doble del núme-
ro 3, asignando a la función que calcula el doble de su argumento el nombre
doble, de tal forma que luego es aplicada al valor 3.
Biblioteca de funciones de orden superior
Con el constructor FUN de XTendedPath, se pueden definir expresiones

lambda, algo que no está contemplado en XPath, y de una forma sencilla.
En el lenguaje XTendedPath las expresiones lambda son consideradas como
un tipo de datos de primer orden, lo cual indica que se pueden pasar como
166
argumentos a otras funciones, ser devueltas como resultados, lo cual da lu-
gar a que se les pueda aplicar funciones de orden superior. En XTendedPath
están predefinidas las funciones de orden superior que aparecen en la tabla
5.32. Dichas funciones se encuentran disponibles en la biblioteca del lengua-
je. El usuario puede incluir fácilmente más funciones definiendo sus propias
bibliotecas si lo desea.
Expresión Cabecera Significado

MAP(f)(z) MAP: (a → b) → a* → b* {f(x) | x ∈ z} (en = orden)
RED(f)(z)(y) RED: (a → b → b) → b → a* → b foldr f z y ∗
ACC(f)(z)(y) ACC: (a → b → b) → b → a* → b foldl f z y ∗
ZIP(f)(z)(y) ZIP: (a → b → c) → a* → b* → c* zip f z y ∗
REVERSE(z) REVERSE: a* → a* reverse z ∗
ID(x) ID: a → a x
FIRST(z) FIRST: a* → a Primer elemento
TAIL(z) TAIL: a* → a* z − FIRST(z) (quitando el primero)
LAST(z) LAST: a* → a Último elemento
INIT(z) INIT: a* → a* z − LAST(z) (quitando el último)
APPLY(f)(z) APPLY: (a → b) → a → b f(z)
FLIP(f)(z)(y) FLIP: (a → b → c) → b → a → c f(y)(z)
O(f)(g) O: (b → c) → (a → b) → (a → c) λz.f(g(z))
Cuadro 5.32: Funciones de orden superior de XTendedPath
Las expresiones marcadas con ∗ están escritas con la sintaxis del lenguaje
de programación funcional Haskell [113]. La gran mayorı́a de esas funciones
son ya habitualmente conocidas en numerosos lenguajes de programación
funcional. RED es la función reduce, también conocida como foldr. ACC
es la función accumulate o foldl. O es la composición de funciones, muy útil
para definir predicados. La función O sirve para componer funciones sencillas
en otras más complejas. El resultado es una nueva función que, cuando sea
evaluada sobre su argumento, pasará como argumento de la primera función
el resultado de evaluar la segunda función sobre el argumento recibido. Estas
funciones se encuentran definidas en XTendedPath en la figura 5.14.
Aunque existe la posibilidad de añadir un número mucho mayor de fun-
ciones de orden superior a XTendedPath, el conjunto anterior ofrece ya de
por sı́ una gran flexibilidad en el manejo de datos, suficiente, para poder ha-
cer muchos tipos de procesamientos diversos sobre los contenidos extraı́bles
167
LET(MAP,FUN((f),FUN((lista),
IF EMPTY(lista) THEN
(lista)
ELSE
(U (f(FIRST(lista))) (MAP(f)(REST(lista))))
END
) ) );
LET(RED,FUN((f),FUN((base),FUN((lista),
(base)
ELSE
(f (RED (f) (base) (REST(lista))) (FIRST(lista)))
END
) ) ) );
LET(ACC,FUN((f),FUN((base),FUN((lista),
(base)
ELSE
(ACC (f) (f (base) (FIRST(lista))) (REST(lista)))
END
) ) ) );
LET(ZIP,FUN((f),FUN((a),FUN((b),
IF EMPTY(a) THEN
(a)
ELSIF EMPTY(b) THEN
(b)
ELSE
(U (f(FIRST(a))(FIRST(b))) (ZIP(f)(REST(a))(REST(b))))
END
) ) ) );
LET(O,FUN((f),FUN((g),FUN((x),
(f(g(x)))
) ) ) );
LET(FLIP,FUN((f),FUN((y),FUN((x),
(f(x)(y))
) ) ) );
Figura 5.14: Algunas funciones de orden superior definidas en XTendedPath
168
del Web. La tabla 5.33 expresa las equivalencias entre algunas expresiones
XPath y sus correspondientes expresiones XTendedPath. En ellas se asume
que P0 es una variable que contiene una página o un rango de la misma y
que L0 es una secuencia de varios elementos.
XPath XTendedPath
$P0//a D(“a”)(P0)
$L0[2] F(2)(L0)
$L0[last()] F(“last”)(L0)
$L0[@alt] F(AT(“alt”))(L0)
$L0[not(@alt)] F(NOTF(AT(“alt”)))(L0)
$L0[child::b] F(C(“b”))(L0)
$L0[b/c] F(O(C(“c”))(C(“b”)))(L0)
$L0[b/c/@d] F(O(AT(“d”))(O(C(“c”))(C(“b”))))(L0)
$L0//a[b/c/@d] F(FUN((x),AT(“d”)(C(“c”)(C(“b”)(x)))))(L0)
$L0/ancestor:* A(“*”)(L0)
$L0//a[1]/following-sibling::a/@href AT(“href”)(FS(“a”)(F(1)(L0)))
$L0//a[@alt = “Correo”] F(O(EQ(“Correo”))(AT(“alt”)))(L0)
$L0//a[text() = “Correo”] F(O(EQ(“Correo”))(TEXT))(L0)
$L0[text() = “Mail” and position() < 3] F(FUN((x),TEXT(x)=”Mail” AND POS(x)<3))(L0)
$P0//input[@name=”userid”][1] F(1)(F(O(EQ(“userid”))(AT(“name”)))(D(“input”)(P0)))
Cuadro 5.33: Ejemplos de expresiones XPath y sus equivalentes en XTended-

Path
Para la implementación interna de estas funciones, la opción emprendida

en este trabajo ha sido la de programarlas en el mismo lenguaje de programa-
ción generado por el traductor de XTendedPath, usando para ello bibliotecas
enlazables con ese código. Aunque otros lenguajes son posibles, dentro de
este trabajo, el traductor que se proporciona traduce las expresiones XTen-
dedPath a lenguaje WebL [80], y es en bibliotecas de ese lenguaje en donde
están predefinidas la mayorı́a de las funciones de orden superior usables des-
de XTendedPath. Si el traductor convirtiera las expresiones XTendedPath a
otro lenguaje, como, por ejemplo, Java, para que los programas Java genera-
dos pudieran ser compilados y enlazados en prototipos ejecutables, deberı́a
usarse una biblioteca que implementara estas funciones en ese lenguaje.
Por ejemplo, si para reescribir una expresión lambda se deseara generar
código C, habrı́a que programar una función con un nombre auxiliar y usar
169
su nombre, pues en C las funciones no son nunca anónimas, aunque sı́ se pue-
den pasar por argumento. En el caso de que se deseara generar código Java,
el hecho de que en ese lenguaje no existe la posibilidad de definir funciones
anónimas podrı́a solventarse de otra forma. Por ejemplo, podrı́a aprovechar-
se la peculiaridad que permite definir objetos anónimos con métodos con
nombres conocidos. El código Java de la figura 5.15 permite la aplicación
al número 4, de una función que devuelve el doble de su argumento. Esta
función no es una función anónima, pero sı́ un método con nombre conocido
(exec) definido dentro de un objeto anónimo.
public class Lambda {
interface Func {
public int exec(int x);
}
public static void foo(Func f) {

System.out.println(f.exec(4));
}
public static void main(String[] args) {

foo(new Func()
{
public int exec(int x) {
return x * 2;
}
});
}
}
Figura 5.15: Ejemplo de expresión lambda definida en Java
5.5.3. Modificación de documentos

Para la modificación de los documentos, XTendedPath tiene cuatro opera-
dores básicos, dos de ellos para la manipulación de atributos y otros dos para
la manipulación de la estructura arbórea de nodos. En todos los casos, los
operadores tienen como efecto colateral la modificación de la representación
interna del documento.
En el caso de los atributos, el operador SETATTR permite modificar
el valor de un atributo en un conjunto de nodos dentro de un documento.
Por otro lado, el operador DELATTR permite eliminar un atributo de un
conjunto de nodos.
En el caso de la modificación de la estructura arbórea, el operador IN-
170
SERTRANGE permite insertar un nuevo rango en un punto concreto de
un documento. El operador DELETERANGES elimina del documento los
rangos recibidos. La tabla 5.34 refleja un resumen de estos operadores.
Cabecera Significado
SETATTR: string → string → node* → page Modificación del valor de atributos
DELATTR: string → node* → page Eliminación de atributos
INSERTRANGE: point → range → page Inserta un rango en el documento
DELETERANGES: range* → page Eliminación de rangos del documento
Cuadro 5.34: Operadores básicos de modificación de documentos
La modificación de atributos dentro de un documento puede ser muy útil

para rellenar formularios. Por ejemplo, sea campotexto una variable que con-
tiene un campo de formulario de tipo texto cuyo valor se deba rellenar. Sea
botonessi una secuencia de campos de formulario de tipo checkbox que de-
ben ser marcados y botonesno los que no deben ser marcados. Sea opcionessi
las opciones de una selección que deben ser seleccionadas y opcionesno las
opciones de una selección que no deben ser seleccionadas. La figura 5.16 con-
tiene expresiones XTendedPath que rellenan adecuadamente esos campos de
formulario, modificando las opciones de rellenado por defecto del formulario.
SETATTR("value")("Java")(campotexto);
SETATTR("checked")("checked")(botonessi);
DELATTR("checked")(botonesno);
SETATTR("selected")("selected")(opcionessi)
DELATTR("selected")(opcionesno);
Figura 5.16: Ejemplo de expresiones de rellenado de formulario
Máscaras
En ocasiones interesa extraer datos de versiones modificadas de los do-

cumentos. Es habitual que esas modificaciones consistan en la eliminación
de ciertas partes, consideradas como molestas para la extracción de datos,
de forma que, una vez eliminadas, la extracción de datos resulta mucho más
sencilla. Una solución que puede emplearse puede consistir en modificar el
documento original eliminando esas partes y ası́ después poder hacer ese
171
cálculo o extracción. Sin embargo, posteriores cálculos pueden necesitar reci-
bir el documento original sin modificaciones, es decir, sin los efectos laterales
de los operadores de modificación de la tabla 5.34.
Una opción clara para este tipo de operaciones puede ser entonces la de
manipular sólo una copia del documento, de forma que sobre ella se hacen
las modificaciones y los cómputos, manteniendo intacta una versión original
del documento. Haciéndose copias temporales de esos documentos, el progra-
mador podrá manipularlas y modificarlas a su gusto, teniendo ası́ una visión
libremente modificable de un documento en la que poder hacer libremente
sus cómputos. Posteriormente, el documento modificado podrá ser eliminado.
Para realizar todas estas operaciones fácilmente en una sola lı́nea sin que el
programador tenga que estar dando nombres a las variables que almacenan
esas copias del documento temporalmente modificadas para hacer cómputos,
se ha ideado el operador de máscara.
El operador de máscara permite al usuario construir nuevas partes de un
documento donde, sin modificar el documento de entrada, se generan nuevos
fragmentos de documento en los que se proporciona una visión en la que
los rangos recibidos en el primer argumento son invisibilizados en los ran-
gos que son recibidos en el segundo argumento. Estas enmascaraciones se
realizan eliminando esos fragmentos sobre las copias de los fragmentos de
los documentos, no sobre el documento original. El resultado de la función
de máscara es un conjunto de fragmentos de documento que son copia de
los recibidos en el segundo argumento donde se han enmascarado los frag-
mentos recibidos en el primer argumento, siendo el documento obtenido un
documento distinto del original. Esta operación podrı́a estar implementada
internamente con hojas de estilo XSLT que generaran un documento nuevo
eliminando la parte que se desea enmascarar. Sin embargo, su implemen-
tación está hecha internamente aprovechando los trozos de documento que
resultan de la eliminación de un nodo para construir directamente con ellos
el nuevo documento en memoria y con estructura de árbol sin necesidad de
tener un motor XSLT.
MASK: range* → range* → range*
La tabla 5.35 define ejemplos de uso de la función de máscara.
Un ejemplo de la capacidad de expresión de XTendedPath comparado

con otras alternativas estándares como las que aparecen en las figuras 3.4 y
3.6 es el que aparece en la figura 5.17.
172
Expresión Significado
MASK(STRPAT(“bomba”)(0)(P))(P) Eliminación de las palabras “bomba” de P
TEXT(MASK(D(“i”)(P))(P)) Texto de P eliminando sus itálicas
COUNT(STRPAT(“\w+”)(0)(MASK(D(“del”)(P))(P))) Número de palabras de la actual versión de P (ver [119])
MASK(F(AT(“onchange”))(D(“select”)(f)))(f) Formulario sin sus select de navegación JavaScript
SUM(STRPAT(“\d+”)(0)(MASK(D(“th”)(T))(T))) Suma de los elementos de una tabla T sin sus cabeceras
Cuadro 5.35: Ejemplos de uso de la función MASK
F(O(EQ(name))(O(TEXT)(C("addresse"))))(D("address")(source))
Figura 5.17: Expresión XPath equivalente a

source//address[addressee[text() =name]]
173
174
Capı́tulo 6
XPlore: Lenguaje para la

navegación y procesamiento de
datos en el Web
Para automatizar tareas en el Web, en esta tesis se han tenido en men-

te unos objetivos similares a los que persigue el lenguaje expect, comen-
tado en el apartado 3.2.1. En ambos casos se pretende automatizar tareas
que manejan aplicaciones interactivas preexistentes, si bien los tipos de esas
aplicaciones interactivas son bien distintos en cada trabajo. Mientras que
con expect, como aplicación interactiva se contempla cualquier programa no
gráfico controlable desde teclado y lanzable desde un intérprete de coman-
dos en sistemas operativos Unix, con el Web, como aplicación interactiva se
contempla cualquier aplicación ubicada en algún servidor Web accesible por
medio de formularios embebidos en páginas tı́picamente HTML. Estas apli-
caciones de servidor Web pueden ser consideradas como intérpretes de cada
una de las peticiones que se les puede enviar a través de esos formularios. En
el primero de los casos, expect está encargado de sustituir al usuario que usa
el teclado para interactuar con la aplicación. En el segundo, un programa de
navegación automatizada debe emular al usuario que usa un interfaz interac-
tivo (el browser) para interactuar con una aplicación que ejecuta alojada en
un servidor Web. En ambos casos, el de la automatización de tareas gestio-
nando programas con expect y el de la automatización de tareas gestionando
aplicaciones localizadas en el Web, se propone el uso de un lenguaje capaz de
representar adecuadamente esos diálogos, especificando adecuadamen-
te las pautas de navegación que deben seguirse para llevar a cabo una tarea.
En el caso del Web, el lenguaje propuesto para ese propósito es XPlore, cuya
175
descripción se lleva a cabo en este capı́tulo.
Analizando los lenguajes actualmente existentes para el desarrollo de apli-
caciones capaces de navegar automáticamente en el Web, mencionados en el
capı́tulo 3, ninguno de ellos resulta completamente adecuado para la automa-
tización de aplicaciones Web. Muchas de las bibliotecas desarrolladas para ser
manejadas por lenguajes de programación habituales y algunas soluciones ad
hoc de la literatura para la automatización de la navegación Web, permiten
especificar fácilmente sencillas pautas de navegación, básicamente visitando
páginas de direcciones conocidas de antemano. Muy pocas de ellas permiten
la especificación de caminos de navegación complejos, donde se deben seguir
varios enlaces y en los que se debe hacer referencia con algún patrón de ac-
ceso a enlaces extraı́dos de los documentos recientemente visitados. Todo lo
más, suelen ofrecer sencillas llamadas a las primitivas GET y POST, pero
no proporcionan al usuario los mecanismos de extracción de datos necesarios
para parametrizar convenientemente esas primitivas en caminos de navega-
ción compleja en los que es necesario establecer una sesión con los servidores
Web accedidos. Por otro lado, las soluciones existentes no tienen un nivel de
abstracción lo suficientemente elevado capaz de abstraer en pocas lı́neas de
código operaciones comunes de la navegación o el procesamiento, lo cual da
lugar a grandes programas difı́ciles de mantener.
En muchos casos, no existe un conjunto adecuado de tipos de datos sobre
los que estructurar los datos obtenidos del Web u homogeneizarlos si pro-
vienen de diversas fuentes, que es un paso primordial, según se describe en
el apartado 2.2.1. En la mayorı́a de los casos, el procesamiento de los datos
que se describe en el apartado 2.2.6 no se contempla como una labor propia
de ninguna herramienta debido al particular funcionamiento de cada posi-
ble tarea, requiriendo que el usuario programe esos procesamientos en rutinas
definibles por él. Ello obliga a separar la estructura de estos programas en dis-
tintas partes, una enfocada a la navegación y otra al procesamiento de
los datos obtenidos de esa navegación. Ello es, sin duda, una opción loable,
pues permite mantener fácilmente disociadas partes del programa que son
disjuntas para el programador. Sin embargo, para pequeños procesamientos
muy sencillos y muy habituales, esta separación, tı́picamente realizada en
ficheros dispersos, resta mucha claridad a los programas, por lo que serı́a
deseable que algunos procesamientos sencillos fueran especificables desde el
propio lenguaje de navegación. Por otro lado, muchas de las soluciones que
sı́ presentan un alto nivel de abstracción medianamente adecuado, proporcio-
nan graves deficiencias que las impiden ser utilizadas en tareas que permitan
el uso en cualquier aplicación del Web. La automatización de estas tareas de-
be poder estar fácilmente representada en el nivel de abstracción adecuado,
176
en un formato de representación capacitado para especificar adecuadamente
diálogos fáciles de entender entre aplicaciones, capaz de representar a su vez
tareas complejas y además ir acompañada de una plataforma capaz de dar
soporte a la ejecución de esos programas.
Entre esas capacidades de abstracción, se requiere poder representar fácil-
mente el diálogo formado por las peticiones y respuestas que se deben desa-
rrollar con las aplicaciones de Web cuyo uso se desea automatizar, pero a la
vez integrando ese diálogo con el manejo de otros recursos, como el manejo
del sistema de ficheros e interacción con el usuario, el uso de temporizado-
res y gestión de hilos concurrentes para manejar varias comunicaciones en
paralelo, ası́ como operaciones de control de flujo habituales en lenguajes de
programación imperativos (bucles, condiciones, variables, llamadas a funcio-
nes, ...). Básicamente, se requiere la completa funcionalidad de un lenguaje
de programación con las siguientes caracterı́sticas:
Capacidad de representación de sesiones en el Web con alto nivel de

abstracción. Ello implica la capacidad de poder especificar fácilmente el
seguimiento de enlaces y envı́o de formularios rellenos de forma sencilla.
Manejo de tipos de datos habituales de los lenguajes de programa-

ción, para estructurar los datos de la forma más adecuada y poderlos
procesar fácilmente.
Buen soporte a la ejecución sobre las páginas del Web legado.
Y, preferentemente, para distinguirlo aún más si cabe de las alternativas

existentes en la literatura, basado en estándares reconocidos como
adecuados para facilitar su utilización.
Existen muchos estándares para realizar diseños y especificaciones con

buen nivel de abstracción, pero prácticamente ninguno de ellos ha sido usado
en el ámbito de la automatización de tareas en el Web, al menos desde el
punto de vista de la creación de clientes. Uno de los estándares más adecua-
dos para estas representaciones han sido los MSC, según lo visto y justificado
en el apartado 4.1, por su facilidad para representar diálogos entre compo-
nentes que se comunican entre sı́ intercambiando mensajes. Sin embargo,
para el dominio del Web, no se conocen plataformas que den ejecución a este
tipo de representaciones de diálogos automatizadas. Por otro lado, además
de representar diálogos, es necesario representar la extracción de datos de
documentos y para ello se ha escogido a XPath, por su clara orientación a
ser el lenguaje de direccionamiento para documentos XML. Ambos lenguajes
177
ofrecen la ventaja de ser completamente complementarios el uno respecto del
otro y de ofrecer conjuntamente una solución apropiada de las necesidades
que se desean automatizar. De hecho, una primera aproximación de ambas
tecnologı́as fue usarlas de forma conjunta tal y como habı́an sido cada una
de ellas habı́a sido concebida, embebiendo expresiones XPath en las acciones
definibles dentro de los MSC. Sin embargo, algunas pequeñas singularida-
des de esa unión ofrecı́an algunas cuestiones que requerı́an ciertas mejoras.
Mejoras que además podı́an simplificar notablemente el nivel de abstracción
teniendo en cuenta el uso que se pretendı́a dar a esta solución, que es la
automatización de tareas en el Web. Por esa razón nació XPlore.
XPlore es un lenguaje de programación de alto nivel de abstracción para la
creación de programas de navegación automática (asistentes de navegación,
programas envoltorio, ...), es decir, de algoritmos de navegación, que sirve
además como anfitrión a XTendedPath, una extensión del lenguaje XPath
que aparece detallada en el apartado 5.3. XPlore es concebido como una
adaptación restringida con reglas de la representación textual de los
MSC enfocada al contexto de la programación de aplicaciones de navegación
automatizada, donde, por otro lado. XPlore hereda, por tanto, sus princi-
pales caracterı́sticas de la representación textual de los MSC, utilizando el
subconjunto de elementos más representativos de este formalismo. XPlore es
un lenguaje imperativo que permite construcciones tı́picas de los lenguajes
de esa naturaleza, como secuencialización de sentencias, bucles, sentencias
condicionales, uso de variables y funciones. Además, al tener incorporado
XTendedPath como un subconjunto del lenguaje, también ofrece los cons-
tructores de programación funcional que ya incluye XTendedPath, por lo
que pueden usarse expresiones lambda para la definición de funciones, ası́ co-
mo la posibilidad de usar y/o definir funciones de orden superior, tanto por
parte del usuario como las contenidas en una biblioteca que se le proporcio-
na. A su vez, XPlore puede ser traducido a un lenguaje de programación que
será posteriormente compilado o ejecutado.
XPlore surge como una particularización de la representación textual de
los MSC dentro del campo de la creación de aplicaciones de navegación au-
tomática. Sin embargo, los MSC en sı́ mismos constituyen una representa-
ción muy genérica, aplicable a muy diversos entornos. Es por ello que cuando
se usan en un entorno como el Web en el que son conocidas una serie de
restricciones o condicionantes, éstos deben también tener cabida en la repre-
sentación. En este nuevo lenguaje se han introducido algunos requisitos a los
MSC. Todo MSC que cumpla estos requisitos es un programa XPlore, mien-
tras que todo programa XPlore es, a su vez, un MSC. Principalmente se ha
respetado la sintaxis inicial, pero se le han añadido una serie de restricciones
178
semánticas, con el objetivo de evitar que determinadas construcciones, sien-
do sintácticamente correctas desde el punto de vista de los MSC, pueden ser
semánticamente inadmisibles, esto es, erróneas, desde el punto de vista de un
algoritmo de navegación Web. De esta manera, se reducen aspectos como la
ambigüedad o la posibilidad de especificar sistemas incoherentes, imposibles,
no deseados o no traducibles a lenguajes de programación, sin que la pérdida
de flexibilidad provocada por esas restricciones afecte a la esencia principal
del lenguaje de expresión de algoritmos ni tampoco a la expresividad del mis-
mo. Dicho de otra forma, el propio comportamiento del Web, algo distinto del
de la comunicación de señales en componentes de telecomunicaciones de bajo
nivel (que es el ámbito para el cual los MSC fueron inicialmente aplicados),
obliga a que algunas construcciones de los MSC se vean indisolublemente
unidas las unas a las otras (por ejemplo, que toda petición en el lado del
cliente sea seguida temporalmente por su correspondiente respuesta). Ello
provoca que existan construcciones de una granularidad un poco mayor a
la que permiten de por sı́ los constructores de los MSC. De esta forma se
consigue además compactar aún más los programas de navegación, lo cual es
deseable conforme a los objetivos planteados por esta tesis.
Ası́ pues, desde un punto de vista técnico, existen dos notaciones del len-
guaje XPlore. Por un lado, la notación MSC es una representación textual
basada en la sintaxis de los MSC en la que se garantiza su legibilidad y mani-
pulabilidad por personas y herramientas familiarizadas con este formalismo.
En esta notación, debe tenerse el cuidado de seguir una serie de restricciones
de escritura para evitar la especificación de sistemas absurdos o no desea-
bles. Por otro lado, existe una notación compacta que es en la que están
basados algunos de los operadores de este capı́tulo y que es la que se traduce
a lenguaje de programación para generar los prototipos ejecutables. Ambas
notaciones son semánticamente equivalentes y sus diferencias son meramente
sintácticas y están convenientemente explicadas a lo largo de este capı́tu-
lo. Los ejemplos del capı́tulo 7 figuran en esas dos notaciones. No obstante,
gracias a un traductor incorporable en una herramienta CASE, es esperable
que en un próximo futuro programas escritos en una notación MSC pueden
ser automáticamente traducibles a una notación compacta, por lo que no
será necesario el manejo de la notación compacta.
Al contrario de lo que ocurre con la mayorı́a de los lenguajes diseñados
en los trabajos relacionados, XPlore no dispone de una plataforma que le
dé directamente soporte de ejecución, es decir, no es directamente interpre-
table por ninguna aplicación. Esto es, no existe ningún programa capaz de
analizar un algoritmo de navegación escrito en XPlore y ejecutar una a una
sus sentencias interactuando ası́ con servidores Web. La labor de interpretar
179
programas en XPlore es factible, pero requerirı́a una gran cantidad de fun-
cionalidad en el intérprete. En su lugar, XPlore viene acompañado por un
traductor que transforma los programas escritos en XPlore (notación com-
pacta) en programas de lenguajes de programación preexistentes. Esta labor
resulta mucho más sencilla que la de la interpretación y no resta funcionalidad
a los programas escritos en XPlore.
La utilización de MSC para modelar el comportamiento de aplicaciones
en el Web no es novedosa de este trabajo. Los MSC han estado vinculados
a SDL [75], y por lo tanto su ámbito de uso ha estado bastante restringido
al desarrollo de sistemas mediante la utilización de métodos formales, tı́pi-
camente en el desarrollo de software para sistemas de control en equipos de
telecomunicaciones. Existen precedentes del uso de MSC para el modelado y
especificación de aplicaciones orientadas al Web [27]. No obstante, se trata de
aplicaciones centradas en el modelado de aplicaciones Web desde el punto de
vista de los servidores Web. En este caso, uno de los componentes del sistema
es el servidor Web cuyo comportamiento se desea especificar, mientras que el
resto de los componentes del sistema son clientes Web que interactúan con
el servidor, principalmente porque la aplicación ası́ modelada está orientada
a la comunicación y colaboración de varios usuarios mediante el uso de un
portal con el fin de conseguir en la colaboración de todos un objetivo común.
En la comunicación entre los componentes, los mensajes intercambiados por
la aplicación y los clientes están llevados a cabo mediante el envı́o de correos
electrónicos y el acceso de páginas Web y rellenado de formularios.
Son varios los motivos por los que se ha seleccionado el formalismo de
los MSC para este trabajo. Más allá de su simplicidad, de su comprensibili-
dad por personas sin conocimientos técnicos especiales, de disponer de una
semántica formal, o de una representación textual, o de sus posibilidades para
ser transformados en distintos formalismos de especificación o de implemen-
tación, lo cierto es que los MSC resultan ser una tecnologı́a muy adecuada
para representar las comunicaciones en el Web [44], tanto desde el punto de
vista de especificación y desarrollo de aplicaciones para los servidores como
para las de los clientes, tal y como aparece documentado en el apartado 4.1.
A continuación se describen los componentes del lenguaje XPlore.
180
6.1. Componentes de XPlore orientados a la
navegación
6.1.1. Transacciones HTTP
Las transacciones del protocolo HTTP se pueden modelizar fácilmente en

un MSC. Basta representar un mensaje de petición HTTP desde el cliente
hasta el servidor y otro de respuesta del servidor al cliente. Desde el punto de
vista del servidor, entre la recepción de la petición y el envı́o de la respuesta
del servidor al cliente deben ejecutarse todas aquellas acciones necesarias
para procesar la petición con el fin de devolver la página de respuesta. Ello
puede conllevar la ejecución de programas externos como CGI [89] o servlets
[69] o puede ser tan simple como devolver el contenido de un fichero existente
en el sistema de ficheros del servidor.
Sin embargo, desde el punto de vista del cliente, una transacción HTTP es
contemplada como una petición de respuesta sı́ncrona, por lo que la ejecución
del cliente debe quedar paralizada hasta que se reciba la correspondiente
respuesta del servidor. El tiempo desde que se tramita una petición HTTP
hasta que se recibe su respuesta es bastante significativo y depende de muchos
factores externos (velocidad y calidad de conexión, sobrecarga en el servidor,
...), razón por la cual el hilo debe quedar entretanto bloqueado. Un cliente que
desee aprovechar ese tiempo para efectuar otras acciones, debe optar por la
utilización de varios hilos de ejecución, de manera que puedan ser ejecutados
mientras el hilo que lanzó su petición está esperando su respuesta. Para ello
puede usarse el operador de concurrencia mencionado en el apartado 6.2.9,
creando ası́ hilos de ejecución capaz de realizar concurrentemente mientras
los hilos ocupados en realizar transacciones HTTP están bloqueados.
Para modelizar una transacción HTTP desde el punto de vista del cliente,
el lenguaje XPlore define las operaciones GET, HEAD y POST, cada una
de ellas asociable a los comandos HTTP del mismo nombre. Estos coman-
dos suelen encontrarse habitualmente implementados en bibliotecas propias
[112, 147] de lenguajes de programación como Java o Perl. Sin embargo, no
suelen controlar ciertos aspectos avanzados de las cabeceras HTTP, como
las cookies y las cabeceras de identificación HTTP, restringiéndose mı́nima-
mente al control de las cabeceras cuya presencia es siempre obligatoria y
con un valor por defecto difı́cilmente configurable. Por el contrario, cualquier
cabecera HTTP, tanto las definidas actualmente, como cualquier otra nueva
cabecera que pueda requerirse en un futuro, gracias a las cuales suele definir-
se el concepto de sesión en los servidores Web, sı́ están controladas por estas
181
primitivas en el lenguaje XPlore, pues están implementadas internamente en
la biblioteca de soporte del lenguaje. Otras muchas acciones implı́citas men-
cionadas en el apartado 2.1 son también igualmente consideradas en estas
bibliotecas de soporte.
El comando GET recibe como primer argumento la URL de la página que
debe traerse. El comando POST recibe como primer argumento el formulario
rellenado que debe enviarse. Ambos comandos pueden opcionalmente recibir
un segundo argumento que ayude a configurar las opciones de bajo nivel
mencionadas en el párrafo anterior, y devuelven como resultado la página
que ha sido enviada por el servidor como respuesta.
GET: (url:string,options:string) → page:node
POST: (form:node,options:string) → page:node
La figura 6.1 representa una transacción POST en XPlore y sus corres-
pondientes representaciones equivalentes gráfica y textual en notación MSC.
El comando GET es similar. Como puede verse, la notación XPlore compacta
(formada por la expresión respuesta = POST(form);) es más simple y menos
sujeta a posibles errores de escritura que la correspondiente notación textual
del MSC.
Figura 6.1: Representación de transacción HTTP
6.1.2. Combinadores de servicios

El acceso a los datos en el Web es más propenso a fallos que el acceso a
datos en la memoria local de un ordenador. Cualquier sobrecarga en los ser-
vidores o cualquier pérdida de conectividad puede fácilmente impedir que las
transacciones HTTP funcionen adecuadamente como debieran, evitando que
las invocaciones de las llamadas GET y POST devuelvan la página deseada.
182
Para evitar estos fallos de ejecución y ası́ conseguir que las aplicaciones que
automatizan tareas en el Web sean lo más robustas posible, es convenien-
te usar mecanismos que detecten cuándo una transacción HTTP falla por
pérdida de conectividad de forma que se puedan tomar las medidas oportu-
nas, como por ejemplo, programar reintentos, acceder a una URL alternativa
capaz de acceder a las páginas deseadas por otra ruta, o limitar en el tiempo
la ejecución de la transacción con un temporizador para parar aquellas tran-
sacciones que están tardando demasiado en ser respondidas. Luca Cardelli,
propone en [40] el uso de unos operadores denominados Service Combinators
con el fin de, fácilmente, con unos pocos y simples constructores fácilmente
combinables entre sı́, solucionar estos problemas de una forma elegante para
el programador. A continuación se detallan los Combinadores de servicios
contemplados en XPlore.
Ejecución temporizada: TIMEOUT(t,exp)
Si la expresión exp tarda en evaluarse menos de t milisegundos, todo ha

ido correcto y ése es el resultado que se devuelve. Si se cumple ese plazo sin
que la evaluación de la expresión haya podido ser completada, se suspende
la evaluación y se produce una excepción. En la figura 6.2, se almacena en
la variable P1 la página de la portada del buscador Google [9], estableciendo
un tiempo máximo de 100000 milisegundos para ello. En el caso en el que se
tarde más de ese tiempo, se produce una excepción.
P1 = TIMEOUT(100000,GET("http://www.google.com", nil));
Figura 6.2: Ejemplo de ejecución temporizada
Ejecución reiterada: RETRY(exp)
Se evalúa la expresión exp tantas veces como sea necesario hasta que no
produzca ninguna excepción. La figura 6.3 muestra el reintento continuado de
peticiones a la página principal de Google, con un lı́mite para cada petición
de 100 segundos. Si se sobrepasa ese lı́mite, se reintenta (indefinidamente)
una nueva petición. Cuando se consigue esa página, se guarda en la variable
P1.
183
P1 = RETRY(TIMEOUT(100000,GET("http://www.google.com", nil)));
Figura 6.3: Ejemplo de ejecución reiterada
Ejecución secuencial: SEQ(a,b)
Primeramente, se evalúa la expresión a. Si no produce excepción y de-

vuelve un resultado correcto, ése debe ser el resultado de la expresión. Si
produce excepción, se abandona su evaluación y se evalúa la expresión b. El
resultado de la ejecución secuencial será de excepción, sólo si ambas expre-
siones producen excepción. En caso contrario, el resultado es el de la primera
expresión que no produzca excepción. La figura 6.4 muestra el intento de
guardar en P1 la página principal de Hotmail [13]. En el caso en el que esa
petición no se consiga llevar a cabo, se intentará con la de Yahoo! [22]. Sólo
si ambas páginas fallan, se devuelve como excepción la de la última de las
expresiones.
P1 = SEQ(GET("http://www.hotmail.com", nil), GET("http://www.yahoo.com", nil));
Figura 6.4: Ejemplo de ejecución secuencial
Ejecución concurrente: PAR(a,b)
Primeramente, se evalúan las expresiones a y b concurrentemente. Cuan-

do la primera de ellas en terminar acaba satisfactoriamente, se suspende la
evaluación de la otra expresión y se retorna el resultado calculado por la
expresión que sı́ terminó. Cuando la primera de ellas en terminar acaba in-
satisfactoriamente, el resultado es delegado al de la otra expresión que sigue
su curso. Si ambas terminan insatisfactoriamente, trasciende la excepción de
la segunda expresión en terminar. El resultado de la ejecución concurrente
será de excepción sólo si ambas expresiones producen excepción. En caso con-
trario, el resultado es el de la primera expresión que termine correctamente
y que no produzca excepción. La figura 6.5 muestra el intento de guardar en
P1 la primera página principal que consiga completar su descarga de los ser-
vidores de Hotmail y del de Yahoo! Sólo si ambas páginas fallan, se devuelve
como excepción la de la última de las expresiones.
A modo de ejemplo, la expresión de la figura 6.6 almacena en P1 la
184
P1 = PAR(GET("http://www.hotmail.com", nil), GET("http://www.yahoo.com", nil));
Figura 6.5: Ejemplo de ejecución concurrente
portada del buscador Google mediante reintentos sucesivos mientras falle,

esperando un tiempo de 20 segundos entre intentos consecutivos.
P1 = RETRY(SEQ(GET("http://www.google.com", nil), SLEEP(20000)));
Figura 6.6: Ejemplo de combinación de servicios
6.2. Componentes de XPlore orientados al

procesamiento
6.2.1. Procesos
Un proceso es una entidad en ejecución automatizada que interactúa con
otras entidades, locales o remotas por intercambio de peticiones y respuestas,
tı́picamente transacciones HTTP. Las entidades que intervienen en una tarea
Web (servidores, portales agregadores, usuarios con un browser, ...) se corres-
ponden con las instancias de los MSC mencionadas en el apartado 4.1.1. Sin
embargo, desde el punto de vista orientado a la automatización de XPlore,
se consideran procesos XPlore sólo a aquellos que deben tener un comporta-
miento automatizado y aún no lo están. Ni los usuarios, ni las instancias ya
automatizadas son procesos desde el punto de vista del lenguaje XPlore. Un
servidor Web o un usuario que sea irreemplazable detrás de un browser, pese
a que también pueden ser representados en un MSC por entidades, no son
considerados por XPlore más que entidades externas con las que el proceso
XPlore debe interactuar de alguna forma.
Los procesos pueden ser clasificados a su vez entre pesados o ligeros, con-
forme a las funcionalidades de la plataforma de ejecución. Esto tı́picamente
se traduce en que los procesos pueden ser programas completos o hilos de
ejecución (threads) de un mismo proceso. Normalmente, un programa XPlo-
re se traduce en un proceso pesado que puede a su vez lanzar varios hilos de
ejecución.
185
6.2.2. Sentencias de control de flujo
Como cualquier lenguaje de programación imperativa, XPlore contempla

la definición de sentencias condicionales y de bucles. Para ello, XPlore define
una construcción IF-THEN-ELSIF-ELSE-END para sentencias condicionales
(donde las ramas alternativas a la primera condición, es decir los ELSIF y
el ELSE son opcionales).
IF condicion THEN acciones
(ELSIF condicion THEN acciones)*
(ELSE acciones)?
END
En cuanto a los bucles, XPlore define dos tipos de ellos. Por una parte, el
bucle WHILE-DO-END (que termina cuando se deja de cumplir una condi-
ción de guarda) y el bucle FOREACH-IN-DO-END (que sirve para recorrer
los elementos de una secuencia de datos).
WHILE condicion DO acciones END
FOREACH variable IN secuencia DO acciones END
En todos los casos, las sentencias condicionales y de bucles están a su vez
basadas en las expresiones inline de los MSC (ver tabla 4.1). Al igual que ese
tipo de expresiones, estas sentencias de programación estructurada pueden
anidarse entre sı́. Como puede apreciarse en la figura 6.7, la representación
en la notación compacta de XPlore tiene algunas diferencias respecto de la
representación MSC de XPlore. Destaca el uso de palabras clave especı́fi-
cas similares a las de un lenguaje de programación imperativo convencional
(ELSE, ELSIF, IN, DO ...), en lugar de usar como separadores de las partes de
estas sentencias la opción definida en la gramática textual de los MSC, con-
sistente en el nombre del tipo de expresión inline seguida de punto y coma.
De esta forma, los programas escritos en XPlore compacto quedan menos
verbosos y con menos propensión a albergar fallos.
En la figura 6.8 puede verse el código XPlore en notación compacta del
que aparece en notación MSC en la figura 6.7.
Entre las sentencias condicionales y de bucle definidas en el lenguaje
XPlore y las sentencias inline definidas en los MSC no existe una correspon-
dencia biunı́voca tal y como puede comprobarse en la tabla 6.1. Por ejemplo,
en los MSC sólo existe una sentencia inline (llamada loop) para cualquier tipo
de bucle, deba éste ser terminado por una condición booleana (tipo WHILE)
o por el recorrido de los elementos de una secuencia (tipo FOREACH). La
sentencia inline opt es completamente redefinible como una sentencia alt en
186
Figura 6.7: Representación de un bucle y una sentencia condicional anidados
en XPlore notación MSC
A();
FOREACH i IN TOSEQ(2,4,7) DO
B();
IF i mod 2 THEN
B();
ELSE
C();
END;
END;
Figura 6.8: Ejemplo de sentencias anidadas en notación compacta de XPlore
187
la que no existen ramas alternativas a la primera condición. La sentencia
inline par está contemplada en XPlore por el operador de concurrencia del
apartado 6.2.9. En cuanto a la sentencia inline de tratamiento de excepciones
exc puede ser tratada con los combinadores de servicios del apartado 6.1.2.
Expresión inline Sentencia XPlore

alt IF-THEN-ELSIF-ELSE
loop FOREACH, WHILE
opt IF sin ramas ELSE
par Asociado a BEGINCONCURRENT
exc Error
Cuadro 6.1: Relación de expresiones inline con sentencias de control de flujo
6.2.3. Entrada/salida
Con XPlore se tiene acceso a las primitivas más habituales para leer o
escribir, tanto de fichero, como de teclado y pantalla. En la tabla 6.2 se
muestran algunas de esas primitivas.
Primitiva Acción
PRINTLN Escribir en stdout
READLN Leer una lı́nea de stdin
ERRORLN Escribir en stderr
FILEREADLN Leer una lı́nea de fichero
SAVETOFILE Escribir al principio de fichero sobreescribiendo
APPENDTOFILE Escribir al final de fichero
LIST Listar un directorio
MKDIR Crear directorio
DELETEFILE Borrar Fichero
Cuadro 6.2: Primitivas de entrada/salida
188
6.2.4. Estado de ejecución
XPlore define dos primitivas para cambiar el estado de ejecución del hilo
actual desde en ejecución a suspendido. La descripción de ambas aparece en
la tabla 6.3.
Primitiva Acción
SLEEP(n) Suspender la ejecución n milisegundos
STALL() Suspender la ejecución indefinidamente
Cuadro 6.3: Primitivas de cambio de estado de ejecución
6.2.5. Errores en la ejecución

XPlore define dos primitivas para interrumpir la ejecución del programa,
tal y como puede apreciarse en la tabla 6.4. STOP interrumpe la ejecución
de forma incondicionada, permitiendo que el proceso muera (con una lla-
mada exit al sistema operativo). ASSERT puede usarse para interrumpir la
ejecución si no se cumplen ciertos requisitos necesarios según el programador.
Primitiva Acción
STOP(valor) Terminar la ejecución del programa con un valor de retorno
ASSERT(expresión) Terminar la ejecución del programa si la expresión es falsa
Cuadro 6.4: Primitivas de errores de ejecución
6.2.6. Funciones
Al igual que en prácticamente cualquier lenguaje de programación, un
conjunto de sentencias XPlore puede encapsularse en una función para poder
ser reutilizado posteriormente mediante llamadas a esa función. Mediante
el uso de funciones, los programas escritos en lenguajes imperativos pueden
modularizarse y simplificar de manera notable su mantenimiento. En la figura
6.9 las funciones A, B y C son ejecutadas por un único proceso (el proceso
Cliente o el proceso Servidor, según corresponda), mientras que Identif es
189
otra función igualmente, salvo por el hecho de que tiene una representación
someramente distinta ya que está involucrada en la ejecución de más de un
proceso (el Cliente y el Servidor).
Figura 6.9: Representación de llamadas a funciones en XPlore notación MSC
Desde el punto de vista de los MSC a ambos casos se les considera como
una descomposición modular (ver apartado 4.1.9) que debe ser detallada
en otro MSC. Siguiendo la sintaxis que XTendedPath pone a disposición de
XPlore, la figura 6.10 contiene la definición de la función Identif en XPlore.
En ella se declara a Identif como una función que recibe dos argumentos (una
URL y una función de rellenado de formularios), de forma que esa función
sirve luego para rellenar el formulario de búsqueda para buscar la palabra
Java, por ejemplo en Google.
Por su lado, el código XPlore en notación compacta de la instancia Cliente
de la figura 6.9 aparece en la figura 6.11.
6.2.7. Llamada a clases Java externas

Gracias a que los programas XPlore son traducidos a lenguaje WebL y
que éste proporciona un soporte para invocar clases Java enlazadas con el
190
LET(Identif,
FUN((url,Rellenar),
LET(P1, GET(url, nil),
Rellenar(D("form")(P1));
LET(P2, POST(D("form")(P1), P2, nil))
)
),
Identif("http://www.google.com",
FUN((form), SETATTR("value")("Java")(D("input")(form))) );
);
Figura 6.10: Ejemplo de definición de función Identif en XPlore notación

compacta
A();
Identif();
B();
Figura 6.11: Ejemplo de llamada de función en XPlore
programa traducido, XPlore incorpora dos nuevos constructores que permiten

la llamada a funciones de usuario que, pudiendo no estar escritas en XPlore,
sin embargo sı́ pueden estar escritas en lenguaje Java. Gracias a la conversión
automática entre tipos de datos Java y tipos de datos WebL, los métodos
y constructores de las clases Java pueden ser llamados con total facilidad.
Estas funciones aparecen detalladas a continuación. Nótese que devuelven
un nuevo tipo de datos, (un java object), lo cual es sólo posible cuando el
lenguaje al que se transforma XPlore es WebL o Java.
JAVA NEW: (classname:string, ...) → java object
JAVA CLASS: (classname:string) → java object
A su vez, los métodos de los objetos Java devueltos por los anteriores
constructores pueden ser invocados fácilmente, de la misma forma en la que
lo serı́an en lenguaje Java. La figura 6.12 muestra un ejemplo. Nótese que
toString() y getMonth() son métodos de la clase java.util.Date del lenguaje
Java.
191
D = JAVA_NEW("java.util.Date");
PRINTLN("Today’s date is ", D.toString());
PRINTLN("Today is ", D.getMonth());
Figura 6.12: Ejemplo de llamada a clases Java desde XPlore notación com-
pacta
6.2.8. Llamada a programas externos

Las funciones escritas en las bibliotecas, tanto de usuario como de sistema,
disponibles en lenguaje XPlore o en lenguaje Java, no son la única forma de
reutilizar software que permite el lenguaje XPlore. Las aplicaciones escritas
en XPlore pueden invocar a programas externos accesibles desde el intérprete
de comandos del sistema operativo, aprovechando ası́ al máximo los recursos
disponibles de su entorno de ejecución. Para ello, XPlore define la primitiva
CALL de la siguiente manera:
CALL: string → string
respuesta = CALL(“dir”);
En la figura 6.13 se representa la llamada a un programa externo repre-
sentado en el argumento comando. En la variable respuesta se almacenan
los resultados de la ejecución que dicho comando ha volcado en su salida
estándar, almacenado en la forma de string.
Figura 6.13: Representación de llamada a programa externo
6.2.9. Operador de concurrencia

Obtener varios hilos de ejecución concurrente también es fácil en XPlo-
re. Dado que las transacciones HTTP o las llamadas a programas externos
192
pueden demorarse un tiempo significativo hasta que son completadas, puede
resultar deseable para el programador simultanear esas esperas con la eje-
cución de otras tareas, para lo cual puede querer crear hilos de ejecución
concurrentes. Para ello se ha definido un sencillo operador de concurrencia,
que permite crear varios hilos de ejecución con el fin de repartir entre ellos la
carga de un conjunto de subtareas. Cada hilo evoluciona concurrentemente
respecto de los demás, de forma que el proceso que los creó queda esperan-
do la terminación de todos los hilos lanzados. El operador de concurrencia
se define de la siguiente manera, donde entre los operadores BEGINCON-
CURRENT y ENDCONCURRENT, se especifica una lista de expresiones
(tı́picamente llamadas a funciones), cada una de ellas encargada a un hilo de
ejecución y separadas por la palabra clave CONC. El constructor funciona
de forma similar a un cobegin/coend tı́pico de programación concurrente.
BEGINCONCURRENT tarea1 CONC tarea2 CONC ... tarean
ENDCONCURRENT
BEGINCONCURRENT fun1() CONC fun2() ENDCONCURRENT

Para representar un operador de concurrencia en un MSC, se define, en
el lado del programa que ejecuta ese operador, una corregión (ver apartado
4.1), para indicar que el orden de los eventos que van a ejecutarse en esa
instancia no es determinable a priori, sino que depende de la evolución de
la ejecución de cada uno de los hilos creados. Una vez que el proceso padre
crea sus hijos, se queda bloqueado a la espera de que todos ellos terminen
su correspondiente subtarea. Sólo cuando el último de estos hilos muere, el
padre se desbloquea de su estado de espera y continúa su ejecución, sabiendo
que las tareas de los hijos lanzados han concluido. Dentro de la corregión, se
representan los correspondientes comandos create para cada hilo, seguidos
por el correspondiente número de llamadas wait para esperar por la ter-
minación de cada uno de los hilos creados. Ninguna otra acción se permite
ejecutar dentro de la corregión del programa principal que crea a los hilos.
Cada hilo creado, puede, sin embargo, crear a su vez más hilos de ejecución
mediante su propia corregión. En la figura 6.14 se representa un operador de
concurrencia con dos hilos de ejecución que ejecutan las subtareas fun1() y
fun2().
193
Figura 6.14: Representación de operador de concurrencia
194
Capı́tulo 7
Ejemplos desarrollados con los

lenguajes propuestos
En este capı́tulo se presentan tres ejemplos de aplicaciones desarrolladas

con las tecnologı́as presentadas en esta tesis. Los tres ejemplos plantean la
resolución de problemas comunes habitualmente planteados en el Web para
los que XTendedPath y XPlore consiguen una automatización completa de
forma sencilla y compacta. Los ejemplos que se presentan en este capı́tulo
son variados e intentan hacer uso del acceso a servidores Web conocidos
por mucha gente, presentándose con diversas representaciones en un orden
creciente de detalle.
El primero de ellos, accede a las páginas del Nasdaq [14] y extrae en for-
mato XML las cotizaciones (con quince minutos de retraso respecto al tiempo
real) de unas acciones que cotizan en ese mercado. Con esas cotizaciones, el
programa calcula el valor de una cartera de acciones definida por el usuario
formada por esos tı́tulos. Como ejemplo de programa de integración de da-
tos en el Web de varias fuentes heterogéneas, el mismo programa se conecta
además al Web del Banco Central Europeo [7] para extraer, de una página
HTML, la cotización del dólar estadounidense (USD) respecto del Euro, y
calcula en euros el valor de la cartera de acciones denominadas en dólares.
El segundo de ellos, accede a las páginas de Aucland [1], un servidor
de subastas online y se dedica a publicar el catálogo de una tienda, alma-
cenado en un fichero de usuario, rellenando con cada uno de sus artı́culos
un complejo formulario de publicación de nuevas subastas en el servidor. El
programa comprueba, antes de seguir cada enlace, que el servidor respon-
de adecuadamente con los mensajes esperados de bienvenida, indicación de
saldo y confirmación de puesta en marcha de la subasta. Se trata de un pro-
195
grama muy útil para publicar un catálogo de muchos artı́culos. El programa
se encuentra totalmente adaptado a la estructura del formulario de envı́o en
HTML, especificando todos los aspectos necesarios para la publicación de los
artı́culos, como precio, cantidad, foto, opciones de pago, formas de envı́o y
todo aquello que el servidor solicite al usuario. Todas las páginas accedidas
están en formato HTML, y algunos comportamientos JavaScript han sido
imitados desde el programa.
El tercero de ellos, accede a las páginas del correo gratuito de Yahoo! [22]
y extrae un listado de los mensajes que hay en la bandeja de entrada para
un determinado usuario que se identifique con un password. Dicho progra-
ma, además, permite el borrado de aquellos mensajes que el usuario declare
como spam, marcando en el formulario de correo de Yahoo! esos mensajes
y pulsando después en el correspondiente botón de borrado del formulario.
El programa es capaz de seguir todos los enlaces necesarios para acceder a
los contenidos que le interesan, incluyendo además las paginaciones de los
resultados que Yahoo! muestra a sus usuarios. También en este ejemplo se
accede a páginas HTML de un servidor Web legado y se han implementado
algunos comportamientos JavaScript.
A continuación se muestran en detalle estos programas:
7.1. Valoración de una cartera de acciones del

Nasdaq en euros
El ı́ndice Nasdaq [14] es el principal ı́ndice bursátil de valores tecnológi-

cos en todo el mundo. En él, inversores de todo el mundo compran y venden
acciones de empresas que forman parte de la cartera de muchos inverso-
res particulares, empresas y fondos de inversión. Su servidor Web ofrece un
servicio gratuito que indica la cotización en dólares USD de las empresas
que componen el ı́ndice con un retraso de unos quince minutos. El servi-
cio está disponible para ser accedido en formato HTML por browsers, pero
también es accesible en formato XML para cualquier programa en general.
Un mismo documento XML devuelto por este servidor bajo petición puede
contener las cotizaciones de varias acciones. La tabla 7.1 refleja una parte de
la estructura lógica de uno de estos documentos XML.
196
Nombre empresa Red Hat, Inc. Sun Microsystems, Inc. eBay Inc.
Techo (USD) 5.61 3.47 78.43
Suelo (USD) 5.3 3.31 76.35
Último (USD) 5.5 3.41 78.35
Variación 0.18 % 0.29 % 2.03 %
Previo (USD) 5.49 3.4 76.79
Dirección sede 1801 Varsity Drive 901 San Antonio Road 2005 Hamilton Avenue
Ciudad Raleigh NC 27606 Palo Alto CA 94303-4900 San Jose CA 95125
Web http://www.redhat.com http://www.sun.com http://www.ebay.com
Cuadro 7.1: Estructura del documento XML con las cotizaciones del Nasdaq
Por otro lado, el Banco Central Europeo [7] ofrece diariamente la cotiza-
ción en euros de las principales divisas mundiales. Al igual que el servidor
del Nasdaq, el Banco Central Europeo es capaz de proporcionar esos datos
en múltiples formatos (HTML, WML, PDF, CSV, ...) ası́ como en su propio
lenguaje definido sobre XML. Para demostrar la capacidad de integración de
datos heterogéneos, para este caso se ha escogido la representación HTML.
La figura 7.1 contiene una representación de esa página tal y como la presenta
un navegador.
Figura 7.1: Cambio de divisas del BCE
El problema que se plantea consiste en realizar un programa que auto-

matice la valoración de una cartera de cuatro acciones del ı́ndice Nasdaq,
de forma que el valor de la cartera sea finalmente calculado en euros con-
forme a la cotización indicada por el Banco Central Europeo. La cartera de
acciones está compuesta por 200 acciones de la compañı́a Flowers.com [8],
197
100 acciones de la compañı́a Red Hat [17], 300 acciones de la compañı́a Sun
Microsystems [19] y 500 acciones de la compañı́a eBay [6]. El programa debe
conectarse al servidor del Nasdaq y formular su petición para obtener las
cotizaciones de esas empresas en un único documento XML, que tiene una
estructura similar a la de la tabla 7.1. Concurrentemente, debe obtenerse
del Banco Central Europeo la cotización del dólar USD en euros, la cual
viene embebida en otro documento, como el de la figura 7.1. Cuando am-
bos documentos han sido finalmente extraı́dos de la red, debe extraerse de
ellos la información necesaria. Del documento XML del Nasdaq se extraerán
las cotizaciones de las empresas, que vienen denominadas en dólares USD.
Del documento del Banco Central Europeo, una página HTML con formato
de tabla en el que cada celda expresa la cotización en euros de una divi-
sa diferente, se extraerá exclusivamente un número (la cotización del dólar
USD). El programa finalmente calculará el valor de la cartera de acciones
multiplicando el precio de cada acción por el número de acciones que forman
la cartera y sumando los resultados de esos productos. Esa suma expresa
el valor de la cartera en dólares USD. Dividiendo ese valor por el factor de
conversión a euros, se obtendrá el resultado buscado. La figura 7.2 refleja el
MSC que explica el algoritmo. Nótese que las peticiones a los servidores Web
se hace lanzando threads concurrentes para minimizar el tiempo de respuesta
del programa, paralelizando las peticiones a los servidores accedidos.
Figura 7.2: MSC gráfico del programa Nasdaq
En la figura 7.3 aparece el correspondiente programa XPlore en notación

MSC. Nótese que ambas son equivalentes tal y como está definido en el
estándar [76] y que la conversión entre una y otra es automatizable.
198
msc Nasdaq;
inst nasdaq;
inst client;
inst ecb;
instance client;
action shares=(200,100,300,500);
concurrent
create thread1;
create thread2;
wait thread1;
wait thread2;
endconcurrent;
action quotes=$P1//equity-node//last-sale-prices
action prod=zip (*) $shares $quotes
action sum=xf:sum($prod)
action usdpereuro=$P2//td[text()="USD"]/following-sibling::td[2]
action PRINTLN("Shares in EUR: " + ($sum/$usdpereuro))
endinstance;
thread1: instance thread1;

out GET quotes to nasdaq;
in P1 from nasdaq;
endinstance;
thread2: instance thread2;
out GET rates to ecb;
in P2 from ecb;
endinstance;
endmsc;
Figura 7.3: Programa Nasdaq en XPlore notación MSC
199
Finalmente, la figura 7.4 contiene el código XPlore en notación compac-
ta. En él se define una variable shares con la secuencia que indica el número
de acciones de cada tı́tulo. Más adelante, se utiliza el operador BEGIN-
CONCURRENT ... ENDCONCURRENT para lanzar las peticiones a ambos
servidores Web de forma concurrente. La página XML del Nasdaq es alma-
cenada en P1 y la página HTML es almacenada en P2. De P1 se extraen las
cuatro cotizaciones, obtenibles mediante la expresión XPath $P1//equity-
node//last-sale-prices, que proporciona una secuencia de cuatro nodos del
documento. De P2 se extrae la cotización del dólar USD en euros, obtenible
con la expresión XPath $P2//td[text() = “USD”]/following-sibling::td[2]. El
resultado consiste en calcular el producto escalar entre el número de accio-
nes shares y la cotización de cada acción (los valores de texto de quotes) y
dividirlo todo por la cotización del dólar USD en euros.
VAR(shares);
shares = [ 200, 100, 300, 500]; /* Number of shares */
LET(dirsave, "/tmp/" + ARGS[0] + "/",

VAR(P1); VAR(P2); VAR(quotes); VAR(usdpereuro); VAR(prod); VAR(sum);
MKDIR(dirsave);
/* P1 and P2 can be concurrently retrieved */

BEGINCONCURRENT
GET(P1,
"http://quotes.nasdaq.com/quote.dll?page=xml&mode=stock&symbol=FLWS&symbol=RHAT&symbol=SUNW&symbol=EBAY"
,nil)
CONC
GET(P2,"http://www.ecb.int/stats/eurofxref/eurofxref-xml.html",nil)
ENDCONCURRENT;
/* quotes = $P1//equity-node//last-sale-prices */
quotes = D("last-sale-price")(D("equity-quote")(P1));
/* prod = [ 200 * FLWS’s price, 100 * RHAT’s price, 300 * SUNW’s price, 500 * EBAY’s price ] */
prod = ZIP(MUL)(shares)(quotes);
sum = XFSUM(prod);
PRINTLN("USD: " + ToString(sum));
/* usdpereuro = $P2//td[text() = "USD"]/following-sibling::td[2] */

usdpereuro = F(2)(FS("td")(F(O(EQ("USD"))(TEXT))(D("td")(P2))));
/* If P2 is XML, then usdpereuro = $P2//cube[@currency="USD"]/@rate */
PRINTLN("EUR: " + ToString(sum/XFNUMBER(TEXT(usdpereuro))));

)
Figura 7.4: Programa Nasdaq en XPlore notación compacta
200
7.2. Publicación de un catálogo de artı́culos
en un Web de subastas
Numerosos sitios Web [1, 22, 6, 11, 18] se han dedicado en los últimos
tiempos a ofrecer subastas online. En ellos es posible realizar múltiples ac-
ciones relacionadas con el comercio electrónico entre usuarios. Entre esas
acciones se encuentran las de pujar por artı́culos, realizar votaciones entre
usuarios o publicar artı́culos para lanzar nuevas subastas. Aunque cada vez
existe un mayor número de herramientas disponibles para publicar grandes
conjuntos de artı́culos, lo cierto es que suelen estar reservadas a un conjunto
privilegiado de usuarios y suelen requerir determinadas configuraciones hard-
ware y software que no siempre son disponibles, por lo que la manera que
muchos usuarios tienen para publicar artı́culos es la de rellenar uno a uno
una serie de formularios online en varios pasos.
El problema que se plantea es el de la automatización de la publicación
de un catálogo de artı́culos en el servidor de subastas de Aucland [1]. El
programa deberá acceder al servidor Web de Aucland identificándose con un
usuario y password previamente registrados en ese servidor, de forma que
se rellenarán los formularios de publicación con cada uno de los artı́culos
que aparecen en catálogo almacenado en un fichero de usuario. Ese catálogo
se encuentra en un fichero de usuario que contiene un artı́culo por cada
lı́nea y que está estructurado por columnas separadas por el carácter de
punto y coma ’;’. Las columnas del fichero se corresponden con varios de los
campos del formulario que debe ser rellenado. Para cada artı́culo del catálogo
deberá rellenarse el formulario y deberán seguirse los enlaces necesarios, de
forma que, uno tras otro, el catálogo completo sea finalmente publicado. La
figura 7.5 refleja el MSC que explica el algoritmo.
En la figura 7.6 aparece el correspondiente programa XPlore en notación
MSC. Ambas son equivalentes y su conversión de uno a otro formato es
automatizable.
Finalmente, la figura 7.8 contiene el correspondiente código XPlore en
notación compacta. En él puede verse cómo las variables P1, P2, P3, P4, P5
y P6 se corresponden con cada una de las páginas que forman la secuencia
de publicación, siendo P1 la portada y P6 la página que confirma que la
subasta ha sido puesta en marcha. Para seguir los enlaces que llevan a la
siguiente página, se aplican expresiones XTendedPath (comentadas con su
correspondiente expresión XPath equivalente) que extraen de la página actual
la URL que indica donde está la siguiente página. Los formularios son también
extraı́dos y rellenados con sus correspondientes expresiones XTendedPath.
201
Figura 7.5: MSC gráfico del programa Aucland
202
msc Aucland;
inst aucland;
inst client;
instance client;
out GET "http://www.aucland.es/" to aucland;

in P1 from aucland;
action a1=$P1//a[match("Vender", text())][1];
out GET $a1/@href to aucland;

in P2 from aucland;
action form2=$P2//form[@name="FormVerif"];
action $form2//input[@name="txtID"]/@value=$login;
action $form2//input[@name="txtPwd"]/@value=$passwd;
out POST $form2 to aucland;

in P3 from aucland;
out GET "http://myaucland.aucland.es/form/AddObj.asp" to aucland;

in P4 from aucland;
action ASSERT(match("Bienvenido", $P4/text()));

action form=$P4//form[@name="AucForm1"];
action $R = FILEOPEN($file);
action L = $R.readLine();
while begin;
condition $L != nil;
while;
decomposed Fill($form);
out POST $form to aucland;
in P5 from aucland;
action ASSERT($balance, $P5/text());
action L = $R.readLine();
action SLEEP(8000);
while end;
endinstance;
endmsc;
msc Fill;
instance client;
action $form//input[@name="field"]/@value=value;
...
endinstance;
endmsc;
Figura 7.6: Programa Aucland en XPlore notación MSC
203
El programa comienza almacenando en P1 la portada de Aucland y en
P2 la página de identificación de usuarios. Rellenado y enviado el correspon-
diente formulario de identificación, en P3 se almacena la página HTML que
contiene el panel de control del usuario una vez conectado. Siguiendo unos
pocos enlaces más, se accede al formulario de publicación de nuevas subas-
tas, del que aparece una parte en la figura 7.7 tal y como se visualiza en un
browser. Dicha página se almacena en P5 y es reutilizada de ahı́ en adelante
para publicar todos los artı́culos del catálogo.
Figura 7.7: Campos del formulario de publicación de Aucland
Obtenido P5 y su correspondiente formulario se procesa un bucle que lee

lı́nea a lı́nea el fichero del catálogo del usuario. Con los datos estructurados
en columnas de cada una de esas lı́neas el programa rellena el formulario de
publicación, comprueba que el saldo de la cuenta es correcto, sigue el enlace
para confirmar que desea publicar la subasta y comprueba el mensaje de que
la subasta ha sido publicada. Con el fin de mantener una polı́tica respetuosa
de uso con el servidor y de no sobrecargarlo con peticiones, se establece
un periodo de tiempo de ocho segundos entre un artı́culo y el siguiente. El
programa se encuentra representado por las figuras 7.8, 7.9 y 7.10. La figura
7.8 contiene el código de la función que obtiene el formulario de publicación
y la función para insertar una foto en el formulario. La figura 7.9 contiene
la función que se dedica a rellenar con expresiones XTendedPath todos y
cada uno de los campos del formulario de publicación y del que aparece
representada una parte en la figura 7.7. Finalmente, la figura 7.10 contiene
el código del programa principal.
204
LET(conecta,FUN((login,passwd),
VAR(P1); VAR(P2); VAR(P3); VAR(P4); VAR(P5);

VAR(a1); VAR(form2);
GET(P1,"http://www.aucland.es/",nil);
/* a1 = $P1//a[match("Vender", text())][1] */
a1 = F(1)(F(O(XFSTRMATCH("Vender"))(TEXT))(D("a")(P1)));
GET(P2,AT("href")(a1),P1.URL);
/* form2 = $P2//form[@name="FormVerif"] */
form2 = F(O(EQ("FormVerif"))(AT("name")))(D("form")(P2));
/* $form2//input[@name="txtID"]/@value=$login */
SETATTR("value")(login)(F(O(EQ("txtID"))(AT("name")))(D("input")(form2)));
/* $form2//input[@name="txtPwd"]/@value=$passwd */
SETATTR("value")(passwd)(F(O(EQ("txtPwd"))(AT("name")))(D("input")(form2)));
POST(P3,form2,P2.URL);
GET(P4,"http://myaucland.aucland.es/form/AddObj.asp",P3.URL);
ASSERT(XFSTRMATCH("Bienvenido " + login)(TEXT(P4)));
GET(P5,"http://myaucland.aucland.es/form/AddObj.asp?IDC=2634",P4.URL);
RETURN P5
),
LET(rellenafoto,FUN((form, im, dirpic),

VAR(i);
/* i = $form//input[@name="txtImg"] */
i = F(O(EQ("txtImg"))(AT("name")))(D("input")(form));
IF SEQ(XFSTRINDEXOF("jpg", im) >= 0, XFFALSE()) THEN
SETATTR("value")(im)(i);
ELSE
SETATTR("value")("")(i);
END;
SETATTR("mime")("image/jpeg")(i);
SETATTR("directory")(dirpic)(i);
),
Figura 7.8: Programa Aucland en XPlore notación compacta
205
LET(rellena,FUN((login, form, L, categ, dirpic),
/* Destroy JavaScript based elements $form//select[@name = "txtCatg3" or @name = "txtCatg4"] */
SEQ(DELETENODES(F(O(EQ("txtCatg3"))(AT("name")))(D("select")(form))), nil);
SEQ(DELETENODES(F(O(EQ("txtCatg4"))(AT("name")))(D("select")(form))), nil);
/* $form//select[@name = "txtCatg2"]/@value =$categ ; for category */

SETATTR("value")(categ)(F(O(EQ("txtCatg2"))(AT("name")))(D("select")(form)));
/* $form//input[@name = "txtBDesc"]/@value =xf:strsearch(L, "[^;]+", 0) ; for description */

SETATTR("value")(XFSTRSEARCH(L,"[^;]+",0))(F(O(EQ("txtBDesc"))(AT("name")))(D("input")(form)));
/* $form//textarea[@name = "txtDescC"]/@value =xf:strsearch(L, "[^;]+", 1) ; for detailed description */

SETATTR("value")(XFSTRSEARCH(L,"[^;]+",1))(F(O(EQ("txtDescC"))(AT("name")))(D("textarea")(form)));
/* $form//input[@name = "txtPrixD"]/@value =xf:strsearch(L, "[^;]+", 2) ; for initial price */

SETATTR("value")(XFSTRSEARCH(L,"[^;]+",2))(F(O(EQ("txtPrixD"))(AT("name")))(D("input")(form)));
/* $form//input[@name = "txtQt"]/@value =xf:strsearch(L, "[^;]+", 4) ; for quantity */

SETATTR("value")(XFSTRSEARCH(L,"[^;]+",4))(F(O(EQ("txtQt"))(AT("name")))(D("input")(form)));
/* $form//select[@name = "txtDuree"]/@value = 14 days ; for duration */

SETATTR("value")(ToString(14*1440))(F(O(EQ("txtDuree"))(AT("name")))(D("select")(form)));
/* $form//select[@name = "txtCity"]/@value = "Madrid" ; for city */

SETATTR("value")("10070151")(F(O(EQ("txtCity"))(AT("name")))(D("select")(form)));
/* $form//input[@name = "WinningAuction"]/@checked = "checked" ; for auto-selling */

SETATTR("checked")("checked")(F(O(EQ("WinningAuction"))(AT("name")))(D("input")(form)));
/* $form//input[@name = "OptTrans1"]/@checked = "checked" ; buyer pays shipping */

SETATTR("checked")("checked")(F(O(EQ("OptTrans1"))(AT("name")))(D("input")(form)));
/* $form//input[@name = "OptCHB"]/@checked = "checked" ; Postal Reimbursement */

SETATTR("checked")("checked")(F(O(EQ("OptCHB"))(AT("name")))(D("input")(form)));
/* $form//input[@name = "OptCR"]/@checked = "checked" ; Cash */

SETATTR("checked")("checked")(F(O(EQ("OptCR"))(AT("name")))(D("input")(form)));
/* $form//input[@name = "OptCHP"]/@checked = "" ; No cheques */

SETATTR("checked")("")(F(O(EQ("OptCHP"))(AT("name")))(D("input")(form)));
rellenafoto(form, SEQ(XFSTRSEARCH(L,"[^;]+",11), ""), dirpic); //Imagen

),
Figura 7.9: Programa Aucland en XPlore notación compacta (2)
206
LET(publica,FUN((login, password, categ, file, balance, dirpic),
VAR(P5); VAR(P6); VAR(P7); VAR(form); VAR(R);

VAR(L); VAR(npublished); VAR(a2);
MKDIR(dirsave);
P5 = conecta(login, password);
/* form = $P5//form[@name = "AucForm1"] */

form = F(O(EQ("AucForm1"))(AT("name")))(D("form")(P5));
npublished=0;
R = FILEOPEN(file);
L = R.readLine();
L = R.readLine();
WHILE L != nil AND L != " " DO
PRINTLN(L);
npublished = npublished + 1;
PRINTLN(npublished);
rellena(login, form, L, categ, dirpic);
POST(P6,form,P5.URL);
ASSERT(XFSTRMATCH(balance)(MARKUP(P6)));
a2 = AT("href")(F(O(XFSTRMATCH("ConfAddObj"))(AT("href")))(D("a")(P6)));
GET(P7,a2,P6.URL);
ASSERT(XFSTRMATCH("Ha comenzado su subasta")(TEXT(P7)));
L = R.readLine();
SLEEP(8000);
END
),
publica(ARGS[1],ARGS[2],"5165",ARGS[3],ARGS[4] + " €", "/users/prof/vlc/pic/")
)))))
Figura 7.10: Programa Aucland en XPlore notación compacta (3)
207
Se ha escogido Aucland para ilustrar este ejemplo por ser uno de los
más conocido dentro de aquellos que no cobran gastos por la publicación de
artı́culos en sus Web. Para otros servidores como[6, 11, 18] se ha desarrollado
el mismo programa con lenguaje XPlore igualmente, siendo regularmente
probados de forma satisfactoria en esos servidores durante un periodo de
varios meses consecutivos.
7.3. Listado de correos nuevos en un Web de

correo gratuito y borrado de spam
Numerosos portales ofrecen a sus usuarios un servicio de envı́o y recepción
de correo electrónico accesible desde las páginas Web mediante un navegador.
Gestionar pequeñas cantidades de correo ocasionalmente con estos servidores
puede ser una tarea amigable para muchos usuarios. Sin embargo, cuando el
volumen de mensajes es considerable, gestionar este tipo de cuentas puede ser
una tarea bastante laboriosa, especialmente si se manejan grandes volúmenes
de mensajes y se carece de filtros personalizables que eviten el spam.
El problema que se plantea es el de la obtención de un listado de los
correos nuevos almacenados en el servidor de correo electrónico gratuito de
Yahoo! España [22]. La figura 7.11 presenta un ejemplo de bandeja de entra-
da.
Figura 7.11: Bandeja de entrada del correo de Yahoo!
El programa debe acometer una doble labor. Por una parte, debe obtener
208
ese listado de forma entendible para otros programas, no como aparece para
los usuarios que lo visualizan desde un browser como en la figura 7.11, sino
de forma estructurada, de forma que pueda ser procesado por un programa
integrador de correo que quiera aglutinar en un mismo interfaz los correos de
éste y otros servidores. Por otro lado, el programa también debe aprovechar
el establecimiento de una sesión con el servidor de Yahoo! para borrar todos
aquellos mensajes considerables por el usuario como spam. Si hay mensajes
detectados como spam por los criterios especificables por los usuarios, se
deben borrar todos los que coincidan con ese criterio, teniendo en cuenta
que Yahoo! puede mostrar sus resultados de forma paginada. La figura 7.12
refleja el MSC que explica el algoritmo.
La figura 7.13 refleja el MSC que explica la función de listado y borrado
de correos.
En la figuras 7.14 y 7.15 aparece la correspondiente representación textual
del MSC representado en las figuras 7.12 y 7.13.
Finalmente, la figura 7.16 contiene el código XPlore que realiza la imple-
mentación final. En P1 se almacena la portada. En P2 se almacena la página
de identificación, donde está el formulario que debe rellenarse para acceder
a la cuenta de correo. El resultado del envı́o, la página P3, ofrece distintas
variantes no controladas por el programador, por lo cual resulta muy útil
el uso del operador de evaluación alternativa EVALALT mencionado en el
apartado 5.5.1. Ello es debido a que, en unas ocasiones, P3 es una página
basada en frames, razón por la cual debe seguirse un enlace adicional hasta
llegar hasta la página de bienvenida. En otras ocasiones, P3 es una pági-
na que contiene un redireccionamiento a otra en una etiqueta de tipo meta
situada en la cabecera. En ese caso, debe seguirse ese enlace para acceder
a la página de bienvenida. Yahoo! suele cambiar sin aviso detalles de este
tipo, introduciendo modificaciones que, aunque son transparentes al usuario,
modifican sustancialmente la forma en la que los programas deben acceder
a las siguientes páginas. Por esa razón, en lugar de una polı́tica destinada a
ir cambiando la forma de acceso a la siguiente página cada vez que Yahoo!
decide hacer alguna modificación, se ha optado por el uso de un combinador
de expresiones que prueba una alternativa u otra, dotando al programa de
una mayor robustez para el seguimiento de este enlace.
La página P5 que contiene la bandeja de entrada donde están los nuevos
mensajes, hace un uso intensivo de las tablas para representar sus resultados.
De ella, los datos relevantes para la aplicación son los que aparecen organiza-
dos en la tabla más interna (las más externas son usadas para posicionar los
elementos en la pantalla), y que además contiene alguna palabra clave, como
209
Figura 7.12: MSC gráfico del programa YahooMail
210
Figura 7.13: MSC gráfico del programa YahooMail (2)
211
msc YahooMail;
inst yahoo;
inst client;
instance client;
out GET "http://www.yahoo.es/" to yahoo;

in P1 from yahoo;
action a1=$P1//a[match("Correo", text())][1];
out GET $a1/@href to yahoo;

in P2 from yahoo;
action form2=$P2//form[@name="login_form"];
action $form2//input[@name="login"]/@value=$login;
action $form2//input[@name="passwd"]/@value=$passwd;
evalalt begin;
action frame3=$P3//frame[@name="wmailmain"];
out GET $frame3/@src to yahoo;
evalalt;
action redir=$P3//meta[@http-equiv="Refresh"];
out GET $redir/@content to yahoo;
evalalt end;
in P4 from yahoo;
action a4=$P4//a[match("Bandeja entrada", text())][1];

out GET $a4/@href to yahoo;
in P5 from yahoo;
action keepon = true;
while begin;
condition $keepon;
while;
action table5aux=$P5//table[match("Remitente", text())];
action table5=$table5aux[not(descendant::$table5aux)]
action tr5=$table5[position() != 1 and position() != last()]
action PRINTLN("Number of e-mails: " + count($tr5));
decomposed List_delete();
while end;
endinstance;
endmsc;
Figura 7.14: Programa YahooMail en XPlore notación MSC
212
msc List_delete;
instance client;
foreach begin;
action var i in $tr5;
foreach end;
action PRINTLN(strreplace($i/text(), ’\n’, ’ ’));
endinstance;
action form5=$P5//form[@name="messageList"];
action keepon = false;
foreach begin;
action var i in $tr5[match($sender, td[3]/text()) and match($subject, td[6]/text())];
foreach end;
action $i//input[@type="checkbox"]/@checked="checked";
endinstance;
alt begin;
condition $keepon;
alt end;
action $form5//input[@name="DEL"]/@value="1";
out POST $form5 to yahoo;
in P5 from yahoo;
alt;
endinstance;
endmsc;
Figura 7.15: Programa YahooMail en XPlore notación MSC (2)
“Remitente”. De esa tabla, interesan todas sus filas menos la primera (usada
para las cabeceras explicativas de la tabla) y la última (usada para albergar
los botones que realizan acciones sobre los mensajes marcados). En el código
que aparece en la figura 7.17, esas filas se almacenan mediante una expre-
sión XTendedPath en la variable tr5. Seguidamente se imprime el contenido
textual de esas filas de la página y se comprueba si existe coincidencia entre
las columnas del Asunto del mensaje y el Remitente del mismo, para decidir
si esos mensajes se deben marcar como spam. En el caso en el que alguno
de esos mensajes haya sido detectado como spam, se procede a pulsar en el
botón de borrado para eliminar los mensajes borrados con el correspondiente
formulario y se sigue de la misma manera con las siguientes páginas.
7.4. Recomendaciones de desarrollo

De la experiencia derivada del desarrollo de aplicaciones de integración
de información y servicios obtenibles del Web como [38, 103, 47, 46, 57,
49, 100, 99, 98, 48, 45, 88], y otros varios, de los que se han seleccionado
los que aparecen en el capı́tulo 7, se han podido analizar las principales
213
LET(conecta,FUN((login,passwd,sender,subject),
VAR(P1); VAR(P2); VAR(P3); VAR(P4); VAR(P5);

VAR(a1); VAR(form2); VAR(frame3); VAR(a4);
VAR(table5aux); VAR(table5); VAR(tr5); VAR(form5);
VAR(keepon);
GET(P1,"http://www.yahoo.es/",nil);
/* a1 = $P1//a[match("Correo", text())][1] */
a1 = F(1)(F(O(XFSTRMATCH("Correo"))(TEXT))(D("a")(P1)));
/* form2 = $P2//form[@name="login_form"] */
form2 = F(O(EQ("login_form"))(AT("name")))(D("form")(P2));
/* $form2//input[@name="login"]/@value=$login */
SETATTR("value")(login)(F(O(EQ("login"))(AT("name")))(D("input")(form2)));
/* $form2//input[@name="passwd"]/@value=$passwd */
SETATTR("value")(passwd)(F(O(EQ("passwd"))(AT("name")))(D("input")(form2)));
EVALALT(
/* frame3 = $P3//frame[@name="wmailmain"] */
frame3 = F(O(EQ("wmailmain"))(AT("name")))(D("frame")(P3));
/* PRINTLN("With frames"); */
GET(P4,AT("src")(frame3),P3.URL),
VAR(redir);
/* PRINTLN("Without frames"); */
/* redir = $P3//meta[@http-equiv = "Refresh"] */
redir = F(O(EQ("Refresh"))(AT("http-equiv")))(D("meta")(P3));
/* meta tag redirection */
/* PRINTLN("Without frames redir: " + TOSTR(redir)); */
GET(P4, LET(content, AT("content")(redir),
/* PRINTLN("Without frames content: " + TOSTR(content)); */
XFSUBSTRING(content, XFSTRINDEXOF("=", content) + 1, XFSTRINGLENGTH(content))),
P3.URL)
);
/* a4 = $P4//a[match("Bandeja entrada", text())] */

a4 = F(1)(F(O(XFSTRMATCH("Bandeja entrada"))(TEXT))(D("a")(P4)));
Figura 7.16: Programa YahooMail en XPlore notación compacta
214
keepon = XFTRUE();
WHILE keepon DO
/* table5aux = $P5//table[match("Remitente", text())] */

/* table5 = $table5aux[not(descendant::$table5aux)] */
/* tr5 = $table5/tr[position() != 1 and position() != last()] */
table5aux = F(O(XFSTRMATCH("Remitente"))(TEXT))(D("table")(P5));
table5 = F(NOT(D(table5aux)))(table5aux);
/* tr5 = C("tr")(table5); */
tr5 = F(COND(a,CONDPOS(a) > 1 AND CONDPOS(a) < CONDLAST(a)))(C("tr")(table5));
/* tr5[1] and tr5[last()] are invalid (headers and buttons) */
PRINTLN("Number of e-mails: " + TOSTR(XFCOUNT(tr5)));
FOREACH i IN TOSEQ(tr5) DO
PRINTLN("#@@@@@@@@@@");
PRINTLN(XFNORMALIZESPACE(XFSTRREPLACE(TEXT(i), ’\n’, ’ ’)));
END;
/* form5 = $P5//form[@name="messageList"] */
form5 = F(O(EQ("messageList"))(AT("name")))(D("form")(P5));
keepon = XFFALSE();
/* FOREACH i IN $tr5[match($sender, td[3]/text()) and match($subject, td[6]/text())] DO */

FOREACH i IN TOSEQ(F(COND(a,XFSTRMATCH(sender, TEXT(F(3)(C("td")(a)))) AND
XFSTRMATCH(subject, TEXT(F(6)(C("td")(a))))))(tr5)) DO
/* $i//input[@type="checkbox"]/@checked="checked" */
SETATTR("checked")("checked")(F(O(EQ("checkbox"))(AT("type")))(D("input")(i)));
keepon = XFTRUE();
END;
IF keepon THEN
/* I want to Delete: (as extracted from JavaScript code) */
/* $form5//input[@name="DEL"]/@value="1" */
SETATTR("value")("1")(F(O(EQ("DEL"))(AT("name")))(D("input")(form5)));
END;
END /* WHILE */
),
MKDIR(dirsave);
conecta(ARGS[1],ARGS[2],ARGS[3],ARGS[4])));
Figura 7.17: Programa YahooMail en XPlore notación compacta (2)
215
diferencias y similitudes de servicios que, siendo funcionalmente similares,
son estructuralmente muy hererogéneos.
Más allá de la experiencia adquirida para saber homogeneizar esas po-
sibles diferencias, lo cierto es que, sin pretender establecer unas pautas for-
males para el desarrollo de aplicaciones de navegación automatizada, sı́ se
han formulado una serie de consejos que pueden ayudar notablemente a este
desarrollo. Dichos consejos aparecen formulados a continuación. Su enume-
ración no implica que deban seguirse estrictamente en ese orden o que todos
sean necesarios, pero sı́ se exponen como una guı́a para desarrolladores que
necesiten una base sobre la cual comenzar a crear este tipo de aplicaciones.
1. Identificar clientes y servidores con entidades en un MSC:

Mediante la asimilación de clientes y servidores Web del sistema con
entidades de un MSC se obtiene una escenificación estática de los com-
ponentes que forman parte del sistema a lo largo de su funcionamiento.
Muchas veces, para la especificación de un asistente de navegación que
sólo desea navegar en un único servidor Web, el número de entidades
del sistema se reduce a dos: el servidor Web al que se desea acceder y
un cliente automatizado o código envoltorio que se desea desarrollar.
Éste es, sin duda el caso más sencillo, y del que los apartados 7.2 y
7.3 son algunos ejemplos. No obstante, para aplicaciones de agregación
de datos semiestructurados de diversas fuentes, como el que aparece
en el apartado 7.1, el número de componentes puede ser significativa-
mente más elevado. Por ejemplo, un portal integrador de contenidos y
servicios puede fácilmente acceder a muchos servidores completamente
heterogéneos, cada uno de ellos correspondiéndose con una entidad.
2. Identificar peticiones y respuestas con mensajes en un MSC:

El siguiente paso consiste en empezar a representar el conjunto de inte-
racciones que debe haber entre las entidades del MSC para que pueda
establecerse entre ellos un diálogo correcto. Teniendo en cuenta que
el protocolo HTTP está formado por peticiones a las que les corres-
ponden respuestas únicas, no resulta especialmente dificultoso el poder
representar mediante los mensajes de un MSC esos intercambios entre
clientes y servidores HTTP.
3. Identificar la estructura del programa con las expresiones in-

line de los MSC:
La estructura de los programas que se desea desarrollar puede que-
dar reflejada con un esqueleto de bucles y sentencias condicionales,
anidables entre sı́, dentro de las cuales, deben quedar ajustadas las
216
transacciones HTTP del paso anterior.
4. Identificar las acciones de un MSC:

A continuación, pueden empezar a describirse las acciones (recuadros
de los MSC) que se deben ejecutar en cada entidad. No es necesario
entrar en demasiados detalles si no se desea. Basta con dejar reflejado
qué acciones de alto nivel se desea ejecutar en esos puntos. Las acciones
que se realizan en una entidad preexistente que no se está implementan-
do pueden dejarse entre comentarios, pues su implementación es ajena
a los objetivos de este desarrollo.
5. Simplificar la estructura descomponiendo en referencias a

otros MSC:
Cuando la estructura obtenida de los pasos anteriores da lugar construc-
ciones con una elevada complejidad ciclomática (número de caminos
posibles por las bifurcaciones de salto) o bien se desea poder reutilizar
fragmentos de MSC en varios sitios con una simple referencia, se puede
fragmentar el programa en varios MSC más simples a los cuales hacer
referencia. Ello equivaldrá a descomponer el programa en funciones o
procedimientos reutilizables.
6. Usar la creación y destrucción de componentes para represen-

tar la invocación de programas envoltorio:
El lanzamiento y creación de hilos concurrentes que se encarguen de
ejecutar subtareas en paralelo puede ser el siguiente paso. Para ello,
deberá representarse en el MSC la creación de una entidad por cada
thread que se desea lanzar. De la misma forma, la recepción de los datos
de cada subtarea encargada a cada thread se especificará dentro de una
corregión, puesto que normalmente no es conocible a priori el orden de
la obtención de resultados de cada uno de los threads lanzados, que
terminarán según su ejecución evolucione más o menos deprisa que la
de los demás threads.
7. Detallar el contenido de las acciones de los MSC:

Una vez construido el esqueleto básico del programa conforme a los
pasos anteriores, se puede empezar a detallar el contenido de las ac-
ciones de un MSC. Estas acciones suelen consistir en almacenar o leer
de algún repositorio unos datos, realizar unos cálculos con ellos y al-
macenarlos en un nuevo repositorio. Por ejemplo, puede leerse de una
página Web un dato extraı́do con una expresión XTendedPath y alma-
cenar el resultado de esa evaluación en una variable o en algún fichero.
También puede modificarse la estructura de una página preexistente,
217
como por ejemplo, cuando se rellena un formulario. También pueden
usarse temporizadores, combinadores de servicio, primitivas que modifi-
can el estado de ejecución del programa, operaciones de entrada-salida
o llamadas a procesos externos (ver capı́tulo 6 para una descripción
detallada).
8. Detallar el contenido de las condiciones de los MSC:

Conforme a las variables del programa y con su valor asignado por las
expresiones de cálculo realizadas en las acciones de los MSC, se pueden
definir las condiciones que evalúan cuándo la ejecución debe bifurcarse
hacia una u otra parte del código de un programa.
9. Completar todos los detalles que queden sin definir:

El objetivo de esta fase es terminar de definir aquellos aspectos nece-
sarios para que el programa quede completamente listo para la fase de
traducción y ejecución. Por ejemplo, puede reforzarse la adaptabilidad
ante cambios con un uso intensivo de combinadores de servicio, refinar
la distribución del código en funciones de usuario para que sea reflejo
de un buen diseño, insertar código que haga comprobaciones sobre las
páginas visitadas o mostrar en algún lugar accesible para el usuario los
resultados que se van consiguiendo a lo largo del proceso de navegación.
10. Convertir el MSC gráfico a MSC textual (lenguaje XPlore en

notación MSC):
Ello puede hacerse fácilmente al ser ambas representaciones equivalen-
tes según lo definido en el estándar [76].
11. Convertir el programa XPlore en notación MSC a lenguaje

XPlore en notación compacta:
Ello también puede hacerse fácilmente teniendo en cuenta las equiva-
lencias entre ambas representaciones vistas en el capı́tulo 6.
12. Ejecutar y analizar los resultados obtenidos:

Una vez obtenido el programa XPlore, sólo basta invocarlo (trans-
formándolo a lenguaje de programación y generando el prototipo eje-
cutable a partir de éste) desde la plataforma de ejecución y comprobar
que devuelve los resultados esperados. Si no los devuelve, deben ana-
lizarse los documentos visitados en detalle para averiguar la causa del
fallo de esa extracción de datos.
13. Repetir todos los pasos anteriores para construir prototipos

incrementales:
Construir un programa que navegue en la Web requiere poder analizar
218
cada uno de las páginas o documentos que van siendo obtenidos de
los servidores. Lo habitual para escribir estos programas es empezar
escribiendo un programa que acceda a la página principal del servicio
al que sea acceder, de forma que los siguientes prototipos vayan incor-
porando uno a uno, el seguimiento de cada uno de los enlaces que se
desea atravesar. De esta forma, se deberán desarrollar al menos tan-
tos prototipos como enlaces se desee atravesar, pero ese número no es
demasiado elevado si se tiene en cuenta que suele haber caminos por
páginas repetibles que suelen poder especificarse dentro de bucles u
otros MSC externos reutilizables.
14. Revisar el funcionamiento de las aplicaciones y realizar una

labor de mantenimiento:
Dado el amplı́simo espectro de causas que pueden invalidar alguna ex-
presión de extracción de datos del código o, menos frecuentemente,
cambios que afecten a la navegación, es necesario realizar una labor de
mantenimiento de este tipo de programas y, en la medida de lo posible,
reforzarlos en aquellos puntos más vulnerables a esas modificaciones
con expresiones que mejoren su robustez y adaptabilidad, usando com-
binadores de servicios, sinónimos, y explorando variantes en general
que puedan preveerse en la medida de lo posible.
219
220
Capı́tulo 8
Conclusiones y trabajos futuros
El presente capı́tulo enumera una serie de conclusiones y unas lı́neas de

trabajo futuro.
8.1. Principales contribuciones

Las principales contribuciones de esta tesis son las siguientes.
Se ha realizado un análisis de las tareas en el Web para estructurarlas

según sus componentes elementales comunes, a los que se ha denomina-
do acciones básicas. Dicho análisis, que aparece en el capı́tulo 2 clasifica
las acciones que forman parte de toda tarea en el Web en dos grandes
grupos: acciones básicas implı́citas y acciones básicas explı́citas. Para
cada una de ellas se detallan sus caracterı́sticas de cara a la implemen-
tabilidad y su influencia en los costes de desarrollo y mantenimiento,
tanto desde el punto de vista de los programas de navegación automáti-
ca particularizada mencionados en el apartado 1.3, como la dificultad
que implican al usuario que usa browsers en una navegación manual.
Se ha realizado un estudio del estado del arte que analiza las principales
caracterı́sticas de las tecnologı́as usadas hasta el momento en el ámbito
de la automatización del tratamiento de los datos obtenidos del Web.
Dicho estudio, plasmado en el capı́tulo 3, alberga tanto los lenguajes
de programación desarrollados a este propósito como los marcos con-
ceptuales en donde se están encuadrando las últimas tendencias (Web
Semántico), intentando reflejar para cada uno de ellos sus principales
aportaciones y limitaciones.
221
Se han seleccionando las tecnologı́as más adecuadas para mejorar la
calidad de los productos obtenibles, teniendo en cuenta el inherente
aspecto de cambio, semiestructuración y propensión a fallos de la Web y
se han resumido sus funcionalidades en el capı́tulo 4. Dichas tecnologı́as
han resultado ser un estándar de la ITU (los MSC), cuatro lenguajes
definidos por el W3C (XPath, XPointer, XQuery y XSLT) y dos API
de programación (SAX y DOM).
Se ha realizado una propuesta de creación de programas de navegación

automatizada a bajo coste que está basada en un método formal, los de-
nominados MSC (Message Sequence Charts [76]) estandarizados por la
ITU. Hasta el momento no se conoce aplicación práctica de este méto-
do formal en la especificación de programas de navegación en el Web,
mencionados en el apartado 1.3. En este trabajo, se demuestra que los
MSC son un mecanismo adecuado para la especificación de aplicacio-
nes que realizan tareas en el Web y que modela adecuadamente tanto
escenarios sencillos como complejos, especialmente aquellos en los que
se deba interactuar con varios servidores o en el que las transacciones
sean complejas o numerosas. Cada MSC puede fácilmente especificar
el comportamiento que un cliente puede realizar con un servidor Web
a lo largo de una sesión o de un fragmento de la misma. Los MSC son
adecuadamente útiles para especificar las acciones que conforman se-
siones o fragmentos de sesiones en el Web mediante una representación
tanto textual como gráfica. Esta representación es capaz de ofrecer a
simple vista una visión general del algoritmo, pero permite a su vez la
especificación de detalles técnicos de bajo nivel. Los MSC son comple-
mentados con otros estándares para realizar manipulaciones sobre los
documentos.
Para la fácil creación de programas y la demostración de aplicabilidad

en entornos reales existentes en el Web legado, se ha diseñado un len-
guaje de programación, denominado XPlore y descrito en el apartado
6, basado en los MSC y susceptible de ser utilizado como formato de es-
pecificación de requisitos de aplicaciones de navegación automatizada,
tanto directamente, como con una posible herramienta CASE, como
se sugiere en el apartado 8.3.1. De este lenguaje se proporcionan en
el capı́tulo 7 algunos ejemplos que demuestran cómo la realización de
algunas tareas en el Web puede ser especificada con programas don-
de, con un conjunto simple y flexible de constructores del lenguaje, es
posible la realización de tareas en servidores del Web legado.
Partiendo de una supuesta versión de XPointer que estuviera basada
222
en XPath 2.0 (en lugar de en la versión 1.0 actual), se ha diseñado
un lenguaje XTendedPath para la consulta y manipulación de docu-
mentos semiestructurados basados en XML, que aúna la funcionalidad
de XPath 2.0 para el direccionamiento de datos en documentos, la fle-
xibilidad de XPointer para extraer fragmentos no asociables a partes
predefinidas de árboles, la capacidad de modificación de XUpdate y la
flexibilidad de DOM a un coste inferior a éste. Entre otras extensio-
nes, que aparecen descritas en el apartado 5.3, se permite además al
usuario la posibilidad de reutilizar código mediante la definición de sus
propias funciones de usuario, algo que tampoco estaba presente entre
las posibilidades del actual borrador ni de XPath ni de XPointer.
Se ha proporcionado una plataforma de ejecución para programas escri-

tos en XPlore y XTendedPath de forma que los programas expresados
en esos lenguajes tengan durante su ejecución el conveniente soporte de
las acciones básicas implı́citas mencionadas en el apartado 2.1. Dicha
plataforma está formada por la combinación de un programa compi-
lador que traduce esos lenguajes a un lenguaje de programación con-
vencional de alto nivel y también un conjunto de funciones de soporte
embebidas en bibliotecas, de forma que son convenientemente enlaza-
das con los programas traducidos de las especificaciones en XPlore y
XTendedPath para formar ası́ un programa ejecutable final.
8.2. Conclusiones
A continuación se evalúa el grado de consecución de los objetivos del
apartado 1.7.
1. Los mecanismos de desarrollo deseados en el planteamiento del traba-

jo, capaces de tener minimizados los costes de desarrollo y ser com-
prensibles y de alto nivel de abstracción se han concretado en el uso
combinado de dos estándares que son MSC y XPath, en el lenguaje
de programación XPlore y en la plataforma de traducción de XPlore
a lenguaje de programación convencional (WebL). Asimismo, la forma
de utilizar estos mecanismos se ha expuesto en unas guı́as que pue-
den servir de consejo para desarrollar aplicaciones y que aparecen en el
apartado 7.4.
2. La plataforma con buen soporte para las acciones implı́citas también

se ha conseguido. Para ello se ha partido de la mejora de una existente
223
a la que se ha añadido soporte a varios detalles técnicos importantes
como el correcto manejo de los formularios a un adecuado nivel de
abstracción, la incorporación de un corrector externo de errores en la
construcción de páginas y el control de protocolos seguros (HTTPS).
3. Las acciones sencillas son fácilmente realizables sin necesidad de recu-

rrir a soluciones costosas como la continua programación de funciones
de usuario o la delegación de todo tratamiento de los documentos a
hojas XSLT, cuya capacidad de procesamiento es bastante limitada.
4. Las acciones más complejas, sin embargo, sı́ son fácilmente resolubles
por el usuario en código definible por él de varias formas. Puede usar
tanto sus propias funciones de biblioteca programadas en XPlore, como
rutinas programadas en una biblioteca de usuario en Java, como llamar
a programas externos.
5. Con los combinadores de servicio se proporciona al usuario mecanismos

adecuados para reducir los costes de ejecución fallida. El usuario es
libre de usarlos como más le plazca. También puede insertar código
para comprobar que las páginas visitadas cumplen las condiciones que
se espera de ellas.
6. El coste de mantenimiento queda convenientemente reducido por el

hecho de que cada acción básica explı́cita de las mencionadas en el
apartado 2.2 queda reflejado en una única lı́nea de código, lo cual im-
plica que cualquier cambio que se desee realizar en el programa debido
a una modificación de la estructura de páginas del servidor suele afec-
tar la gran mayorı́a de las veces a una única lı́nea de código. Por otro
lado, en el caso de producirse el error, el sistema proporciona un men-
saje detallando la lı́nea de código que produjo el error e información
contextual acerca del momento en el que se produjo el fallo.
7. Los programas desarrollables con XPlore son aplicables al Web legado

siempre y cuando sus páginas HTML sean manipulables o corregibles
por herramientas especializadas como Tidy. Los principales problemas
o restricciones de aplicabilidad del Web legado vienen dados por la
navegación basada en JavaScript y por los elementos multimedia que
restan accesibilidad a la página.
8. Finalmente, XPlore es una solución aplicable al Web basado en XML

porque el mecanismo de extracción de datos sobre el que se basa es
XPath, razón por la cual la aplicación al Web legado es simplemente
224
un caso particularizado de la aplicación a documentos definibles con el
lenguaje de marcas del W3C (XML).
8.3. Lı́neas de trabajos futuros

Las actuales lı́neas de trabajos futuro de esta tesis son variadas. La pla-
taforma de ejecución puede ser mejorada y ampliada con múltiples mejoras
relacionadas con las acciones básicas implı́citas como las mencionadas en el
apartado 2.1. La sintaxis del lenguaje XTendedPath sin duda es mejorable.
Por otro lado, serı́a deseable contrastar la utilización de XPlore en un mayor
número de aplicaciones de integración. Sin embargo, en este apartado se des-
tacarán sólo dos lı́neas de trabajo que se considera especialmente relevantes.
Por un lado, la mejora de la amigabilidad de XPlore por personas que no
tengan especiales habilidades para la programación. Por otro lado la mejora
de la aplicabilidad de estos programas a un mayor número de servidores del
Web legado.
8.3.1. Herramienta CASE

Si bien XPlore ha resultado en los ejemplos desarrollados hasta el mo-
mento una aportación a la simplificación del desarrollo y reducción del coste
de mantenimiento, sin perder flexibilidad ni expresividad para la extracción,
navegación o manipulación de datos obtenidos del Web, el hecho de que sea
un lenguaje de programación no deja de implicar que sólo sea utilizable por
programadores. Por esa razón, especialmente en las fases iniciales de desa-
rrollo, hubiera sido muy de agradecer por las personas que lo han utilizado
para desarrollar trabajos con él [38, 103], ası́ como el autor de esta tesis en
los ejemplos que ha desarrollado por su cuenta [42, 44, 41, 43], la utilización
de una herramienta CASE capaz de asistir al usuario en el desarrollo de este
tipo de programas.
Una herramienta capaz de guiar al usuario en su definición de algoritmos
de navegación, abstrayéndole de los aspectos de bajo nivel para que se pueda
concentrar en la lógica del problema que está automatizando, podrı́a supo-
nerle sin duda una importante ayuda. Si bien la construcción de este tipo de
herramientas no forma parte de los objetivos directos de este trabajo, una
herramienta CASE que ayude a la creación fácil de asistentes de navegación
y que utilice los mecanismos descritos en su apartado 8.1 y 7.4 no deberı́a
ser difı́cilmente realizable y sin embargo sı́ podrı́a resultar muy útil para
225
desarrollar programas en lenguaje XPlore.
8.3.2. Accesibilidad a sitios Web orientados a la visua-

lización
El Web basado en documentos HTML bien construidos desde el pun-

to de vista de la accesibilidad es bastante navegable, pese a la orientación
a la visualización de muchas de las etiquetas y atributos de ese lenguaje.
Sin embargo, la utilización masiva de elementos multimedia como imágenes,
animaciones Flash, applets, plugins y rutinas JavaScript, tal y como se men-
cionaba en el apartado 1.4.3, puede dificultar muy seriamente la capacidad
de operación de los programas de navegación automatizada. Ello debe ser,
sin duda, un factor a tener en cuenta en los trabajos relacionados por estas
tecnologı́as de automatización de tareas en el Web.
Desde el punto de vista de los servidores
Los desarrolladores de servidores pueden tener en mente objetivos muy

diversos dependiendo de cuál sea la polı́tica de accesos que quieran establecer.
Si se desea favorecer el acceso al servidor Web por el mayor espectro de
posibles clientes (browsers, robots, agentes, asistentes, ...), una de las mejores
opciones consiste en seguir consejos y guı́as que mejoren la accesibilidad,
como por ejemplo las que aparecen definidas en [128, 137, 136].
Si se desea restringir el acceso al servidor Web de forma que sólo unos
determinados tipos de clientes (tı́picamente los usuarios con browsers) ten-
gan acceso completo a los contenidos mientras que otro tipo de clientes de
navegación automatizada no sean capaces de navegar adecuadamente por el
servidor, una de las mejores opciones suele ser optar por la opción contraria,
es decir, aplicar de forma contraria las recomendaciones de accesibilidad defi-
nidas en [128, 137, 136], especialmente aquellas que contengan contenidos de
tipo multimedia, que, como se describe en [2], suelen dar un buen resultado
como medida de filtro para seleccionar a los usuarios que acceden. Establecer
este tipo de restricciones de acceso puede estar motivado normalmente por
polı́ticas relacionadas normalmente con aspectos económicos y sociales como
la publicidad o los derechos de autor, o bien con aspectos técnicos (evitar que
un robot pueda sobrecargar un servidor) y, en cualquier caso, es un derecho
que tienen los responsables de los contenidos que se publican en un servidor
Web y que debe ser respetado.
226
Desde el punto de vista de los clientes
Los desarrolladores de clientes deben tener en cuenta cuáles son las polı́ti-
cas de restricciones establecidas por los servidores Web y ser respetuosos con
esos servidores, cumpliendo unas mı́nimas normas de cortesı́a que eviten que
su interacción con el servidor pueda ser usada con efectos perniciosos para el
servidor o para otros usuarios.
Sin embargo, en muchas ocasiones, la falta de accesibilidad de un sitio
Web suele estar más motivada por su despreocupación por las recomenda-
ciones de accesibilidad del W3C que por el temor a ser accedidos por robots.
Los clientes enfocados a la automatización de tareas en estos servidores Web
deben enfrentarse a múltiples problemas derivados de la falta de mecanismos
para acceder adecuadamente a los datos involucrados en una tarea. Actual-
mente, las principales restricciones de XPlore vienen dadas por dos problemas
no resueltos en esta tesis, y para las cuales buscar soluciones implica esfuer-
zo, por lo que se proponen como trabajos futuros la mejora de los siguientes
aspectos.
JavaScript Las animaciones JavaScript exigen la interpretación de código

de programa vinculado a las páginas en la plataforma del cliente. La
plataforma de ejecución que da soporte a XPlore no dispone de ningún
intérprete de JavaScript, por lo que todas las acciones JavaScript rele-
vantes para la navegación deben ser emuladas con código XPlore pro-
gramado ad hoc. Incorporar a la plataforma de ejecución el motor de
interpretación de JavaScript de un browser (como por ejemplo se pro-
gramó en [31]), podrı́a ser una solución a este problema. )
Contenidos multimedia Los contenidos multimedia que pueden estar in-

volucrados en la navegación, como imágenes, applets, plugins o anima-
ciones Flash no siempre vienen acompañados de descripciones textuales
que ayuden a su entendimiento para una buena navegación. Es posi-
ble usar los atributos alt o title en muchas etiquetas HTML para
basar en esas descripciones la navegación, pero si esas descripciones
faltan, es muy probable que la herramienta que se pretende desarrollar
no pueda ser completamente automática y que requiera la intervención
manual de un operador que reconozca visualmente el elemento multi-
media y actúe en consecuencia. Asimismo, otros formatos ajenos a los
estándares del W3C, como los formatos PDF, PS, DOC, RTF, ... son
difı́cilmente analizables si no se dispone de una biblioteca que permita
acceder a la estructura de esos documentos de forma adecuada. XPlore
no tiene incorporada ninguna biblioteca de acceso a estos formatos pro-
227
pietarios ni tampoco puede seleccionar enlaces que no estén descritos
por una descripción textual, con lo que los enlaces basados en imágenes
suelen acabar presentando algunos problemas que deben ser resueltos
de formas poco ortodoxas y que confieren puntos de poca estabilidad en
el código fuente. Cualquier iniciativa que permita mejorar estos aspec-
tos permitiendo un reconocimiento visual automatizado del elemento
multimedia puede suponer una mejora importante en XPlore y en las
técnicas de desarrollo de programas de navegación automatizada en
general.
8.3.3. Desarrollo de agentes inteligentes no particula-

rizados
Si bien XPlore se centra en el desarrollo de aplicaciones potentes de auto-
matización de tareas en el Web, los programas desarrollados con este lenguaje
están particularizados a cada tarea. Sin duda, serı́a mucho más deseable no
tener que programar una aplicación de este tipo para cada tarea, sino dispo-
ner de un agente de propósito general capaz de analizar las páginas Web de
un determinado dominio y decidir, conforme a los objetivos definidos por un
usuario, los enlaces que deben seguirse y la forma en la que deben rellenar-
se los formularios, decidiendo todo en tiempo de navegación y no teniendo
preprogramadas esas decisiones en aplicaciones que tı́picamente suelen fallar
cuando algún elemento esperable en el camino de esa navegación se presenta
de forma distinta a la esperada. Tal y como se vio en el apartado 1.3, este
tipo de programas se corresponde con el Web Semántico [32], en el cual están
puestas las expectativas en este sentido.
228
Apéndices
8.4. Gramática EBNF del lenguaje XPlore
Module = { Import } SS
Import = IMPORT "(" Ident ")" ";"
SS = (Var | E) { ";" (Var | E) } [ ";" ]
Var = VAR "(" Ident ")"
E = Value
| E BinOp E
| UnOp E
| "(" E ")"
| E "(" [ E { "," E } ] ")"
| E "[" E "]"
| Ident "=" E
| Statement
| FieldRef
Value = nil | Bool | String | Real | Integer | Sequence

Bool = XFTRUE "(" ")" | XFFALSE "(" ")"
String = "’" { Char } "’" | ’"’ { Char } ’"’
Real = Integer [ Fraction ] [ Exponent ]
Fraction = "." Integer
Exponent = ( "e" | "E" ) [ "+" | "-"] Integer
Integer = Digit { Digit }
Sequence = "[" [ E { "," E } ] "]"
BinOp = "+" | "-" | "*" | "/" | DIV | MOD

| "<" | "<=" | "==" | "!=" | ">" | ">="
| AND | OR
| "|" | "?"
UnOp = "-" | "+" | "!"
Statement = WhileStat | IfStat | FunStat | EveryStat | ConcurrentStat | ReturnStat

WhileStat = WHILE SS DO SS END
IfStat = IF SS THEN SS [ ElseStat ] END
ElseStat = ELSE SS | ELSIF SS THEN SS [ ElseStat ]
FunStat = FUN "(" "(" [ Ident { "," Ident } ] ")" "," SS ")"
EveryStat = FOREACH Ident IN E DO SS END
ConcurrentStat = BEGINCONCURRENT SS2 ENDCONCURRENT
SS2 = (Var | E) { CONC (Var | E) }
ReturnStat = RETURN [E]
FieldRef = E "." Ident [ "(" [ E { "," E } ] ")" ]
Ident = Letter { Letter | Digit }
229
Digit = "0" .. "9"
Letter = "a" .. "z" | "A" .. "Z"
230
Bibliografı́a
[1] Aucland online auctions. www.aucland.com.

[2] Captcha programs. www.captcha.net.
[3] Comparador de tarifas telefónicas. www.teltarifas.com.
[4] Consors españa. www.consors.es.
[5] Curl tool. curl.haxx.se/docs/httpscripting.shtml.
[6] ebay online auctions. www.ebay.com.
[7] European central bank. www.ecb.int.
[8] Flowers.com. www.flowers.com.
[9] Google. www.google.com.
[10] Lynx browser. lynx.browser.org.
[11] Mercadolibre. En Sitio de subastas, www.mercadolibre.com.
[12] Mozilla browser. www.mozilla.org.
[13] Msn hotmail. www.hotmail.com.
[14] Nasdaq quotes. quotes.nasdaq.com.
[15] Net minder. www.netmind.com.
[16] Rdf site summary (rss) 1.0. web.resource.org/rss/1.0/.
[17] Red hat, inc. www.redhat.com.
[18] Segundamano. En Portal de anuncios clasificados, www.segundamano.es.
[19] Sun microsystems, inc. www.sun.com.
[20] Wget tool. sunsite.auc.dk/pub/infosystems/wget/.
[21] Xpath explorer. http://sourceforge.net/projects/xpe.
[22] Yahoo! www.yahoo.com.
[23] G. Aas. Lwp – library for www access in perl.
perl.com/CPAN/modules/bymodule/LWP/.
[24] S. AG. Tamino xml server. www.softwareag.com/tamino.
[25] P. Atzeni, G. Mecca, and P. Merialdo. Semistructured and structured da-
ta in the web: Going back and forth. En Workshop on Management of
Semistructured Data, 1997.
[26] A. S. F. Azavant. Building light-weight wrappers for legacy web data-sources
using w4f. International Conference on Very Large Databases (VLDB), 1999.
[27] J. Baeten, H. van Beek, and S. Mauw. An MSC based representation of
DiCons. En Proceedings of the 10th SDL Forum, pags 328–347, Copenhagen,
Denmark, June 2001.
231
[28] R. A. Baeza-Yates and B. A. Ribeiro-Neto. Modern Information Retrieval.
ACM Press / Addison-Wesley, 1999.
[29] R. Baumgartner, S. Flesca, and G. Gottlob. Visual web information extrac-
tion with lixto. En The VLDB Journal, pags 119–128, 2001.
[30] M. Benedikt, J. Freire, and P. Godefroid. Veriweb: Automatically testing
dynamic web sites. En WWW 11th conference, 2002.
[31] C. A. P. Bermúdez. Un sistema mediador para la integración de datos
estructurados y semiestructurados. En Tesis Doctoral, Departamento de
Tecnoloxı́as de Información e as Comunicacións - Universidade Da Coruña,
2002.
[32] T. Berners-Lee, J. Hendler, and O. Lassila. The semantic web. En Scientific
American, May 2001.
[33] T. Bolognesi and E. Brinksma. Introduction to the iso specification language
lotos. En The Formal Description Technique LOTOS P. H. J. van Eijk,
C. A. Vissers, and M. Diaz, Eds, pags 23–73, Elsevier Science Publishers
North-Holland, 1980.
[34] R. P. Bourret. Xml data binding resources.
www.rpbourret.com/xml/XMLDataBinding.htm.
[35] S. Bressan and P. Bonnet. The eclipse http library. En Proc. of the Intl.
Conf. on Indutrial Applications of Prolog, 1996.
[36] P. Buneman. Semistructured data. 16th acm symposium on principles of
database systems. pags 117–121, 1997.
[37] D. Buttler, L. Liu, and C. Pu. A fully automated extraction system for the
world wide web. IEEE ICDCS-21, April 16-19 2001.
[38] M. E. G. Cabellos. Desarrollo de un portal web integrador de información
basada en subastas online. En Proyecto Fin De Carrera, Escuela Politécnica
Superior, Ingenierı́a de Telecomunicación - Universidad Carlos III de Ma-
drid, 2003.
[39] D. Cabeza and M. Hermenegildo. The pillow web programming library -
reference manual, citeseer.nj.nec.com/cabeza00pillow.html.
[40] L. Cardelli and R. Davies. Service combinators for web computing. Software
Engineering, 25(3):309–316, 1999.
[41] V. L. Centeno, P. T. Breuer, L. S. Fernández, C. D. Kloos, and J. A. H.
Pérez. Msc-based language for specifying automated web clients. En The
Eighth IEEE Symposium on Computers and Communications, Kemer, An-
talya, Turkey, June 30 - July 3 2003.
[42] V. L. Centeno, L. S. Fernández, C. D. Kloos, P. T. Breuer, and M. E. G.
Cabellos. Standards-based languages for programming web navigation as-
sistants. En 5th IEEE International Workshop on Networked Appliances,
pags 70–75, Liverpool, U.K., October 2002.
[43] V. L. Centeno, L. S. Fernández, C. D. Kloos, P. T. Breuer, and F. P. Martı́n.
Building wrapper agents for the deep web. En International Conference on
Web Engineering, Oviedo, Spain, July 2003.
232
[44] V. L. Centeno, C. D. Kloos, P. T. Breuer, L. S. Fernández, M. E. G. Ca-
bellos, and J. A. H. Pérez. Automation of the deep web with user defined
behaviours. En First International Atlantic Web Intelligence Conference,
AWIC 2003, Lecture Notes in Artificial Intelligence LNAI 2663 (Subseries
of Lecture Notes in Computer Science), Ed. Springer, pags 339–348, Madrid,
Spain, May 2003.
[45] V. L. Centeno, M. C. F. Panadero, C. D. Kloos, A. M. López, and C. G. Ru-
bio. Personalizing your electronic newspaper. En EUROMEDIA 99: Fourth
Annual Scientific Conference on Web Technology, New Media, Communica-
tions and Telematics Theory, Methods, Tools and Applications, pags 16–22,
Munich, Germany, Abril 1999.
[46] V. L. Centeno, M. C. F. Panadero, C. D. Kloos, A. M. López, and C. G.
Rubio. Diseño de un periódico electrónico personalizado. En IV Jornadas
de Informática, pags 251–260, Las Palmas de Gran Canaria, España, Julio
1998.
[47] V. L. Centeno, M. C. F. Panadero, C. D. Kloos, A. M. López, and C. G.
Rubio. Concepción y desarrollo de un periódico electrónico personalizado.
En Jornadas Técnicas RedIRIS, pags 24–31, Barcelona, España, Noviembre
1998.
[48] V. L. Centeno, M. C. F. Panadero, D. R. Mateos, C. D. Kloos, A. R. de las
Heras, A. M. López, C. G. Rubio, T.Ñ. Flores, and T. H. Pérez. Mass-
customizing electronic journals. En XML EUROPE’99 Conference, pags
233–240, Granada, Spain, Abril 1999.
[49] V. L. Centeno, M. C. F. Panadero, D. R. Mateos, C. D. Kloos, A. R. de las
Heras, A. M. López, C. G. Rubio, T.Ñ. Flores, and T. H. Pérez. El periotróni-
co: Xml en un periódico electrónico a la carta. resultados y perspectivas. En
I Seminario del Programa Nacional de Aplicaciones y Servicios Telemáticos
(SPAST-I), pags 167–174, Pamplona, España, Noviembre 1999.
[50] S. Ceri, P. Fraternali, and A. Bongio. Web Modeling Language (WebML):
a modeling language for designing Web sites. Computer Networks (Amster-
dam, Netherlands: 1999), 33(1–6):137–157, 2000.
[51] S. Chawathe, H. Garcia-Molina, J. Hammer, K. Ireland, Y. Papakonstan-
tinou, J. D. Ullman, and J. Widom. The TSIMMIS project: Integration
of heterogeneous information sources. En 16th Meeting of the Information
Processing Society of Japan, pags 7–18, Tokyo, Japan, 1994.
[52] D.Ñ. Chorafa. Handbook of Database Management and Distributed Relatio-
nal Databases. Tab Professional and Reference; 1st Edition edition, 1989.
[53] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web services
description language (wsdl) 1.1. En W3C Note, 2001.
[54] F. Cohen. An xml-based scripting language that calls on java objects can
prove web software reliable www-106.ibm.com/developerworks/library/j-
load.html?n-j-671.
233
[55] V. Crescenzi, G. Mecca, and P. Merialdo. Roadrunner: Towards automatic
data extraction from large web sites. En The VLDB Journal, pags 109–118,
2001.
[56] A. Deutsch, M. Fernandez, D. Florescu, A. Levy, and D. Suciu. A query
language for xml. www.research.att.com/ mff/files/final.html.
[57] M. C. Fernández, V. L. Centeno, C. D. Kloos, A. M. López, and C. G. Rubio.
Diseño de un periódico electrónico con xml. En II Congreso Nacional de
Ingenierı́a de Telecomunicación, pags 339–343, Madrid, España, Junio 1998.
[58] J. A. Fisteus. Diseño e implementación de un conversor de html a xhtml.
En Proyecto Fin De Carrera, E.T.S.E. Telecomunicación - Universidade de
Vigo, 2001.
[59] D. Florescu, A. Grunhagen, and D. Kossmann. Xl: An xml programming
language for web service specification and composition. En WWW 11th
conference, 2002.
[60] D. Florescu, A. Y. Levy, and A. O. Mendelzon. Database techniques for the
world-wide web: A survey. SIGMOD Record, 27(3):59–74, 1998.
[61] W. Forum. Wireless markup language. www.wapforum.org.
[62] A. Foundation. Xalan library. http://xml.apache.org/xalan-j/index.html.
[63] A. Foundation. Xindice xml database. www.xindice.com.
[64] C. Frye, M. Plusch, and H. Lieberman. Spinning the Semantic Web – Static
and Dynamic Semantics of the Web. The MIT Press, 2003.
[65] C. Goldfarb. The SGML handbook. Oxford University Press, 1992.
[66] R. Goldman, J. McHugh, and J. Widom. From semistructured data to XML:
Migrating the lore data model and query language. En Workshop on the
Web and Databases (WebDB ’99), pags 25–30, 1999.
[67] J.-R. Gruser, L. Raschid, M. E. Vidal, and L. Bright. Wrapper generation
for web accessible data sources. En Conference on Cooperative Information
Systems, pags 14–23, 1998.
[68] H. Gupta. Selection of views to materialize in a data warehouse. En ICDT
citeseer.nj.nec.com/gupta97selection.html, pags 98–112, 1997.
[69] M. Hall. Core Servlets and JavaServer Pages. Prentice Hall, 2000.
[70] J. Hammer, H. Garcı́a-Molina, S.Ñestorov, R. Yerneni, M. Breunig, and
V. Vassalos. Template-based wrappers in the TSIMMIS system. pags 532–
535, 1997.
[71] D. Harel. Statecharts: A visual formalism for complex systems. Science of
Computer Programming, 8(3):231–274, June 1987.
[72] E. R. Harold. Getting started with xom.
http://xml.com/pub/a/2002/11/27/xom.html, Nov 2002.
[73] G. J. Holzmann. Promela online reference cm.bell-
labs.com/cm/cs/what/spin/man/intro.html, 2001.
[74] E. S. Information and C. Systems. Standard ecma-262. En EC-
MAScript Language Specification, www.ecma.ch/ecma1/STAND/ECMA-
262.HTM, December 1999.
234
[75] ITU-T. Recommendation z.100: Specification and description language (sdl).
En Formal description techniques (FDT), Geneva, Switzerland, 1993.
[76] ITU-T. Recommendation z.120: Message sequence chart (msc). En Formal
description techniques (FDT), Geneva, Switzerland, 1997.
[77] H. J. and M. B. The jdom project www.jdom.org.
[78] A. R. S. Jim Melton. Understanding the New SQL: A Complete Guide Older
Edition.
[79] V. Josifovski. Design, implementation and evaluation of a distributed me-
diator system for data integration, phd thesis (linkping studies in science
and technology. dissertations 582) isbn 91-7219-482-0, linkping university,
linkping, sweden, june 1999., 1999.
[80] T. Kistler and H. Marais. Webl - a programming language for the web.
En Proceedings of the 7th International World Wide Web Conference, pags
259–270, Computer Networks and ISDN Systems 30, 1998.
[81] T. Klement. Jedi: Java extraction and dissemination of information,
www.darmstadt.gmd.de/oasys/projects/jedi/index.html.
[82] C. D. Kloos, P. T. Breuer, V. L. Centeno, and L. Sánchez. Higher order ap-
plicative xml documents. En Monterey Workshop 2002: Radical Innovations
of Software and Systems Engineering in the Future, Venice, Italy, October
2002.
[83] N. Kushmerick, D. S. Weld, and R. B. Doorenbos. Wrapper induction for
information extraction. En Intl. Joint Conference on Artificial Intelligence
(IJCAI), pags 729–737, 1997.
[84] D. Libes. expect: Scripts for controlling interactive processes. Computing
Systems, 4(2):99–125, 1991.
[85] L. Liu, C. Pu, and W. Han. XWRAP: An XML-enabled wrapper construc-
tion system for web information sources. En ICDE, pags 611–621, 2000.
[86] M. T. Ltd. Sax: The simple api for xml www.megginson.com/sax.
[87] S. Lu, M. Dong, and F. Fotouhi. The semantic web: Opportunities and
challenges for next-generation web applications. Information Research, 7(4),
2002. Special Issue on the Semantic Web.
[88] D. R. Mateos, V. L. Centeno, M. C. F. Panadero, C. D. Kloos, A. R. de las
Heras, A. M. López, C. G. Rubio, L. S. Fernández, J. T.Ñ. Flores, and
A. H. Pérez. Prensa en xml: el negocio de la personalización y la conquista
de nuevos medios. En Jornadas Telecom I+D, Madrid, España, 2000.
[89] R. McCool. The common gateway interface. En National Center for Super-
computing Applications, University of Illinois at Urbana-Champaign.
[90] G. Michaelson. An introduction to functional programming through lambda
calculus. En Addison-Wesley, XV, 320 S. - ISBN 0-201-17812-5, 1988.
[91] Microsoft. Internet explorer browser. www.microsoft.com/catalog/.
[92] M. Mohania, K. Karpalem, and M. Vincent. Maintenance of datawarehouse
views using normalization. d ram, editor, data management, pages 32–50.
springer verlag, 1997.
235
[93] I. Muslea, S. Minton, and C. A. Knoblock. Hierarchical wrapper induc-
tion for semistructured information sources. Autonomous Agents and Multi-
Agent Systems, 4(1/2):93–114, 2001.
[94] J. Myllymaki. Effective web data extraction with standard XML techno-
logies. En World Wide Web 10th Conference, Hong Kong, pags 689–696,
2001.
[95] Netscape. Persistent client state http cookies.
www.netscape.com/newsref/std/cookiespec.html.
[96] G. of Canada. Internet guide. En Universal accessibility,
www.canada.gc.ca/programs/guide/3 1 4e.html.
[97] J. K. Ousterhout. Tcl: An embeddable command language. En Proceedings
of the USENIX Winter 1990 Technical Conference, pags 133–146, Berkeley,
CA, 1990. USENIX Association.
[98] M. C. F. Panadero, V. L. Centeno, C. D. Kloos, A. M. López, T. Hernández,
C. G. Rubio, and L. S. Fernández. Mass-customizing electronic newspapers.
En ICCC/IFIP Third Conference on Electronic Publishing, pags 225–235,
Ronneby, Sweden, Mayo 1999.
[99] M. C. F. Panadero, V. L. Centeno, D. R. Mateos, C. D. Kloos, A. R. de las
Heras, A. M. López, C. G. Rubio, T.Ñ. Flores, and T. H. Pérez. Un periódico
a la carta: información personalizada mediante el uso de xml. En Jornadas
de Publicación electrónica, pags 135–147, Leganés, Madrid, Julio 1999.
[100] M. C. F. Panadero, V. L. Centeno, D. R. Mateos, C. D. Kloos, A. R. de las
Heras, A. M. López, C. G. Rubio, T.Ñ. Flores, and T. H. Pérez. Periodismo
electrónico a la carta: noticias personalizadas con xml. En Novática: Re-
vista de la Asociación de Técnicos de Informática, Num; 142, pags 16–19,
Noviembre - Diciembre 1999.
[101] Y. Papakonstantinou, S. Abiteboul, and H. Garcia-Molina. Object fusion
in mediator systems. En Proceedings of the Twenty-second International
Conference on Very Large Databases, pags 413–424, 1996.
[102] T. Payne, R. Singh, and K. Sycara. Rcal: A case study on semantic web
agents, proc. 1st int’l conf. autonomous agents and multiagent systems (aa-
mas 02), acm press, newyork, 2002., 2002.
[103] J. A. H. Pérez. Desarrollo de un portal web integrador de servidores de
correo electrónico basado en tecnologa xml. En Proyecto Fin De Carrera,
Escuela Politécnica Superior, Ingenierı́a Informática - Universidad Carlos
III de Madrid, 2003.
[104] D. Raggett. Clean up your web pages with html tidy. Poster 7th Interna-
tional World Wide Web Conference www.w3.org/People/Raggett/tidy/.
[105] S. Raghavan and H. Garcia-Molina. Crawling the hidden web. En Procee-
dings of the Twenty-seventh International Conference on Very Large Data-
bases, 2001.
[106] A. H. Rights and E. O. Commission. Access to electronic commerce and new
service and information technologies for older australians and people with a
disabilities. www.hreoc.gov.au/disability rights/inquiries/ecom/ecom.html.
236
[107] J. Robie, J. Lapp, and D. Schach. Xml query language (xql).
http://www.w3.org/TandS/QL/QL98/pp/xql.html.
[108] E. Rudolph, J. Grabowski, and P. Graubmann. Towards a harmonization
of UML-Sequence Diagrams and MSC. En R. Dsoulli, G. von Bochmann,
and Y. Lahav, editors, SDL’99: The Next Millennium, Proceedings of the
9th SDL Forum, Montreal, Canada, June 1999. Elsevier Science Publishers.
[109] M. d. T. y. A. S. Secretarı́a General de Asuntos Sociales. Test de accesibilidad
web. www.tawdis.net.
[110] M. P. Singh. Deep web structure. Internet Computing, 6(5):4–5, Sept.-Oct.
2002.
[111] H. Snoussi, L. Magnin, and J.-Y. Nie. Heterogeneous web data extraction
using ontology. En Third International Bi-Conference Workshop on Agent-
orienter Information Systems (AOIS-2001), Montreal (Canada, 2001.
[112] Sun. Package java.net. En JavaTM 2 Platform Standard Edition,
www.sun.com/java.
[113] S. Thompson. Haskell: The craft of functional programming. En Addison-
Wesley, ISBN 0-201-34275-8, 1996.
[114] S. Todd, F. Parr, and M. Conner. A primer for httpr. En An Overview of
the Reliable HTTP Protocol, IBM, April 2002.
[115] A. Tost. Xml document processing in java using xpath and xslt.
www.javaworld.com/javaworld/jw-09-2000/jw-0908-xpath.html.
[116] K. e. Turner. Using formal description techniques. En An Introduction to
Estelle, LOTOS, and SDL, Wiley, 1993.
[117] W3C. Hypertext markup language (html and xhtml).
www.w3.org/MarkUp/.
[118] W3C. Libwww - the w3c protocol library. En www.w3.org/Library/.
[119] W3C. Marking document changes: The ins and del elements. En Especifi-
cación de HTML 4.01, www.w3.org/T R/html4/struct/text.html#h − 9,4.
[120] W3C. Mathematical markup language (mathml). www.w3.org/TR/REC-
MathML.
[121] W3C. Policies relating to web accessibility.
http://www.w3.org/WAI/Policy/.
[122] W3C. public-qt-comments@w3.org mail archives.
lists.w3.org/Archives/Public/public-qt-comments/.
[123] W3C. Resource description framework (rdf). www.w3.org/RDF.
[124] W3C. Scalable vector graphics (svg). www.w3.org/Graphics/SVG.
[125] W3C. Synchronized multimedia integration language.
www.w3.org/AudioVideo.
[126] W3C. W3c link checker. validator.w3.org/checklink.
[127] W3C. www-xpath-comments@w3.org mail archives.
lists.w3.org/Archives/Public/www-xpath-comments/.
[128] W3C. Web content accessibility guidelines 1.0. W3C Recommendation 5-
May-1999, 1999.
237
[129] W3C. Xml path language (xpath) version 1.0. W3C Recommendation 16
November 1999, 1999.
[130] W3C. Xsl transformations (xslt) version 1.0. W3C Recommendation 16
November 1999, 1999.
[131] W3C. Document object model (dom) level 2. W3C Recommendation 13
November, 2000, 2000.
[132] W3C. Extensible markup language (xml) 1.0 (second edition). W3C Re-
commendation 6 October 2000, 2000.
[133] W3C. Del - data extraction language. W3C Note 31 October 2001, 2001.
[134] W3C. Xml schema. W3C Recommendation, 2 May 2001, 2001.
[135] W3C. Xml syntax for xquery 1.0 (xqueryx). W3C Working Draft 07 June
2001, 2001.
[136] W3C. Techniques for authoring tool accessibility guidelines 1.0. W3C Note
29-Oct-2002, 2002.
[137] W3C. User agent accessibility guidelines 1.0. W3C Recommendation 17-
Dec-2002, 2002.
[138] W3C. Xml pointer language (xpointer). W3C Working Draft 16 August
2002, 2002.
[139] W3C. Document object model (dom) level 2 html specification version 1.0.
W3C Recommendation 09 January 2003, 2003.
[140] W3C. Web ontology language (owl) reference version 1.0. En W3C Working
Draft 21 February 2003, http://www.w3.org/2001/sw/, 2003.
[141] W3C. Xml path language (xpath) 2.0. W3C Working Draft 02 May 2003,
2003.
[142] W3C. Xquery 1.0: An xml query language. W3C Working Draft 02 May
2003, 2003.
[143] W3C. Xsl transformations (xslt) version 2.0. W3C Working Draft 02 May
2003, 2003.
[144] P. Wadler. A formal model of pattern matching in XSL. Technical report,
1999.
[145] P. Wadler. Two semantics for xpath. 1999. http://www.cs.bell-labs.com/
who/wadler/topics/xml.html., 1999.
[146] D. Wahlin. Parse html pages to extract data.
www.fawcette.com/xmlmag/2002 12/online/xml wahlin 12 18 02/, De-
cember 18, 2002.
[147] L. Wall. Perl language, v5.004. En Freely available software package, June
1997, ftp://ftp.perl.com/pub/perl/src/CPAN/5.0/perl5.004.tar.gz.
[148] XML:DB. Xupdate working draft, last release september 14, 2000.
http://www.xmldb.org/xupdate/, 2000.
[149] L. S. Zettlemoyer and R. S. Amant. A visual medium for programmatic
control of interactive applications. En CHI, pags 199–206, 1999.
238

Automatizacion de Tareas en El Web

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Automatizacion de Tareas en El Web

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDAD CARLOS III DE MADRID

Departamento de Ingenierı́a Telemática

Doctorado en Tecnologı́as de las Comunicaciones

Autor: Vicente Luque Centeno

Directores: Carlos Delgado Kloos y Luis Sánchez Fernández

Realizado el acto de defensa y lectura de la Tesis el dı́a de

EL PRESIDENTE EL SECRETARIO LOS VOCALES

2. Análisis de tareas Web 53

4. Selección de tecnologı́as para la automatización de tareas en

5. XTendedPath: Lenguaje para la consulta y modificación de

6. XPlore: Lenguaje para la navegación y procesamiento de da-

7. Ejemplos desarrollados con los lenguajes propuestos 195

8. Conclusiones y trabajos futuros 221

1.1. Diferencias entre la navegación manual y la navegación au-

2.1. Diferencias entre acciones básicas explı́citas e implı́citas . . . . 57

3.1. Resumen de las tecnologı́as utilizables . . . . . . . . . . . . . . 87

4.1. Tipos de expresiones inline . . . . . . . . . . . . . . . . . . . . 103

6.1. Relación de expresiones inline con sentencias de control de flujo188

1.1. Sistema mediador . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1. Script Expect para controlar ejecución interactiva de ftp . . . 74

4.1. Entidades de un MSC . . . . . . . . . . . . . . . . . . . . . . 98

6.1. Representación de transacción HTTP . . . . . . . . . . . . . . 182

7.1. Cambio de divisas del BCE . . . . . . . . . . . . . . . . . . . 197

Quiero agradecer a todas aquellas personas que, de una un otra forma,

Actualmente, millones de usuarios en todo el mundo se ven abocados a

Esta tesis doctoral aborda el problema de la automatización de tareas

Dentro del mundo industrial en general, la automatización persigue in-

Navegación manual Navegación automática

Cuadro 1.1: Diferencias entre la navegación manual y la navegación automáti-

1.1.3. Tiempo de respuesta

1.1.4. Requisitos hardware y software

1.1.5. Adecuación de repositorios

1.1.7. Coste de implantación y adaptabilidad

1.2. Ejemplos de tareas costosas para la na-

Solicitar al Web de Hacienda el envı́o de datos fiscales de 100 perso-

Publicar en eBay un catálogo de una tienda con 500 artı́culos en su-

Componer un listado con los titulares de los principales periódicos cada

Buscar, desde una nevera conectada a Internet, la mejor oferta de leche

Mandar un SMS (Short Message Service) a una lista de teléfonos móvi-

Buscar en algún reconocido portal de ocio los restaurantes de una de-

Combinar la información de restaurantes de un portal de ocio (que indi-

1.3. Tipos de programas de navegación auto-

1.3.1. Programas de navegación genérica no adaptada

Son programas que, siendo en principio utilizables en cualquier Web, ne-

1.3.3. Programas de navegación particularizada

Son programas totalmente particularizados a las peculiaridades de un si-

Cuadro 1.2: Clasificación de programas que navegan por el Web según su

Siempre que se permita al autor un par de pequeñas licencias literarias,

Genérica no adaptada Genérica adaptada Particularizada

Cuadro 1.3: Comparaciones aclarativas de alternativas de navegación según

1.3.4. Modos de integración de aplicaciones Web

Integración de aplicaciones similares

Es normal encontrar aplicaciones de diversos servidores que, siendo

Integración de aplicaciones complementarias

Los datos semiestructurados, que aparecen detallados en el apartado 1.4.7,

Figura 1.1: Sistema mediador

La motivación de la construcción de este tipo de sistemas se encuentra

1.3.6. Asistentes de navegación Web

Para automatizar tareas en el Web se necesitan programas capaces de eli-

Figura 1.2: Comparación de navegación manual con automática

1.4. Caracterı́sticas de los datos del Web

En las últimas décadas las nuevas tecnologı́as han permitido la creación,

1.4.3. Orientación a los visualización

Iniciativas de mejora para la accesibilidad, como las publicadas por el