automatizacion de tareas en el web

UNIVERSIDAD CARLOS III DE MADRID

Departamento de Ingenierıa Telematica

Doctorado en Tecnologıas de las Comunicaciones

TESIS DOCTORAL

AUTOMATIZACION DE TAREAS

EN EL WEB:

UNA PROPUESTA BASADA EN

ESTANDARES

Autor: Vicente Luque CentenoLicenciado en Informatica

Directores: Carlos Delgado Kloos y Luis Sanchez FernandezDoctores Ingenieros de Telecomunicacion

Tribunal nombrado por el Mgfco. y Excmo. Sr. Rector de la UniversidadCarlos 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 dede en .

Calificacion:

EL PRESIDENTE EL SECRETARIO LOS VOCALES

Indice general

1. Planteamiento y objetivos 7

1.1. Diferencias entre navegacion manual y automatica . . . . . . . 9

1.1.1. Esfuerzo . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.1.2. Propension a errores . . . . . . . . . . . . . . . . . . . 11

1.1.3. Tiempo de respuesta . . . . . . . . . . . . . . . . . . . 11

1.1.4. Requisitos hardware y software . . . . . . . . . . . . . 11

1.1.5. Adecuacion de repositorios . . . . . . . . . . . . . . . . 12

1.1.6. Procesamiento . . . . . . . . . . . . . . . . . . . . . . . 12

1.1.7. Coste de implantacion y adaptabilidad . . . . . . . . . 13

1.2. Ejemplos de tareas costosas para la navegacion manual . . . . 13

1.3. Tipos de programas de navegacion automatizada . . . . . . . . 16

1.3.1. Programas de navegacion generica no adaptada . . . . 16

1.3.2. Programas de navegacion generica adaptada . . . . . . 17

1.3.3. Programas de navegacion particularizada . . . . . . . . 17

1.3.4. Modos de integracion de aplicaciones Web . . . . . . . 20

1.3.5. Sistemas mediadores . . . . . . . . . . . . . . . . . . . 22

1.3.6. Asistentes de navegacion 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. Orientacion a los visualizacion . . . . . . . . . . . . . . 26

i

1.4.4. Relevancia dependiente de la tarea . . . . . . . . . . . 29

1.4.5. Regularidad estructural . . . . . . . . . . . . . . . . . 30

1.4.6. Ausencia de semantica en el marcado . . . . . . . . . . 32

1.4.7. Niveles de estructuracion . . . . . . . . . . . . . . . . . 32

1.4.8. Distribucion de la informacion . . . . . . . . . . . . . . 35

1.4.9. Difıcil modificabilidad . . . . . . . . . . . . . . . . . . 36

1.4.10. Aportaciones de XML . . . . . . . . . . . . . . . . . . 36

1.5. Coste de la navegacion automatizada . . . . . . . . . . . . . . 39

1.5.1. Coste de desarrollo . . . . . . . . . . . . . . . . . . . . 41

1.5.2. Coste de ejecucion 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. Analisis de tareas Web 53

2.1. Acciones basicas implıcitas . . . . . . . . . . . . . . . . . . . . 57

2.1.1. Gestion de cabeceras HTTP . . . . . . . . . . . . . . . 57

2.1.2. Gestion de errores en la comunicacion con el servidor . 58

2.1.3. Reparacion interna de paginas mal construidas . . . . . 58

2.1.4. Seguimiento implıcito de enlaces . . . . . . . . . . . . . 59

2.1.5. Ejecucion de comportamientos embebidos en las paginas 60

2.1.6. Soporte para otros protocolos . . . . . . . . . . . . . . 61

2.1.7. Tratamiento adecuado de cada campo de formulariossegun su forma de rellenado . . . . . . . . . . . . . . . 61

2.1.8. Creacion de query-string a partir de un formulario relleno 62

2.2. Acciones basicas explıcitas . . . . . . . . . . . . . . . . . . . . 63

2.2.1. Extraccion de datos relevantes . . . . . . . . . . . . . . 63

2.2.2. Estructuracion 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. Subsanacion de las faltas de soporte de la plataforma de na-vegacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3. Estado de la cuestion 71

3.1. Consideraciones previas . . . . . . . . . . . . . . . . . . . . . . 71

3.2. Automatizacion de aplicaciones interactivas . . . . . . . . . . 72

3.2.1. Lenguaje Expect . . . . . . . . . . . . . . . . . . . . . 73

3.3. Web Semantico . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.4. Mecanismos de construccion de programas de navegacion au-tomatizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

3.4.1. Uso de APIs estandares . . . . . . . . . . . . . . . . . 83

3.5. Conclusiones del estado de la cuestion . . . . . . . . . . . . . . 87

3.6. Limitaciones de las tecnologıas actuales . . . . . . . . . . . . . 90

4. Seleccion de tecnologıas para la automatizacion de tareas enel 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. Creacion y destruccion dinamica de entidades . . . . . 101

4.1.8. Expresiones inline . . . . . . . . . . . . . . . . . . . . . 103

4.1.9. Descomposicion modular . . . . . . . . . . . . . . . . . 103

4.2. XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

4.2.1. Secuencias . . . . . . . . . . . . . . . . . . . . . . . . . 108

iii

4.2.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4.2.3. Operadores aritmetico-logicos y de comparacion . . . . 110

4.2.4. Ejes de navegacion . . . . . . . . . . . . . . . . . . . . 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 deXPath 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 modificacion dedocumentos 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 mas 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: extension 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 semanticas . . . . . . . . . . . . . . . 141

5.4.3. Funciones de comparacion . . . . . . . . . . . . . . . . 143

5.4.4. Funciones logicas . . . . . . . . . . . . . . . . . . . . . 144

5.4.5. Funcion TO: (generador de secuencias numericas) . . . 144

5.4.6. Funciones EVERY y SOME: (expresiones cuantificadas)145

5.4.7. Funciones eje . . . . . . . . . . . . . . . . . . . . . . . 145

5.4.8. Funcion 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. Modificacion de documentos . . . . . . . . . . . . . . . 170

6. XPlore: Lenguaje para la navegacion y procesamiento de da-tos en el Web 175

6.1. Componentes de XPlore orientados a la navegacion . . . . . . 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 ejecucion . . . . . . . . . . . . . . . . . . . . 189

6.2.5. Errores en la ejecucion . . . . . . . . . . . . . . . . . . 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. Valoracion de una cartera de acciones del Nasdaq en euros . . 196

7.2. Publicacion de un catalogo de artıculos en un Web de subastas 201

7.3. Listado de correos nuevos en un Web de correo gratuito yborrado 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 visualizacion 226

8.3.3. Desarrollo de agentes inteligentes no particularizados . 228

8.4. Gramatica EBNF del lenguaje XPlore . . . . . . . . . . . . . 229

vi

Indice de cuadros

1.1. Diferencias entre la navegacion manual y la navegacion au-tomatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2. Clasificacion de programas que navegan por el Web segun suadaptacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.3. Comparaciones aclarativas de alternativas de navegacionsegun coste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.4. Principales diferencias entre las ultimas versiones de HTML . 29

1.5. Diferencias entre caracterısticas de los datos segun su nivel deestructuracion . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

1.6. Resumen de aportaciones de XML . . . . . . . . . . . . . . . . 38

1.7. Resumen de tipos de coste de la navegacion automatizada . . 40

1.8. Resumen de medidas de robustez segun origen del fallo . . . . 45

2.1. Diferencias entre acciones basicas explıcitas e implıcitas . . . . 57

2.2. Principales cabeceras gestionadas por los clientes del protocoloHTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 basicas 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 comparacion en XTendedPath . . . . . . . . . . 143

5.4. Operadores logicos en XTendedPath . . . . . . . . . . . . . . 144

5.5. Generador de secuencias numericas en XTendedPath . . . . . 144

5.6. Expresiones cuantificadas en XTendedPath . . . . . . . . . . . 145

5.7. Semantica de la funcion C . . . . . . . . . . . . . . . . . . . . 146

5.8. Ejemplo de la aplicacion de la currificacion en la funcion C . . 146

5.9. Semantica de la funcion D . . . . . . . . . . . . . . . . . . . . 147

5.10. Semantica de la funcion DORSELF . . . . . . . . . . . . . . . 147

5.11. Semantica de la funcion P . . . . . . . . . . . . . . . . . . . . 148

5.12. Semantica de la funcion A . . . . . . . . . . . . . . . . . . . . 148

5.13. Semantica de la funcion AORSELF . . . . . . . . . . . . . . . 149

5.14. Semantica de la funcion PS . . . . . . . . . . . . . . . . . . . 149

5.15. Semantica de la funcion FS . . . . . . . . . . . . . . . . . . . 150

5.16. Semantica de la funcion PREC . . . . . . . . . . . . . . . . . 150

5.17. Semantica de la funcion FOLL . . . . . . . . . . . . . . . . . . 151

5.18. Semantica de la funcion AT . . . . . . . . . . . . . . . . . . . 151

5.19. Texto de nodos en XTendedPath . . . . . . . . . . . . . . . . 152

5.20. Semantica de la funcion 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 evaluacion 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. Semantica de la expresion INSIDE(a,b) . . . . . . . . . . . . . 164

viii

5.30. Ejemplos de uso del operador jerarquico INSIDE . . . . . . . . 165

5.31. Semantica de la expresion 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 basicos de modificacion de documentos . . . . . . 171

5.35. Ejemplos de uso de la funcion MASK . . . . . . . . . . . . . . 173

6.1. Relacion de expresiones inline con sentencias de control de flujo188

6.2. Primitivas de entrada/salida . . . . . . . . . . . . . . . . . . . 188

6.3. Primitivas de cambio de estado de ejecucion . . . . . . . . . . 189

6.4. Primitivas de errores de ejecucion . . . . . . . . . . . . . . . . 189

7.1. Estructura del documento XML con las cotizaciones del Nas-daq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

ix

Indice de figuras

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

1.2. Comparacion de navegacion manual con automatica . . . . . . 25

1.3. Regularidad en el Web . . . . . . . . . . . . . . . . . . . . . . 31

3.1. Script Expect para controlar ejecucion interactiva de ftp . . . 74

3.2. Script Expect para controlar ejecucion 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. Creacion y destruccion dinamica 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. Representacion de elementos XPointer en un fragmento XML . 116

xi

4.13. Expresion XPath reformulada con el operador if . . . . . . . . 120

4.14. Expresion XPath reformulada con el operador every . . . . . . 120

5.1. Expresion XPath 2.0 que calcula importe de ventas con sub-totales parciales . . . . . . . . . . . . . . . . . . . . . . . . . . 127

5.2. Pseudocodigo basado en variables que calcula subtotales . . . 127

5.3. Pseudocodigo basado en funciones que calcula subtotales . . . 128

5.4. Ejemplo de expresion 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. Restriccion que debe cumplir todo rango en XTendedPath . . 160

5.13. Restriccion de rangos reescrita con operadores jerarquicos . . . 165

5.14. Algunas funciones de orden superior definidas en XTendedPath168

5.15. Ejemplo de expresion lambda definida en Java . . . . . . . . . 170

5.16. Ejemplo de expresiones de rellenado de formulario . . . . . . . 171

5.17. Expresion XPath equivalente asource//address[addressee[text() =name]] . . . . . . . . . . . 173

6.1. Representacion de transaccion HTTP . . . . . . . . . . . . . . 182

6.2. Ejemplo de ejecucion temporizada . . . . . . . . . . . . . . . . 183

6.3. Ejemplo de ejecucion reiterada . . . . . . . . . . . . . . . . . . 184

6.4. Ejemplo de ejecucion secuencial . . . . . . . . . . . . . . . . . 184

6.5. Ejemplo de ejecucion concurrente . . . . . . . . . . . . . . . . 185

6.6. Ejemplo de combinacion de servicios . . . . . . . . . . . . . . 185

6.7. Representacion de un bucle y una sentencia condicional ani-dados en XPlore notacion MSC . . . . . . . . . . . . . . . . . 187

xii

6.8. Ejemplo de sentencias anidadas en notacion compacta de XPlore187

6.9. Representacion de llamadas a funciones en XPlore notacionMSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

6.10. Ejemplo de definicion de funcion Identif en XPlore notacioncompacta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

6.11. Ejemplo de llamada de funcion en XPlore . . . . . . . . . . . 191

6.12. Ejemplo de llamada a clases Java desde XPlore notacion com-pacta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

6.13. Representacion de llamada a programa externo . . . . . . . . . 192

6.14. Representacion de operador de concurrencia . . . . . . . . . . 194

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

7.2. MSC grafico del programa Nasdaq . . . . . . . . . . . . . . . . 198

7.3. Programa Nasdaq en XPlore notacion MSC . . . . . . . . . . 199

7.4. Programa Nasdaq en XPlore notacion compacta . . . . . . . . 200

7.5. MSC grafico del programa Aucland . . . . . . . . . . . . . . . 202

7.6. Programa Aucland en XPlore notacion MSC . . . . . . . . . . 203

7.7. Campos del formulario de publicacion de Aucland . . . . . . . 204

7.8. Programa Aucland en XPlore notacion compacta . . . . . . . 205

7.9. Programa Aucland en XPlore notacion compacta (2) . . . . . 206

7.10. Programa Aucland en XPlore notacion compacta (3) . . . . . 207

7.11. Bandeja de entrada del correo de Yahoo! . . . . . . . . . . . . 208

7.12. MSC grafico del programa YahooMail . . . . . . . . . . . . . . 210

7.13. MSC grafico del programa YahooMail (2) . . . . . . . . . . . . 211

7.14. Programa YahooMail en XPlore notacion MSC . . . . . . . . . 212

7.15. Programa YahooMail en XPlore notacion MSC (2) . . . . . . 213

7.16. Programa YahooMail en XPlore notacion compacta . . . . . . 214

7.17. Programa YahooMail en XPlore notacion compacta (2) . . . . 215

xiii

Agradecimientos

Quiero agradecer a todas aquellas personas que, de una un otra forma,han hecho posible este trabajo. Agradezco a mis padres el haber depositadosu confianza en mı y haberme permitido seguir adelante y haberme apoyadoen todo momento. A mis directores de tesis, quiero agradecerles los buenosy consejos y las sabias preguntas que me hicieron buscar las respuestas paraelaborar este trabajo. A mis companeros del Departamento de IngenierıaTelematica, por toda la colaboracion recibida y por todo lo que de ellos heaprendido en estos anos de doctorado. A mis antiguos companeros de laFacultad de Informatica, de donde tantısimas cosas aprendı. A mis amigos yamigas por haber estado ahı todo este tiempo.

1

Resumen

Actualmente, millones de usuarios en todo el mundo se ven abocados arealizar cada dıa tareas en Internet, manejando de forma repetida un con-junto cada vez mayor de remotas aplicaciones que se encuentran accesiblesen el Web. Para todas esas labores, la gran mayorıa de esas personas ape-nas cuenta con la unica ayuda de los browsers, lo cual confiere al procesode navegacion una alta necesidad de interaccion por parte del usuario, en loque habitualmente se conoce como navegacion manual. Sin embargo, ello amenudo implica un esfuerzo demasiado elevado para muchas personas, es-pecialmente cuando el volumen de datos es grande o la complejidad de sumanejo requiere muchas interacciones con el browser.

Desarrollar programas que naveguen automatizadamente por el Web, ma-nipulando inteligentemente la informacion disponible en Internet es una ne-cesidad cada vez mas demandada en numerosos entornos. Sin embargo, eldesarrollo de este tipo de programas tradicionalmente se ha afrontado contecnicas que implican un alto coste de desarrollo y un elevado coste de man-tenimiento, ademas de tener una vida demasiado corta y ser muy sensiblesa pequenas modificaciones en las paginas accedidas. En este trabajo se pro-ponen nuevas tecnicas basadas en estandares para reducir el coste de estosdesarrollos y mejorar la estabilidad de estos programas.

3

Abstract

Nowadays, millions of people around the world have to daily perform taskson Internet, repeatedly managing an increasing amount of Web enabled ap-plications. For many of these tasks, most people use browsers, by manuallyand mecanically interacting with screens of data retrieved from remote com-puters. However, this implies too much effort for too many people, speciallywhen the amount of data is big or those data require complex managementswith 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 severalenterprises. However these programs have traditionally had a large deve-lopment and maintenance cost, they have had very short lives and theirbehaviour when minor changes affect pages is not desirable. This documentpresents several standards-based new techniques for reducing these costs andmaking these programs more stable.

5

Capıtulo 1

Planteamiento y objetivos

Esta tesis doctoral aborda el problema de la automatizacion de tareasen el Web. En cualquier automatizacion, como por ejemplo cualquiera de lasllevadas a cabo en un complejo industrial, se persigue delegar en las maquinasla realizacion de trabajos, de forma que estos sean llevados a cabo con lamınima intervencion humana y mecanica 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 serviciosWeb, que comprenden, por una parte, a los servidores de informacion alma-cenada en simples paginas Web, y por otra, a las aplicaciones remotamenteaccesibles desde el Web para muy diversos propositos, se puede acceder atraves de una gran variedad de paginas Web. Gran cantidad de esa informa-cion se encuentra muchas veces almacenada en bases de datos que, siendoaccesibles mediante interfaces especıficamente disenadas para el Web, se en-cuentran sin embargo a veces sin explorar conforme a las necesidades particu-lares de muchos usuarios. Mucha informacion, ciertamente, pero en especialmuchas aplicaciones accesibles remotamente desde el Web, acaban quedandoinfrautilizadas para muchos usuarios en un mundo donde los browsers se hanquedado ciertamente limitados como herramientas de trabajo, ya que care-cen de cualquier tipo de proposito mas alla que el de la mera presentacionpaginada de datos al usuario y la recogida de datos del usuario medianteformularios.

La heterogeneidad del Web actual es inmensa. Por un lado, hay innume-rables formas posibles de organizar y estructurar los contenidos dentro decada pagina mediante distintas combinaciones de etiquetas de marcado, nosolo HTML sino tambien XML. Por otro lado, existen multiples variantespara distribuir la informacion entre las distintas paginas, ası como multiples

7

maneras de dejar estas enlazadas entre sı. Toda esta heterogeneidad dificultaenormemente la integracion de datos obtenidos de distintos servidores para sucombinacion o gestion unificada. La integracion de datos de diversas fuentes,bien para la obtencion de datos elaborados con valor anadido (sindicacion decontenidos), bien como cadena de suministro (aplicaciones que deban pasar-se datos de unas a otras), es un area que actualmente esta demandando uncreciente interes, habida cuenta de la necesidad de automatizar el manejo degrandes volumenes de datos en el Web.

En ocasiones, los usuarios se encuentran con la tarea de tener que rellenarmuchas veces un conjunto conocido de formularios o seguir de forma repeti-tiva un mismo conjunto de enlaces para poder conseguir la informacion quedesean o para poder manejar intensivamente aplicaciones remotamente pormedio del Web. Estos usuarios acaban invirtiendo para ello gran cantidadde tiempo en labores que, dado su automatismo, serıa muchas veces posibleque se realizaran autononamente por un ordenador. Es habitual que muchasde estas aplicaciones del Web ofrezcan interfaces para realizar transaccionessimples, pero no que dispongan de interfaces para ofrecer multiples transac-ciones que puedan ser procesadas por lotes. Sin embargo, los usuarios nodisponen hoy en dıa de otra herramienta mas alla del browser, por lo queacaban debiendo aprobar con un click de raton cada enlace que desean se-guir una y otra vez, transaccion a transaccion, repetidamente cada vez quemanejan una de estas aplicaciones accesibles desde el Web.

Tradicionalmente, uno de los grandes problemas del Web estriba en laincapacidad de manejar en el grandes volumenes de informacion de formaefectiva, conforme a los deseos de los usuarios. Los grandes buscadores ape-nas resuelven una pequena parte del problema de la busqueda de informacion.Aunque son capaces de listar los documentos del Web en los que se sabe queaparecen los terminos de busqueda, 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, semanticao funcionalidad interna con el fin de buscar allı los datos que le interesan. Sinduda, las necesidades de los usuarios son mucho mas complejas que aquellasa las que puede dar respuesta un simple buscador, ya que, una vez delantede la pagina en la que debe empezar a trabajar, debe ser el usuario quien in-dique por donde navegar, construyendo ası el camino que le lleve a conseguirsus objetivos.

8

1.1. Diferencias entre navegacion manual y

automatica

Dentro del mundo industrial en general, la automatizacion persigue in-crementar la productividad de las personas, minimizando los errores propiosde la naturaleza humana y mejorando ası la eficiencia en la realizacion detrabajos y en la optimizacion de los recursos involucrados. Con la automa-tizacion de tareas en el Web se persiguen esos mismos objetivos aplicadosen la realizacion del cada vez mayor numero de tareas que pueden realizarsea traves del Web. Al igual que en cualquier empresa, el objetivo principalde la automatizacion de tareas en el Web es ahorrar tiempo y esfuerzo alas personas. En el caso del Web, los beneficios de la automatizacion seranmas patentes en aquellas tareas que necesiten procesar grandes volumenesde informacion o que deban ser frecuentemente ejecutadas.

Trasladando a las maquinas las actividades mas automatizables y rutina-rias, se permite ahorrar esfuerzo a las personas. Gracias a ello las personaspueden centrarse en otras actividades, habitualmente mas productivas, crea-tivas y probablemente mas adecuadas para sus trabajos y sus preparaciones.Sin duda, la productividad y creatividad humana se ve muchas veces ale-targada por las tareas mas rutinarias de navegacion en el Web. El hecho detener que realizar una y otra vez los mismos pasos dıa a dıa delante de unbrowser, siguiendo los mismos enlaces y rellenando una y otra vez los mis-mos formularios, acaba siendo una tarea que requiere demasiado esfuerzo ydedicacion para muchas personas. Ejemplos de tareas que pueden requerirser realizadas frecuentemente, son las que se pueden llevar a cabo con aplica-ciones como las bancarias (comprobaciones de saldo, transferencias, listadode movimientos, operaciones de bolsa, subastas de depositos, fondos de in-version ...), de subastas (publicacion de artıculos para vender, busqueda ycomparacion de artıculos para pujar, insercion de pujas, gestion de avisos,evaluacion de transacciones, ...), de compra-venta (busqueda y comparacionde artıculos, realizacion de pedidos y de pagos, ...), de reserva de billetes deavion o de tren, habitaciones de hotel, entradas a espectaculos, envıo de men-sajes, ası como un largo etcetera. Estas aplicaciones se encuentran cada vezmas frecuentemente, tanto en las intranets de las empresas, como accesiblesa todo el mundo en un gran numero 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 cuantopara llevarlas a cabo, las acciones mecanicas 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 navegacion manual basada en browsers,gracias a la automatizacion de tareas en el Web, grandes volumenes de in-formacion distribuida en multiples bases de datos accesibles desde el Webpueden ser procesados conforme a los intereses de los usuarios requiriendode ellos un esfuerzo mınimo. Las principales diferencias entre la navegacionmanual y la automatica, resumidas en la tabla 1.1, aparecen detalladas acontinuacion.

Navegacion manual Navegacion automatica

Intervencion Humana Ordenador

Accion Mecanica Programada

Esfuerzo De navegacion De programacion

Errores De navegacion De programacion

Tiempo de respuesta Significativo Infimo

Requisitos Browser Conexion

Repositorios No programables Programables

Procesamiento Calculo mental Automatizable

Volumen de datos Limitado Enorme

Implantacion Factible Costosa

Adaptabilidad ante cambios Tolerable Costosa

Cuadro 1.1: Diferencias entre la navegacion manual y la navegacion automati-ca

1.1.1. Esfuerzo

El Web actual esta disenado para ser navegado de forma interactiva, conel usuario proporcionando mecanicamente una a una sus instrucciones detrasde la pantalla del ordenador, haciendo click en cada enlace que desea seguir.Ello supone en muchas ocasiones un serio coste de recursos humanos, estoes, 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 opcion, una tarea automatizada por un programa capaz denavegar en lugar del usuario, emulando el comportamiento de la actuacionconjunta de este y del navegador, puede reducir significativamente ese costede navegacion.

10

1.1.2. Propension a errores

La interaccion mecanica de las personas en la navegacion manual aumentaen gran medida la propension a cometer errores durante la ejecucion de latarea. Este riesgo se hace mas probable cuando el conjunto de datos que debeser manipulado es voluminoso. Por el contrario, un programa que navegueautomaticamente por el Web puede manipular eficiente y adecuadamentegrandes volumenes de informacion, incluso a pesar de que esta se encuentradistribuida en varias fuentes de datos.

1.1.3. Tiempo de respuesta

Pese a que el rendimiento de una aplicacion Web esta principalmentecondicionado por el tiempo de respuesta del servidor y de las conexionesque comunican a este con el cliente, lo cierto es que, las personas, cuandonavegamos delante de un browser en el que debemos introducir interactiva-mente nuestras ordenes, tenemos unos tiempos de respuesta significativos.Ademas, y no menos importante, las personas somos facilmente distraıblesde nuestros cometidos, como puede ocurrir con la aparicion de enlaces queinesperadamente reclamen nuestra atencion por un tema que nos interese yno tenga nada que ver con la tarea que nos estaba ocupando. Incluso en unaescena en la que un operador se encuentre altamente concentrado en la rea-lizacion de una tarea con un browser, el simple hecho de tener que activarmecanicamente unos dispositivos de introduccion de datos, como el teclado yel raton, estando a la vez pendiente de varias ventanas abiertas en la pantallaque reclaman simultaneamente la atencion del usuario, supone unos tiemposde retraso que, aunque aceptables para unas pocas transacciones, resultanciertamente frustrantes cuando el numero de acciones mecanicas a ejecutaracaba siendo elevado, especialmente debido a la imposibilidad de ordenartrabajos por lotes en el Web.

1.1.4. Requisitos hardware y software

Sin duda, uno de los grandes problemas de los browsers es que, ademasde la intervencion mecanica necesaria para poder proceder al seguimiento deenlaces, requieren de hardware y software especializado, de forma que granparte del Web ahora mismo esta pensada exclusivamente para ser accesi-ble desde ordenadores personales (PC), con unas resoluciones de pantalladeterminadas, y con unos requisitos de software especıficos muy concretos.

11

Sin embargo, la proliferacion de un cada vez mayor numero de dispositivoselectronicos conectados a la red, como algunas cabinas publicas de acceso aInternet, los dispositivos inalambricos, u otros pequenos electrodomesticos,esta aumentando el numero de dispositivos con reducidas capacidades de vi-sualizacion de datos, que, sin embargo, no dejan de ser capaces de trataradecuadamente los datos de la Red. Estos dispositivos podrıan facilmenteconectarse a la red para automatizar tareas en el Web, al igual que lo hacecualquier otro ordenador, conforme a lo propuesto en [42], prescindiendo, altratar automaticamente las paginas sin necesitar que el usuario las visualicepara proporcionar interactivamente sus instrucciones sobre las mismas, de lascapacidades de visualizacion que sı poseen los ordenadores de sobremesa enlos que se ejecutan los browsers. Es decir, la navegacion manual esta practi-camente limitada a un conjunto muy particular de dispositivos (aquellos quetengan instalado el browser contemplado por el sitio Web), mientras que lanavegacion automatica, al carecer de esas restricciones, puede llevarse a ca-bo desde un numero mucho mayor de dispositivos de acceso, como neveras,asistentes personales, telefonos moviles, set-top boxes ...

1.1.5. Adecuacion de repositorios

Otro de los problemas con los que se encuentran las personas que navegancon browsers es que la forma de recolectar los datos relevantes que van en-contrando esta basada en metodos poco automatizables, e inadecuados paragrandes volumenes de datos, como la memorizacion, el apuntar los datos enun papel, guardar toda la pagina a fichero, imprimirla para analizarla frentea otras personas en una reunion, o, quiza en el mejor de los casos, el simplecopiar y pegar en la ventana de otra aplicacion. Sin embargo, ni el papel,ni la memoria humana, ni una ventana abierta de un editor de texto sonrepositorios adecuados para almacenar los datos relevantes que se van extra-yendo de las paginas cuando el volumen de datos empieza a ser considerable.Por el contrario, desde el punto de vista de la automatizacion de tareas, esdeseable la utilizacion de repositorios de datos accesibles desde programas deordenador, como variables de memoria, ficheros con algun tipo de estructuraconocida 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 losdatos del Web es realmente sencillo, (aunque ciertamente es posible que en

12

el futuro estos procesamientos se puedan volver cada vez mas complejos), locierto es que el volumen de datos que muchas veces hay que manejar en elWeb es demasiado alto como para ser manejado mentalmente por personasdelante de un navegador. Es facil encontrar la version mas barata de un libroen una pagina que tenga pocos ejemplares, pero ya no lo es tanto cuando sedesean comparar un gran numero de listados de tiendas, cada una con suspropios precios, de forma que haya que mezclar los resultados de todas ellas,y calcular el gasto final incluyendo gastos de envıo, descuentos especialeso promocionales, o eliminando resultados repetidos. Realizar este tipo detareas es algo que puede facilmente ser automatizado por un programa capazde acceder a los datos involucrados si estos se encuentran convenientementealmacenados en un repositorio adecuado de datos como los mencionados enel punto anterior.

1.1.7. Coste de implantacion y adaptabilidad

Todas las ventajas de la navegacion automatica frente a la navegacionmanual tienen un coste. Desarrollar aplicaciones que automaticen las tareasde navegacion en el Web es costoso. Apenas existen tecnicas especıficamenteorientadas a la reduccion del coste de implantacion 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 paginas involucradas enuna tarea puede acabar requiriendo una ardua labor de mantenimiento. Porel contrario, las paginas cuya estructura es frecuentemente actualizada, noplantean excesivos problemas a las personas que las navegan manualmentecon browsers, pues el comportamiento humano es facilmente adaptable a lasnuevas circunstancias, algo que no puede decirse normalmente del compor-tamiento de los programas de ordenador. En el apartado 1.5 aparecen masdetallados estos costes.

1.2. Ejemplos de tareas costosas para la na-

vegacion manual

Segun aumentan las posibilidades de realizar nuevas acciones en un mundocada vez mas interconectado, resulta cada vez menos difıcil encontrar tareascapaces de absorber horas de trabajo a sus usuarios o en las que se justifiquepoco la conveniencia de que estos deban estar presentes en todo momentoante la pantalla del ordenador. A continuacion 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 enun unico paso, pero que debe ser rellenado y enviado una vez para ca-da persona, introduciendo datos personales y fiscales de la declaracionanterior.

Publicar en eBay un catalogo de una tienda con 500 artıculos en su-bastas. Actualmente cada artıculo requiere el rellenado del orden deunos 8 o 9 formularios, que aparecen en secuencia y que empiezan porla seleccion del tipo de subasta y categorıa en la que se desea publicar,continuan preguntando por informacion especializada del artıculo basa-da en las selecciones anteriores, y acaban solicitando una confirmacionde que todo esta conforme para el usuario. En algunos de los pasos ca-be la posibilidad de que aparezcan variantes en la secuencia, como porejemplo 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 necesariorellenar un formulario aparte para enviar la foto al servidor. Ademas,resulta deseable realizar una serie de mınimas comprobaciones en cadapaso, como el cercioramiento de que las tarifas que se pretenden cobrarson las que el usuario espera, o que se confirme que cada artıculo hasido 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 delos formularios necesarios para la publicacion de un artıculo, contem-plando las cuestiones mencionadas, de forma que esa secuencia figuredentro de un bucle que itere sobre los artıculos que se desea publicar,presumiblemente leıdos de algun repositorio definido por el usuario.

Buscar con Google cada semana las paginas de cierto tema, mantenien-do para ello una lista acumulada de paginas ya conocidas que se res-tara a los resultados obtenidos. De esta forma se presentara al usuariouna lista que contenga exclusivamente las direcciones hasta el momentono conocidas por el usuario y que los robots de Google, en su continuodevenir por la red, van descubriendo. En todo caso, los resultados quese analicen de Google no deben comprender solo la primera pagina deresultados, sino que debe inspeccionar todas independientemente de lapaginacion, filtrando de los resultados encontrados aquellos que apa-rezcan en la lista de conocidos por el usuario. Dicha lista debera residiren un fichero en el ordenador del usuario, capaz de ser actualizado por

14

este, pues Google, en su version actual, no permite albergar este tipode informacion personalizada para cada usuario.

Componer un listado con los titulares de los principales periodicos cadamanana. Los resultados podrıan ser visualizados en una television co-nectada a Internet mediante una set-top box que recoja los titulares devarias fuentes de noticias del Web y las presente agrupadas al usuariopor secciones o segun sus preferencias.

Buscar, desde una nevera conectada a Internet, la mejor oferta de lechefresca en varias tiendas, incluyendo, a ser posible, no solo la busquedaen tiendas habilitadas para neveras, sino en cualquier tienda que vendaa domicilio.

Ampliar la tarea anterior para que busque la tienda que pide menosdinero por la entrega a domicilio de una cesta de la compra con variosartıculos, incluyendo los gastos de envıo y descuentos aplicables de cadatienda.

Chequear si, entre los mensajes en varias cuentas de correo Web (devarios portales) hay algunos que cumplan ciertos requisitos, como remi-tentes especiales o fechas o asuntos determinados. A cada uno de esosmensajes, aplicarles ciertas acciones, como extraer de ellos los cuerposde los mensajes para ser leıdos, cambiarlos de carpeta, responderlos,reenviarlos a alguna direccion o simplemente borrarlos.

Mandar un SMS (Short Message Service) a una lista de telefonos movi-les usando los formularios que para ello ponen accesibles algunos por-tales del Web, a ser posible eliminando las restricciones que imponenestos portales sobre tamano de los mensajes y numero de mensajesenviados por unidad de tiempo.

Buscar en algun reconocido portal de ocio los restaurantes de una de-terminada zona geografica, seleccionar aquellos que sirvan comida adomicilio y comparar sus ofertas.

Combinar la informacion de restaurantes de un portal de ocio (que indi-que si aceptan tarjeta de credito) con el callejero de la ciudad ofrecidopor otro portal para obtener un listado de restaurantes que aceptentarjeta de credito que esten cerca de la salida del cine al que voy a iresta tarde.

15

La mayorıa de los ejemplos anteriores esta pensada para automatizar unelevado volumen de datos en una aplicacion accesible desde el Web, comopuede ser una aplicacion de recoleccion de datos de la Administracion, unbuscador, una aplicacion de publicacion de subastas, una aplicacion de envıode mensajes a moviles o una que gestione cuentas de correo electronico desdeel Web. En algunos casos, en lugar de acceder a una aplicacion, la tareadebe acceder simplemente a varias paginas de estructura conocida pero deinformacion variante, con el fin de combinar la informacion dispersa en esasfuentes de la forma deseada por el usuario.

1.3. Tipos de programas de navegacion auto-

matizada

Para conseguir automatizar tareas en el Web se necesita disponer de apli-caciones que automaticen la navegacion de los usuarios en paginas y apli-caciones en el Web, de forma que sustituyan al usuario siguiendo algunasecuencia de enlaces que deban seguirse y formularios que deban rellenarsepara poder realizar la tarea.

Los programas que pueden navegar en el Web pueden clasificarse segunsu grado de particularizacion a las paginas Web que se espera que visiten.Dicho criterio permite clasificar estos programas en tres grandes grupos:

1.3.1. Programas de navegacion generica no adaptada

Son programas que no estan particularizados a ningun sitio Web y que,por lo tanto, pueden ser usados en cualquiera de ellos. Normalmente se dedi-can a solicitar interactivamente al usuario informacion acerca de que enlacesseguir (browsers), o bien a seguir todos los enlaces de un sitio Web pararealizar una tarea muy sencilla, normalmente identica en cada una de laspaginas encontradas, como por ejemplo, la indexacion por palabras de cadauna de sus paginas (robots de buscadores), la comprobacion de enlaces ro-tos [126], la descarga completa de sitios Web [20] o el aviso de que ciertaspaginas han sido actualizadas recientemente [15]. Dado que estos programascarecen normalmente de un contexto semantico (ver tabla 1.6) y por lo tanto,son incapaces de particularizar su comportamiento al significado semanticode los datos de las paginas visitadas, solo pueden ser usados en tareas muysencillas, sin posibilidades de poder navegar de forma eficiente por el deepWeb [110, 105].

16

1.3.2. Programas de navegacion generica adaptada

Son programas que, siendo en principio utilizables en cualquier Web, ne-cesitan meta-informacion acerca del mismo para poder navegarlo de formaadaptada a sus caracterısticas particulares. Normalmente, suelen analizar pri-mero la meta-informacion, expresada en terminos declarativos, del sitio Webpara decidir mientras navegan que enlaces tienen la mayor probabilidad dellevar a la consecucion de unos objetivos preestablecidos. El Web Semantico[87] del W3C es un prometedor exponente de esta forma de automatizacionde tareas en el Web.

1.3.3. Programas de navegacion particularizada

Son programas totalmente particularizados a las peculiaridades de un si-tio Web concreto, por lo que, en principio, no son reutilizables en otros sitiosWeb. Estos programas, comunmente denominados wrappers o codigo envol-torio [70], presentan importantes ventajas, ya que no necesitan ningun tipode metadatos y pueden estar completamente adaptados a las caracterısticasdel sitio Web visitado. Mediante el seguimiento, particularizado al sitio Web,de enlaces pre-programados estaticamente segun la semantica que el progra-mador implıcitamente refleja en el codigo de estos programas, practicamentecasi cualquier tarea concebida por el usuario puede ser desarrollada de formaeficiente, teniendo ademas en cuenta sus preferencias acerca de la forma en laque desea que se lleve a cabo la tarea. Por ejemplo, para borrar el correo spamen la bandeja de entrada de una cuenta de correo Web como el de Yahoo!, unusuario puede querer marcar los correos de ciertos dominios que el consideraspam, para despues pulsar en el boton de borrado, mientras que otro usuariopuede preferir seleccionar los mensajes con determinados asuntos moviendo-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 laestructura de las paginas accedidas puede provocar un malfuncionamientodel programa).

En la tabla 1.2 aparecen resumidas las principales caracterısticas de losdistintos tipos de programas que navegan por el Web segun su grado deadaptacion a las paginas de esos sitios Web.

17

Generica no adaptada Generica adaptada Particularizada

Ejemplos Browsers, robots Web Semantico Wrappers

Algoritmo Usuario, fuerza bruta Guiado por objetivos Pre-programado

Contexto semantico Nulo Metadatos declarativos Implıcito en programacion

Construccion de caminos Usuario, todos Dinamica Estatica, pero flexible

Implantabilidad Facil Incipiente, a largo plazo Conocida y factible

Mantenimiento Infimo Facil (declarativo) Costoso (programacion)

Aplicable a cualquier Web Sı Si tiene metadatos No

Automatizacion de tareas MUY simples No complejas Sı

Cuadro 1.2: Clasificacion de programas que navegan por el Web segun suadaptacion

Comparaciones de costes

Siempre que se permita al autor un par de pequenas licencias literarias,cabrıa quiza comparar los distintos tipos de programas orientados a la nave-gacion en el Web con soluciones medicas que intentan paliar una enfermedaden una persona y con la navegacion marina.

Los programas genericos no adaptados podrıan asimilarse a los trata-mientos medicos mas sencillos, sin receta y con un bajo coste, y que todo elmundo puede usar, como el hecho de beber agua, ingerir te verde o inclusotomar una aspirina. Son estas soluciones validas y facilmente aplicables pa-ra problemas habitualmente comunes de encontrar. Los programas genericosadaptados podrıan quiza asimilarse a una fisioterapia o a un tratamientomedicinal con receta medica. Este tipo de soluciones esta enfocada a unafinalidad mas especıfica que los tratamientos sencillos son incapaces de resol-ver por sı mismos, por lo que se requiere normalmente la ayuda de alguienexterno capaz de facilitar la solucion al usuario. Finalmente, los programasno genericos, esto es, los completamente particularizados, pueden ser com-parables a una operacion de cirugıa. Este tipo de operaciones tiene un costesensiblemente superior al de otras alternativas, pero es realmente efectivocuando el problema del usuario no puede ser solucionado con las tecnicasanteriores.

De la misma forma, puede hacerse un sımil de la navegacion en el deepWeb con los viajes en el mar. Una navegacion basada en browsers puede serasimilada con un buzo, capaz de sumergirse con autonomıa propia por cual-quier recoveco marino por estrecho que sea, pero incapaz de recorrer grandesdistancias ni de llegar a grandes profundidades (ademas 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 eldeep Web rellenando formularios o siguiendo enlaces de profundidad poten-cialmente ilimitada. La gran diversidad de robots segun su complejidad esasimilable a la gran diversidad de barcos existentes, desde pequenas balsasa transatlanticos, segun su complejidad. En todos los casos, su navegacionesta centrada en la parte mas superficial del mar y nunca se sumergen enel fondo del deep Web. La navegacion con alternativas genericas adaptadascomo la del Web Semantico es asimilable a varias alternativas, segun el pun-to de vista de sus promotores o sus detractores. Para los primeros, el WebSemantico es comparable a un enorme submarino tripulado, capaz de auto-matizar cualquier tarea a cualquier distancia y profundidad y con capacidadautonoma (programacion de agentes y de inteligencia artificial) para tomardecisiones durante la navegacion, pero incapaz de introducirse por los recove-cos en los que no cabe, es decir, incapaz de navegar sin sus correspondientesmetadatos. Para sus detractores, sin embargo, el Web Semantico promete de-masiadas cosas irrealizables aun hoy en dıa, y es en realidad mas asimilable aluso de una red de transitables tuneles construidos debajo del fondo del mar(como el Eurotunel que atraviesa el canal de la Mancha). En ambos casos serequiere la construccion de rutas de navegacion (por las que quepa el subma-rino) o transitables tuneles adaptados al fondo marino, que sean asimilablesa los metadatos adaptados al sitio Web al que describen. Estos metadatosactuan como guıas de la navegacion, indicando por donde navegar y pordonde no y cual es el camino que hay que tomar en cada bifurcacion parallegar a un destino. Finalmente, cuando se necesita recorrer grandes distan-cias, acceder a grandes profundidades e introducirse por pequenos recovecosen los que no cabe un enorme submarino, y no se dispone de metadatos, lohabitual es recurrir a soluciones como los pequenos batiscafos no tripuladosy teledirigidos, costosos, pero capaces de recorrer cualquier ruta. La tabla 1.3contiene un resumen de estas comparaciones aclarativas.

Generica no adaptada Generica adaptada Particularizada

Ejemplos Browsers, robots Web Semantico Wrappers

Medicina Te verde, aspirinas, ... Medicacion con receta, fisioterapia, ... Cirugıa

Deep Web Buzo, barcos Red de tuneles bajo el mar, submarino Batiscafo no tripulado

Coste Bajo Medio/alto Alto

Cuadro 1.3: Comparaciones aclarativas de alternativas de navegacion seguncoste

19

Las tareas que los usuarios necesitan automatizar en el Web pueden lle-gar a ser bastante complejas. Solo aquellos programas capaces de manipularadecuadamente los datos que aparecen en los documentos visitados puedenservir al usuario para automatizar sus tareas en el Web. Dado que la mayorıade las tareas realizables por las aplicaciones de navegacion generica no adap-tada son demasiado simples y que el Web Semantico es aun una tecnologıarealmente incipiente, la principal alternativa utilizable actualmente consisteen la creacion de programas de navegacion particularizada a los sitios Web.

La navegacion basada en wrappers ha sido sin duda la que mas apor-taciones ha realizado ultimamente a la automatizacion de complejas tareasen el Web, en donde ha demostrado en repetidas ocasiones ser aplicable deforma fructıfera [67]. Si bien los contextos semanticos (ver tabla 1.6) basa-dos en metadatos declarativos pueden aun tardar tiempo en ser efectivos,es constatable que los contextos semanticos embebidos en las sentencias deprogramacion que forman parte del codigo de un wrapper son una podero-sa arma de automatizacion. Por otro lado, si bien la construccion dinamicade caminos de navegacion guiados por el cumplimiento de objetivos resultaimpracticable sin la existencia de metadatos, la construccion estatica, pe-ro flexible para ganar robustez, de caminos pre-programados de navegaciondonde no sea necesaria la existencia de metadatos que indiquen los enlacesque se deben seguir, puede servir como base para la automatizacion de tareasque manejen aplicaciones accesibles desde el Web.

1.3.4. Modos de integracion de aplicaciones Web

Cuando se desea automatizar tareas que involucran a mas de una aplica-cion Web, dos modos de integrarlas suelen ser los mas empleados.

Integracion de aplicaciones similares

Es normal encontrar aplicaciones de diversos servidores que, siendosemanticamente similares porque estan concebidos para fines parecidos, desdeel punto de vista del marcado de sus paginas, son estructuralmente distintas.Normalmente, se trata de aplicaciones que, aunque pueden tener pequenasdiferencias entre sı, ofrecen una funcionalidad similar al usuario, cada unaaccesible desde su propio servidor. Es por ello que el usuario puede tenerque conectarse simultaneamente a varias de ellas a la vez, escogiendo sobrela 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 electronico o con varias cuentas bancarias, personas que manejenvarios sitios de subastas en el Web o que quieran simplemente buscar lasmejores ofertas en varias tiendas suelen tener que abrir varias ventanas, unapara cada una de estas aplicaciones, y operar con todas ellas a la vez.

Integracion de aplicaciones complementarias

Por otro lado, tambien resulta frecuente encontrarse con tareas que invo-lucran el intercambio de datos entre varias aplicaciones construidas de formaindependiente unas de otras, pero que no esten integradas convenientemente,por lo que la unica forma de manejarlas sea manipulando los formularios pro-pios de acceso a la herramienta. Ante esta situacion, los usuarios tıpicamentedeben conectarse a alguna de ellas y, tras analizar los datos obtenidos de esta,enviar esos mismos datos, quiza con alguna variacion, a otra herramienta, re-llenando con el teclado y el raton su correspondiente formulario. Eso sueleocurrir en entornos donde, por ejemplo, una aplicacion se dedica a recogerpeticiones de muchos usuarios y, antes de procesarlas convenientemente, unsupervisor debe darles el visto bueno, reinsertando esos datos en otra aplica-cion junto con alguna informacion adicional. En ese caso, el supervisor, si lasherramientas no se han integrado convenientemente, puede tener que estarcopiando los datos de una ventana de la primera herramienta y pegandolosen una ventana de la segunda herramienta. Otro ejemplo distinto, pero conel mismo planteamiento operativo, se puede encontrar en personas que debanenviar por alguna aplicacion Web de correo electronico determinados frag-mentos de documentos que una primera aplicacion les pueda estar mostrandoen otra ventana. Sin duda, las tareas realizables pueden llegar a ser cierta-mente impensables para los disenadores de las aplicaciones Web accedidas,pues son los usuarios quienes mejor definen la forma en la que desean hacersus tareas. Por ejemplo, una persona puede desear responder desde el correoque tiene en Yahoo! los correos electronicos que le lleguen a su cuenta decorreo en Hotmail, porque no desee responder directamente desde allı. Eneste caso, los formularios de Yahoo! deberan recibir informacion, no solo delusuario, sino de la proporcionada por Hotmail, de la misma forma en la queun usuario que realizara esa tarea hubiera copiado y pegado ese texto desdela ventana de una aplicacion 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 paginasHTML disponibles dentro de todo el Web, tambien pueden encontrarse confrecuencia en abundantes fuentes de datos dentro de entornos corporativosde tamano mediano o grande. Precisamente por ello, son numerosas las em-presas que presentan actualmente necesidades de poder integrar, no ya en ununico documento, sino quiza tambien en la toma de decisiones operativas dela 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 combinenla informacion obtenida de distintas fuentes en el Web.

Si bien es habitual que cada una de esas fuentes fuera desarrollada ensu momento con distintas tecnologıas y objetivos, lo cierto es que la granmayorıa de ellas fue concebida para ser accedida de forma que la informacionresultante de cada una de ellas fuera a ser consultada directamente, bienpor personas, bien, en el mejor de los casos, pese a su enorme coste, porotras aplicaciones capaces de realizar llamadas a una interfaz particular dela aplicacion. Las nuevas formas de negocio de hoy en dıa y la necesidad demanipular mucho mas eficientemente grandes volumenes de informacion defuentes muy diversas han contribuido ineludiblemente a una necesidad cadavez mayor de que esas consultas a los antiguos sistemas aislados preexistentespuedan estar ahora integradas en otras consultas realizadas por nuevos pro-gramas capaces de combinar eficientemente la informacion que pueda estardistribuida 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 reconociblemas alla del simple texto sin estructura, si se tienen en cuenta precisamentecombinaciones especiales de etiquetas de marcado que son capaces de iden-tificar a los datos clave que deben extraerse de las paginas.

Un foco importante de investigacion en la actualidad es la construccion desistemas capaces de integrar de manera sencilla datos semiestructurados he-terogeneos y dispersos de multiples fuentes accesibles por medios telematicosde forma que se obtenga de los mismos una vision similar a la proporcionadapor una unica base de datos convencional. La idea de este enfoque consisteen ocultar todo tipo de heterogeneidad de cada una de las fuentes de datosaccedidas de forma que al usuario se le proporcione una unica vision globalde todo el sistema y pueda manipular cada uno de los recursos de la redde una forma uniformizada, pese a que cada sistema trabaje en realidad de

22

forma distinta y tenga sus propias particularidades sintacticas. Los sistemasDatawarehouse, basados en la replicacion de informacion a un repositoriocomun [68, 92] usados en entornos cerrados desde hace tiempo, no son ade-cuadamente escalables para ser usados en el Web. Quiza la aproximacionarquitectural mas utilizada hasta el momento para este tipo de sistemas seala de los sistemas mediadores [79, 101]. En ella, los datos permanecen en susfuentes originales y un sistema intermedio, llamado mediador, se encarga deproporcionar a lo usuarios la ilusion de que existe una unica fuente en la quese encuentran todos los datos combinados y unificados de manera coherentede acuerdo a un unico esquema global. Cuando el mediador recibe una con-sulta sobre el esquema global, esta se reformula en diversas subconsultas quese realizan directamente sobre las fuentes originales. La interaccion directacon las fuentes es delegada por el mediador a los llamados programas envol-torio (o wrappers), cada uno de ellos especializado en el dialogo concreto concada 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, devolviendoselos al me-diador. Es entonces cuando los resultados de las fuentes son reestructuradospor el mediador para ajustarse al esquema global y ser devueltos entonces alusuario. De esta manera, este obtiene la impresion de estar consultando ununico sistema. Este esquema se encuentra representado en la figura 1.1.

Figura 1.1: Sistema mediador

La motivacion de la construccion de este tipo de sistemas se encuentratanto en los planes estrategicos a nivel corporativo dentro de una organiza-cion, 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 informacion enorme, que es difıcil de gestionar, y a la quees complicado, cuando no imposible, sacar el maximo partido. Por otro la-do, diversos factores, como la rapida evolucion tecnologica, las presiones delmercado o el efecto de la competencia entre diferentes proveedores de solucio-nes tecnicas, han causado que los entornos y las tecnologıas utilizadas para lageneracion y manejo de estos datos difiera en gran medida a lo largo del tiem-po, creando ası, a lo largo de los ultimos anos, un escenario donde grandesvolumenes de informacion se encuentra dispersa en fuentes independientes yheterogeneas, cuyos datos necesitan ahora mas que nunca ser combinados yunificados. Son muchas las organizaciones que estan desarrollando o tienenplanes de desarrollar sistemas capaces de proporcionar visiones unificadas delos datos manejados por la organizacion.

Los problemas a los que los sistemas mediadores se han venido enfrentan-do en los ultimos anos son extrapolables a la realizacion de muchas tareasen el Web. Muchos de las aplicaciones construidas en las intranets de lossistemas corporativos a lo largo de los ultimos anos han sido creadas coninterfaces para el Web. Es por ello que los sistemas mediadores se han vistoultimamente cada vez mas abocados a la automatizacion de tareas en lasaplicaciones de las intranets de estas corporaciones. A pesar de que el nume-ro de posibles tareas automatizables en el Web es mayor que las realizablesen las intranets de las aplicaciones corporativas, los sistemas mediadores,impulsados por las necesidades de estas corporaciones, no han dejado de serun importante exponente de la necesidad de automatizar el tratamiento dedatos obtenible de aplicaciones accesibles desde el Web.

1.3.6. Asistentes de navegacion Web

Para automatizar tareas en el Web se necesitan programas capaces de eli-minar la necesidad de que el usuario deba interactuar incansablemente con elordenador durante la ejecucion de la tarea. En lugar de solicitar que, durantela navegacion, el usuario active el seguimiento de cada enlace que se deseavisitar, se deben preprogramar todas esas activaciones en un algoritmo, deforma que queden ası explıcitamente la seleccion preaprobada de los enlacesque se seguiran durante la ejecucion de la tarea. El resultado de ese algoritmonormalmente consistira en presentarle al usuario solo los datos (resultados,confirmaciones, ...) que a este le interesan, evitando, en lo posible, mostrarletoda aquella informacion irrelevante para su tarea. El programa capaz deautomatizar de esta forma las tareas del usuario conforme a sus interesesse denomina asistente de navegacion Web. En la figura 1.2 aparece es-

24

quematizada la diferencia entre la tradicional navegacion manual basada enbrowsers y la navegacion basada en asistentes de navegacion Web. Con unasistente de navegacion Web, se persigue sustituir al browser y al usuario quelo maneja por un unico programa capaz de automatizar una tarea de formaque los servidores Web involucrados presten a la aplicacion el mismo servicioque prestarıan a un usuario que realizara esa tarea con un browser.

Figura 1.2: Comparacion de navegacion manual con automatica

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 continuacion se presentan algunas de las principales caracterısticas de losdatos del Web.

1.4.1. Voluminosidad

En las ultimas decadas las nuevas tecnologıas han permitido la creacion,recopilacion y publicacion de grandes volumenes de informacion accesible enuna amplia diversidad de formatos y mediante una amplia gama de mediosde acceso telematicos. Por otra parte, muchas aplicaciones ya existentes enlas intranets de muchas organizaciones han sido reconvertidas para poder seraccedidas ahora desde el Web, mediante un mayor numero de terminales.Esto ha llevado, por otra parte, a la aparicion de un gran numero de aplica-ciones que, siendo accesibles desde cualquier punto del planeta mediante elWeb, a traves de sus interfaces basadas en formularios, proporcionan al Webuna enorme cantidad de informacion para la que no existen apenas mediosadecuados de manipulacion.

25

1.4.2. Heterogeneidad

El Web es un ente tremendamente heterogeneo, lo cual ha implicado unagran dificultad a la hora de manejar adecuadamente los grandes volumenesde informacion dispersa en el Web. La proliferacion de fuentes de informa-cion desarrolladas de forma totalmente independiente unas respecto de lasotras ha llevado a un escenario en el que mucha informacion potencialmen-te util para las necesidades particulares de muchos usuarios este dispersa yalmacenada segun esquemas y estructuras de almacenamiento con grandesheterogeneidades. Debido a la intrınseca naturaleza abierta en el Web, loscontenidos de la misma se muestran debilmente estructurados y, cuando loestan, su esquema es enormemente heterogeneo, presenta irregularidades, ysigue muy pocas restricciones. Otra peculiaridad del Web actual es el hechode que la inmensa mayorıa de su informacion es legible para las personas,pero no lo es para las maquinas, por lo que su tratamiento automatizado seencuentra con importantes problemas. La heterogeneidad de las Webs de lasempresas supone aun mayores problemas cuando se las pretende interconec-tar con las de sus clientes o proveedores u otros canales de comercializacion.

1.4.3. Orientacion a los visualizacion

Una de las grandes barreras a la automatizacion en el Web actual (notanto por los principios en los que se fundo, sino por el uso que se le haido dando despues) es que esta muy orientado a la visualizacion. La granmayorıa de los disenadores no han concebido sus paginas para ser procesadaspor otro tipo de aplicaciones distintas a los browsers. Es mas, tampoco resultaextrano que algunos disenadores hayan concebido sus paginas para que seannavegadas exclusivamente desde ciertos browsers concretos, excluyendo,en ocasiones sin saberlo, en otras intencionadamente, la navegacion de otrostipos de programas como las que aparecen en la tabla 1.2.

La actual orientacion a la visualizacion en el Web no es un problemaen sı mismo para la accesibilidad si esa orientacion esta basada en hojasde estilo. Sin embargo, quiza porque las hojas de estilo nacieron algo mastarde que el propio Web y aun no tienen un soporte completo en muchasherramientas, tradicionalmente las paginas han reflejado su orientacion a lavisualizacion en el propio marcado HTML de sus paginas. La gran mayorıa delos sitios Web actuales centran aun el uso de su marcado HTML en aspectosprimordialmente visuales (tamanos y tipos de letra, colores, alineamientos,espaciados, distribucion por la pantalla, imagenes, ...), muchos de ellos en-focados para impactar visualmente al usuario que use uno de los browsers

26

graficos admitidos por el disenador del sitio Web.

A pesar de que iniciativas como las de las hojas de estilo CSS bien permi-ten independizar a HTML de esa orientacion a la visualizacion, buena partedel marcado HTML que se usa en las paginas de millones de aplicacionesaccesibles desde el Web, creadas a lo largo de los ultimos anos, esta aunorientado a estos fines. Ası, en lugar de un Web en la que cualquier paginaHTML pueda ser navegable desde cualquier browser y dispositivo de acce-so, donde las distintas peculiaridades de cada uno esten contempladas endistintas hojas de estilo, cada una de ellas adaptada a un tipo distinto determinal, el Web actual adolece de un grave problema de orientacion a unreducido numero de browsers, puesto que los usuarios que utilizan otros ti-pos de programas de acceso distinto a esos browsers, no tienen un adecuadoacceso a los contenidos que desean visitar. Para muchos usuarios, son muchaslas paginas inaccesibles, donde determinados contenidos dejan de ser visiblesy muchas aplicaciones accesibles desde el Web dejan de ser funcionales sim-plemente por el hecho de que se acceda a ellas con browsers no consideradospor el disenador del sitio Web.

Por ejemplo, resulta habitual el hecho de que se visualicen enlaces que sinembargo 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 segun elagente de usuario empleado y acaban redirigiendo a la portada del Web o auna pagina de error en la correspondiente respuesta a toda peticion en la queno se acompane la identificacion del browser esperado en ese Web. En muchossitios, la navegacion basada en browsers sobre terminales tipo texto, comoLynx [10] resulta impracticable. Incluso la navegacion basada en browsersgraficos resulta impracticable en muchos sitios Web si no se tiene activadaalguna funcionalidad especial que el disenador del sitio Web considero comonecesaria, como son las cookies, las rutinas JavaScript [74], las imagenes, olas animaciones en Flash u otros formatos. A ello hay que anadir la escasezpractica de descriptores textuales adecuados en numerosos componentes delas paginas, como los scripts, los applets, los plugins, los frames o los contro-les ActiveX, muchos de los cuales solo resultan funcionales en determinadosbrowsers, pero no en otras aplicaciones.

Accesibilidad

Iniciativas de mejora para la accesibilidad, como las publicadas por elW3C en sus recomendaciones [128, 137, 136], estan encontrando ultimamen-

27

te un decidido apoyo en numerosas personas e instituciones para conseguirque el acceso a los contenidos Web sea funcional con independencia de cualsea la plataforma de acceso, tanto hardware como software. Estas recomenda-ciones ultimamente hacen especial hincapie en poco costosas, pero efectivasmejoras de acceso al Web por parte de, tanto browsers especıficos usadospor personas discapacitadas, como los recientes terminales inalambricos conpantallas de reducidas dimensiones y escasa capacidad de procesamiento oancho de banda limitado, tales como telefonos moviles, asistentes personaleso pequenos electrodomesticos. La correcta operatividad con independenciadel browser utilizado o del dispositivo de acceso escogido es una de las gran-des necesidades del Web actual. Ultimamente, el cada vez mayor numero deformas de acceso ha puesto aun mas de manifiesto el serio problema de acce-sibilidad existente en el Web, como lo demuestra el hecho de que los nuevosdispositivos sean incapaces de acceder adecuadamente a las paginas del Weblegado. Este problema ha permanecido disimulado por el importante domi-nio de Microsoft Internet Explorer como browser mas utilizado en los ultimosanos. No obstante, numerosas iniciativas de mejora, como las del W3C y otras[109, 106, 96, 121] han sido propuestas para aportar soluciones. Dentro de lasrecomendaciones del W3C se enumeran varios tipos de programas de navega-cion, mucho mas alla de los habituales browsers graficos. El objetivo de estasrecomendaciones es la de permitir el correcto acceso al Web desde terminalesen modo texto, software especıfico de navegacion para personas con visiondiscapacitada que presentan al usuario las paginas en Braille o en audio,ası como desde terminales de reducidas dimensiones, con pequenos displayscomo los cada vez mas habituales dispositivos inalambricos, y muchos mas.

El objetivo principal de estas iniciativas consiste en que las paginas pu-blicadas en el Web sean accesibles a sus usuarios independientemente deldispositivo 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 delmarcado HTML que este orientado a la visualizacion, delegando esa tarea enlas hojas de estilo y simplificando ası el marcado estructural de las paginas.En la tabla 1.4 pueden contemplarse las principales diferencias entre las dis-tintas versiones de HTML surgidas en los ultimos tiempos, desde los puntosde vista de la orientacion a la visualizacion y a la accesibilidad.

Resulta curioso destacar en este punto como los sitios Web que mas exitohan cosechado en los ultimos tiempos (Google, Yahoo, eBay, EasyJet ...)suelen tener como caracterıstica comun el hecho de que no hacen apenas

28

HE = Hojas de estilo HTML sin HE HTML con HE XHTML o XML

Orientacion a la visualizacion En HTML En hoja de estilo En hoja de estilo

Accesibilidad por terminales Baja Media Alta

Regularidad estructural Orientacion visual Sencilla Sencilla

Modificaciones en la estructura Habituales Escasas Infimas

Reglas de construccion Basicas Basicas Tipo de documento

Automatizacion de tareas Difıcil Media Facil

Difusion relativa en el Web Alta Baja Muy baja

Cuadro 1.4: Principales diferencias entre las ultimas versiones de HTML

uso de tecnologıas que mermen la accesibilidad de sus paginas. Sin embargo,la escasa implantacion practica de las normas y recomendaciones del W3Cdurante muchos anos hace prever que la transicion hacia un Web accesiblepara browsers de distintos terminales sera aun lenta, en cuanto a la inercia delWeb esta asentada en su gran tamano y en la tradicional escasa orientacionde disenadores y herramientas a estos aspectos. La orientacion del Web alos browsers como unicas herramientas de acceso es la razon de que el Websea aun muy abundante en paginas que no solo no cumplen las reglas de larecomendacion oficial de XHTML, sino que ni tan siquiera cumplen muchasde las reglas de las recomendaciones anteriores de HTML.

1.4.4. Relevancia dependiente de la tarea

Por datos relevantes se debe entender, no solo aquella informacion es-pecıfica que esta siendo buscada y que forma parte de los resultados que,quiza tras algun procesamiento, se le deben proporcionar al usuario al finali-zar la tarea, sino, en general, todos aquellos datos que puedan ser utilizablesen algun momento dentro de ese proceso de navegacion. Ejemplos de datosrelevantes son las direcciones de las paginas que se deben visitar, los camposde formularios que se deben rellenar, o quiza incluso simples campos que apa-recen en las paginas en funcion de cuyos valores se puede tomar la decisionde seguir uno u otro enlace o efectuar una u otra accion definible por el usua-rio. No toda la informacion de cada pagina Web es igualmente relevante. Escomun que, para una tarea particular, de una sola pagina apenas interese undato, un determinado enlace o un formulario concreto y los demas datos de lapagina puedan ser felizmente ignorados. La relevancia de cada informacion,por otra parte, no se puede considerar en terminos absolutos. La relevanciade un dato depende de la tarea concreta que se desee realizar, es decir, de losobjetivos por los cuales la pagina 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 otroenlace completamente distinto. Para ciertas personas, determinada informa-cion puede ser considerada como relevante, mientras que, para otras, pese aque tengan propositos similares, esa misma informacion puede no serlo. Encualquier caso, dicha informacion, relevante o no, es presentada al usuariotıpicamente embebida en paginas Web que, estando escritas en HTML parasu visualizacion en browsers, no estan, sin embargo, orientadas para ser pro-cesadas por otro tipo de aplicaciones capaces de manipular esa informacionautomaticamente. Es decir, las paginas HTML estan construidas para ser vi-sualizadas, pero no para ser comprendidas por maquinas. El problema de laintegracion de datos del Web en aplicaciones, esto es, de su automatizacion,ha sido abordado de manera muy activa por investigadores de diferentes co-munidades y disciplinas, tales como la Telematica, la Minerıa de Datos o laInteligencia Artificial, realizandose en los ultimos anos importantes contri-buciones desde diferentes puntos de vista.

1.4.5. Regularidad estructural

Las bases de datos, que almacenan su informacion de forma estructurada,al volcar sus contenidos en paginas Web, suelen conservar en ese volcadocierta regularidad, denominada estructural, en el marcado HTML de los datosvolcados. Distintos datos conviviendo bajo la misma ferrea estructura de unabase de datos acaban siendo volcados al Web con similares etiquetas HTML,por lo que conservan una cierta regularidad estructural en sus marcados. Unejemplo de ello puede verse en la figura 1.3, donde se muestra parte del codigode una pagina Web que contiene los resultados de una busqueda en Google.

El hecho de que exista una regularidad estructural en las paginas HTMLpublicadas en un mismo servicio (aplicacion accesible desde el Web o con-junto de paginas logicamente enlazadas para un fin comun y publicadas bajouna misma estructura) tiene un inmenso valor para la extraccion de datosdel Web. La regularidad estructural puede ser usada para identificar unosdatos respecto de otros. Sin embargo, el hecho de que dicha estructura nosea 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. Ademas, la estructurasupuestamente regular de los sitios Web puede presentar irregularidades confrecuencia. Por ejemplo, es habitual que en el catalogo electronico 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 acompanadosademas de un indicativo promocional de oferta, que otros artıculos no poseen.Es precisamente la posibilidad que HTML ofrece para realizar multiples 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 heterogeneo asimple vista, pese a que los principios de su funcionamiento sean en realidadsencillos. Es precisamente esa combinacion de sencillez y flexibilidad, caren-tes en el mundo de las bases de datos, una de las principales razones que hanencumbrado a HTML como el formato por excelencia de los documentos enel Web.

Reconocer esta regularidad estructural en una pagina permite extraer susdatos relevantes. Existe una gran necesidad actualmente de aplicaciones quepuedan integrar la informacion semiestructurada de varias fuentes diversaspreexistentes. La heterogeneidad de la forma de marcar datos en cada fuentehace necesario muchas veces un pretratamiento particularizado consistenteen adaptar los datos provenientes de diversas fuentes a un formato comun.Una vez estructurados todos los datos en un formato comun, estos puedenser procesados adecuadamente sin tener en cuenta su procedencia. Esto sueleser necesario en procesos de integracion de informacion 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 losservidores localizados en la intranet de una empresa, donde es primordialque los sistemas sigan funcionando para las personas y herramientas que losllevan usando sin necesidad de ser interferidos por el hecho de que una nuevaherramienta de acceso se incorpore al sistema informatico preexistente.

1.4.6. Ausencia de semantica en el marcado

Cualquier dato que aparezca en una pagina HTML no puede distinguirsefacilmente de forma automatizada. Por ejemplo, un dato numerico, no puedereconocerse facilmente como un precio, una cantidad, una fecha o un numerode referencia por la sencilla razon de que en el marcado HTML del Webactual no se distingue entre unos tipos de datos respecto de otros. Por otrolado, practicamente casi cualquier combinacion de etiquetas HTML puedeusarse indistintamente para marcar unos datos u otros, razon por la queacaba siendo el usuario quien, aplicando sus conocimientos contextuales enla navegacion, infiere la semantica de esos datos al visualizarlos en la pantalla.Esto es algo que ocurre cuando se navega con un browser. En la navegacionmanual se debe tomar muchas veces la decision de pulsar en uno u otro enlaceo la de rellenar un formulario en lugar de otro, o la de rellenar cierto campo deuna forma en lugar de cierta otra dependiendo de los datos visualizados hastael momento en la pantalla, pero que el ordenador no es capaz de distinguirrespecto del resto de los datos visualizados porque HTML es un lenguajede marcado poco orientado a la descripcion semantica y con un uso muyorientado a la visualizacion.

1.4.7. Niveles de estructuracion

Tradicionalmente, en el campo de la documentacion, se ha distinguido en-tre datos estructurados y datos no estructurados. Los datos no estructuradosson aquellos que no presentan ningun esquema o estructura mas alla de lamera secuencia de bytes o palabras. Los datos estructurados son aquellos quesiguen un esquema de datos perfectamente definido (e.g. aquellos contenidosen bases de datos). El esquema que define la estructura de un conjunto dedatos estructurados suele incluir ferreas restricciones sobre los mismos, talescomo 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 tamano o posibilidad de impedir la existencia de camposcon valores nulos.

32

Datos no estructurados

Un ejemplo tıpico de datos no estructurados son los textos libres. Debi-do a su escasa o practicamente nula estructura, la unica manera posible derecuperar informacion de estos documentos es mediante consultas no estruc-turadas o imprecisas, tales como las busquedas por palabra clave. Con estetipo de consultas solo es posible representar expresiones que recuperen aque-llos documentos en los que aparece el conjunto de palabras clave buscadas. Eshabitual en este tipo de consultas la posibilidad de utilizar operadores logicospara combinar expresiones simples. Basicamente, este es el sistema de datosen 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 grannumero de trabajos e importantes contribuciones a este respecto [28], lo ha-bitual es que este tipo de soluciones trabajen con un nivel de granularidaddemasiado grueso (el documento), frente a lo que muchas veces en reali-dad se necesita (el dato). Los muy bien conocidos buscadores como Googleo Altavista consideran el Web como un gran repositorio de informacion noestructurada y son capaces de construir gigantescos ındices sobre el Web,permitiendo su consulta de forma eficiente. Sin embargo, para un cada vezmayor numero de usuarios que encuentran la necesidad de realizar consultasmas especializadas, esta abstraccion del Web como un conjunto de informa-cion no estructurada es demasiado debil, ya que, a fin de cuentas, no sirvenpara nada mas que para localizar documentos que tengan las palabras con-sultadas, no para obtener el dato en sı que en realidad buscan, ni tampocopara automatizar el uso de aplicaciones manejables desde formularios.

Datos estructurados

Los datos estructurados son aquellos que presentan un esquema rıgidoy bien definido para los datos. Un ejemplo tıpico de fuente estructurada dedatos son las bases de datos relacionales. En este caso existe un diccionariode datos que define la organizacion interna y las restricciones de los datos,ası como de las relaciones entre los mismos. Cuando los datos se encuentran enforma estructurada, es posible realizar consultas precisas mediante lenguajesde consulta estructurados, de los cuales el mas popular es SQL [78]. Estaprecision a la hora de hacer consultas hace que los datos estructurados seanmuy adecuados para su tratamiento por programas de ordenador.

33

Datos semiestructurados

Al contrario de los datos estructurados, los datos del Web carecen de todasestas restricciones y pertenecen a una categorıa distinta. Esa categorıa dedatos ha recibido el nombre de datos semi-estructurados [36]. Los datos semi-estructurados se caracterizan porque, aunque siguen algun tipo de esquema,el seguimiento que hacen del mismo es mucho menos rıgido que en el casode los datos estructurados. Segun [60], las principales caracterısticas de losdatos 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 ycualquier restriccion asumible de ese esquema debera inferirse de ellosde 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 cualquiermomento.

El esquema tolera irregularidades que no siempre aparecen especifica-das.

No existe un tipado fuerte de los datos individuales, por lo que es posibleencontrar en ocasiones valores de tipos diferentes a los esperados. Porejemplo, para un mismo tipo de dato consultado, es posible que esteaparezca en varios formatos distintos.

Sin tener la programabilidad de una ferrea base de datos en la que es facilasumir decisiones semanticas acerca de los datos, su bajo coste de creacionlas ha convertido en poco tiempo en la alternativa usada por excelencia parala publicacion de datos en el Web. Sin embargo, la gran mayorıa de la in-formacion accesible por el Web no presenta un nivel de estructuracion tanfuerte, pese a que serıa deseable poder manipularla eficazmente. En muchasocasiones, 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 facilmente la vision de esa estructura ferrea. HTML es un buenformato para ser visualizado en navegadores. Sin embargo, su estructura noesta orientada a la descripcion de los datos, sino a su visualizacion. Tenga-se en cuenta, que en el proceso de transformacion de la informacion desderepositorios estructurados a formatos visualizables, se produce una perdidade estructuracion que, a lo largo de los ultimos anos, 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 metodos para reestructurar lainformacion del Web son mas necesarios.

HTML es el lenguaje de marcado en el que se encuentran embebidosmayoritariamente los datos del Web. Apenas los Web Services [53] y unospocos y marginales (comparativamente con el inmenso tamano del Web)segmentos de negocio usan XML como formato de intercambio de datos.Algunos mas son los sitios que aparecen publicados en XHTML [117]. Muyal contrario de los documentos XML, las paginas HTML se caracterizanporque su estructuracion esta atada a muy pocas reglas. La gran mayorıade ellas son reglas elementales de construccion, sin que las reglas logicas deestructuracion propias del ambito de conocimiento del documento quedenbien reflejadas en su marcado estructural. Este marcado, por el contrario,sı suele contener una elevada carga de aspectos orientados a la visualizacion.Esta debil estructuracion de las paginas puede ser cambiada facilmente encualquier momento, pues no existe un esquema de datos explıcito que debaregir la estructura de las paginas. Por todos estos motivos, los documentosHTML pueden ser considerados como datos semiestructurados.

La tabla 1.5 presenta un resumen de las principales diferencias entre lascaracterısticas de los datos segun sus distintos niveles de estructuracion.

Datos no estructurados Datos estructurados Datos semi estructurados

Esquema de datos Inexistente Explıcito Implıcito

Restricciones Inexistentes Ferreas Laxas

Irregularidades Inexistentes Prohibidas Abundantes

Cambios de estructura Inexistentes Prohibidos Habituales

Consultas Imprecisas Precisas Poco precisas

Ejemplo Texto plano Base de datos Pagina Web

Coste de creacion Bajo Alto Bajo

Uso Medio Bajo Muy alto

Cuadro 1.5: Diferencias entre caracterısticas de los datos segun su nivel deestructuracion

1.4.8. Distribucion de la informacion

Los datos que aparecen en el Web y son necesarios para una tarea nosuelen aparecer todos integrados en un mismo documento, sino que suelen

35

aparecer distribuidos en varios de ellos por cuestiones organizativas. Ası pues,informacion 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 deocio.

Entre los documentos individuales integrantes de otros documentosmultimedia, como por ejemplo las diversas paginas que formen un mis-mo frameset.

Entre diversas paginas enlazadas entre sı, como por ejemplo, los deri-vados de la paginacion de resultados de busqueda.

Mezclada dentro de una misma pagina con informacion no relevantepara la tarea, como por ejemplo, la publicidad y otras informacionesno relevantes para la tarea.

1.4.9. Difıcil modificabilidad

Los programas creados para navegar automaticamente en el Web, de-ben, por lo tanto, afrontar el problema del manejo de informacion semi-estructurada, corriendo el peligro de ver modificada, sin previo aviso, la es-tructura de las paginas que se desea visitar. En el caso de la integracionde aplicaciones accesibles desde el Web, estas deben ser tratadas con su-mo cuidado y respeto para no interferir en el correcto funcionamiento delas tareas realizadas por otros mecanismos, tıpicamente browsers, que otrosusuarios esten llevando a cabo. La mejor forma de integrar estas aplicacioneslegadas suele consistir, no en modificarlas para que contemplen una nuevaherramienta de acceso, sino en usar las interfaces que ya tengan desarrolla-das, tıpicamente formularios en formato HTML, creando herramientas queemulen las herramientas de acceso preexistentes que hasta el momento hanestado siendo usadas. En muchas ocasiones ello supone, si no un serio ahorrode costes, la unica opcion 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 mas 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 visualizacion, el uso de XML se ha extendidorapidamente como solucion al intercambio de datos estructurados en muydiversos ambitos. Las principales cualidades de los documentos XML son lassiguientes:

Sintaxis facilmente procesable

XML presenta una sintaxis textual muy simplificada que permite estruc-turar facilmente los documentos en forma de arbol. Al contrario de su pre-decesor SGML [65], los programas que procesan XML pueden ser muy facil-mente construibles debido a la simplicidad del formato, algo que sin embargono le resta flexibilidad y extensibilidad para poder definir documentos com-plejos.

Independencia de la presentacion

XML permite dotar facilmente a los documentos de una estructurasintactica que este adecuada a la naturaleza propia del documento, pres-cindiendo absolutamente de la forma en la que este pueda ser visualizado,labor que queda delegada en las hojas de estilo.

Estructuracion de datos

Las etiquetas XML no definen propiedades acerca de como deben servisualizadas, sino que simplemente describen los datos que contienen. Con elfin de dar una descripcion formal a los posibles contenidos que puede teneruna etiqueta dentro de un documento, XML incluye la posibilidad opcionalde describir esas sintaxis mediante los DTD o XML Schema.

Contexto semantico

Algo que no forma parte de la especificacion de XML y para lo que aunno se ha definido formato estandarizado de representacion es el contextosemantico. Mediante un contexto semantico capaz de dotar de significadosa cada una de las partes de esa estructuracion sintactica (etiquetas y atri-butos XML), es posible ası que cada uno de los datos que aparecen en un

37

documento pueda tener significado semantico para los usuarios. De esta for-ma, las distintas partes de los documentos pueden presentar un significadoconocido y sin ambiguedades, adecuado para ser entendible por las maquinas,algo que las paginas HTML que forman parte del Web actual no cumplen,pues estan orientadas a la mera visualizacion. La tabla 1.6 refleja un resumende las aportaciones que realiza cada una de las tecnologıas mencionadas eneste parrafo a los documentos estructurados en XML.

Tecnologıa Aporta Finalidad Herramientas

XML Sintaxis Datos descritos DTD, Schema, Relax-NG, ...

Hojas de estilo Presentacion Documentos presentables CSS, XSL, ...

Contexto semantico Semantica Documentos procesables Metadatos RDF/OWL, programas ...

Cuadro 1.6: Resumen de aportaciones de XML

Sin embargo, siendo XML una buena opcion, lamentablemente aun no esusada masivamente en el Web. Para ello resulta necesario un cierto consensoa la hora de escoger el lenguaje concreto de entre los multiples lenguajesexistentes de un dominio de conocimiento para marcar adecuadamente loscontenidos. Por otro lado, lo cierto es que XML apenas resuelve una partedel problema: la de la estructuracion de los documentos y la posibilidad deasociar, gracias a un contexto que suele estar implıcito en las personas, sig-nificados semanticos 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 normalmenteno se puede conseguir en un solo paso.

Sin embargo, al igual que ocurre con la orientacion a la accesibilidad eindependencia del dispositivo de acceso, son numerosos los inconvenientes quepermiten augurar que XML aun tardara mucho tiempo en ser una solucionefectiva. Entre esos inconvenientes cabe destacar los siguientes:

El uso de XML directamente en los browsers, como mero formato devisualizacion, acompanado, eso sı, de sus correspondientes hojas deestilo, no aporta ventajas sobre otros formatos para los que ya existenbrowsers, como HTML.

El ya gigantesco tamano del Web supone sin duda una gran inercia ala hora de acoger nuevas tecnologıas. Ello implica que, aunque en de-terminado momento, XML pase por fin a ser la solucion comunmente

38

aceptada por los servidores Web, la lentitud con la que se reajustaranlas paginas de los servidores Web ya existentes implicara que el accesoa sitios Web basados en HTML seguira siendo necesario durante muchotiempo. Y aun ası, no es previsible tampoco que HTML llegue a desa-parecer por XML, por lo que habra un gran numero de aplicaciones queno migraran a XML. En cualquier caso, en la actualidad, tras cuatroanos despues del nacimiento de XML, este apenas se encuentra usadoen unos pocos segmentos verticales de negocio, de una forma marginalsi se lo compara con HTML.

El hecho de que las especificaciones del W3C que parecen prometernuevas soluciones esten aun en fase de borrador supone un serio incon-veniente para ser adoptadas por los desarrolladores, que las contemplanaun con muchas reticencias.

1.5. Coste de la navegacion automatizada

Uno de los aspectos mas curiosos para la automatizacion de tareas en elWeb es que la mayorıa de las mejoras de accesibilidad mencionadas en elapartado 1.4.3 en lo referente a la independencia de dispositivos de accesoen la navegacion con browsers, son tambien directamente aprovechables paraotras aplicaciones que no son browsers, como las de navegacion automatica.Un marcado poco orientado a los aspectos de visualizacion, que delegue esalabor en hojas de estilo, independiente del dispositivo de acceso, y cercano ala estructura logica del documento, es mas simple y regular y menos proclivea ser modificado con el tiempo, pues seran las hojas de estilo quienes asumanlos cambios de presentacion. Ello redunda en una importante minimizacionde costes, tanto de publicacion en el lado del servidor como de procesamientoen el cliente que manipule las paginas obtenidas del servidor.

En el lado del servidor, la opcion de mantener documentos accesibles, cadauno de ellos visualizable con varias hojas de estilo alternativas, cada una deellas a su vez orientada a un dispositivo de acceso, sera sin duda mucho maseconomica (en tiempo, espacio y esfuerzo a largo plazo) y escalable que la demantener para cada pagina una version orientada a cada terminal.

En el lado del cliente, la simplicidad del marcado de las paginas accesiblesreduce sensiblemente la complejidad de procesamiento. Esto tiene especialimportancia en las reglas de extraccion de datos basadas en la regularidadestructural de las paginas. Al ser esta regularidad estructural mas simple ymas estable, estas reglas seran a su vez mas simples y estables, por lo que

39

necesitaran 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 endistintos lenguajes de programacion. Desde C, Java, Perl, TCL-TK, Prolog,Visual Basic hasta el mismo ensamblador, cualquiera de estos lenguajes puedeser usado en la construccion de estos sistemas, habida cuenta de la existenciade 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 losmismos costes, soliendo haber unos lenguajes mas orientados que otros paracada tipo de labor. Para minimizar los costes, es necesario que la plataformade ejecucion proporcione un buen soporte al acceso de datos en el Web porel protocolo HTTP, emulando lo mas parecidamente el comportamiento deun browser y ejecutando la mayor cantidad de acciones que implıcitamenteeste ejecuta, algunas de las cuales aparecen en el apartado 2.1, como porejemplo que este sea robusto en los fallos que ocasionalmente ocurren en lascomunicaciones (sobrecarga en la conexion, tiempo de respuesta excesivo enel servidor, ...), enlaces rotos a componentes del documento, y que permitaubicar facilmente los errores cuando estos se produzcan, para ayudar a unamas rapida reparacion del codigo de la aplicacion. Desde el punto de vista delprogramador, la plataforma de ejecucion debe proporcionarle ademas un APIde desarrollo con el adecuado nivel de abstraccion, la posibilidad de anadirsus propias medidas de robustez ante inesperados comportamientos del ser-vidor (paginas de error, cambios de regularidad estructural, ...) y, sobre todo,una sencilla forma de definir para fuentes de datos semiestructuradas, reglasde extraccion de datos, sencillas, potentes y faciles de mantener, pues suelenser la parte que mas suele sufrir ante los inevitables cambios en la regula-ridad estructural de las paginas. Los costes de la navegacion automatizada,que aparecen resumidos en la tabla 1.7, pueden separarse en tres grandesgrupos:

Coste Necesidad Para programador Para plataforma

De desarrollo Buen API Buen nivel de abstraccion Buen soporte acciones implıcitas

De ejecucion fallida Robustez Ante cambios o fallos del servidor En comunicaciones

De mantenimiento Bajo coste Reglas de extraccion de datos Ubicacion de errores

Cuadro 1.7: Resumen de tipos de coste de la navegacion automatizada

40

1.5.1. Coste de desarrollo

El desarrollo de aplicaciones de navegacion automatizada debe tener encuenta las caracterısticas de los datos que va a manejar, que se encuentranen el apartado 1.4. El coste de desarrollo depende sin duda de la complejidadde la tarea que se desea automatizar, pero tambien es altamente dependientedel 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 accionesbasicas implıcitas que aparecen en el apartado 2.1 y que a su vez ese APItenga un buen nivel de abstraccion para poder facilitar convenientemente laimplementacion de las acciones basicas explıcitas, esto es, los pasos basicosde la tarea, detallados en el apartado 2.2. Una optima plataforma de desa-rrollo sera aquella que permita detallar cada una de estas acciones con elmınimo numero de lıneas de codigo de alto nivel, entendibles por mucha gen-te y evitando en la medida de lo posible que sus diferencias con un browsertrasciendan al usuario, para garantizar que la parte de la tarea que especificala recuperacion de documentos del Web sea realizada de la forma mas sencillaposible.

Sin embargo, la recuperacion de documentos del Web no es mas que unade las acciones que deben formar parte de la tarea. Tal y como figura en elapartado 2.2, debe procesarse el documento para extraer los datos relevantesque en el figuran, estructurarlos, opcionalmente homogeneizarlos en el caso deque puedan proceder de varias fuentes y procesarlos conforme a la tarea que seeste automatizando. Todas estas acciones deben ser programadas para cadatarea. Sin duda, dado que a fin de cuentas el desarrollo de estos programases una labor de programacion, conviene dotar al programador de las mejorestecnicas de reutilizacion de codigo propias de los lenguajes de alto nivel deabstraccion, como son la encapsulacion en funciones definidas por el usuarioy la modularizacion de las mismas para que pueda construir sus propiasbibliotecas reutilizables por el y por otros usuarios. De esta forma puedereducirse igualmente el time to market, es decir, el tiempo de desarrollo y sepuede disfrutar mas facilmente de prototipos mas rapidamente aplicables.

No obstante, una de las principales fuentes de coste de desarrollo de estosprogramas es la falta de soporte adecuado para muchas acciones ocultas alusuario durante la navegacion y que son normalmente ejecutadas por losbrowsers. Siendo lo ideal que dichas acciones sean llevadas a cabo de formatransparente por estas plataformas para que no trasciendan al usuario, lohabitual es que las actuales plataformas de desarrollo de estos programasproporcionen un soporte bastante incompleto de las mismas, por lo que alfinal, el programador debe introducir su propio codigo para llevar a cabo un

41

sinfın de pequenos detalles tecnicos de los que los usuarios de los browsers noacaban siendo normalmente conscientes y que aumentan considerablementela complejidad de la tarea. De esta forma, una pequena y sencilla labor en elWeb puede facilmente requerir el desarrollo de programas demasiado grandesy complejos que intentan resolver una gran variedad de pequenos detallestecnicos mas propios de la configuracion del servidor que de la propia tareay que ademas, al ser tremendamente cambiantes, suponen una importantefuente de futuros fallos de ejecucion.

El coste de desarrollo queda minimizado con la utilizacion de lenguajesde programacion con el adecuado nivel de abstraccion y soporte transparentea los detalles de la navegacion. Un lenguaje de programacion de alto nivel deabstraccion, encapsulable, modular, con la posibilidad de definir facilmentereglas de extraccion de datos basadas en la regularidad estructural y con flexi-bilidad para estructurar esos datos extraıdos resulta primordial para reducirlos costes de desarrollo de estas aplicaciones.

1.5.2. Coste de ejecucion fallida

El coste de ejecucion fallida es el coste que supone un fallo de ejecucion alrealizar una tarea. Dicho coste suele depender de la relevancia de la tarea y noser dependiente de la forma en la que este programa pueda haber sido cons-truido. Este coste, no obstante, puede quedar convenientemente minimizadocon la utilizacion de medidas capaces de dotar de robustez a la navegacion,para que el programa trate de la forma mas adecuada los comportamientosno esperados de las comunicaciones o del servidor. Basicamente, para aplicarlas medidas de robustez se suele tener en cuenta la ubicacion del fallo y eltipo de tratamiento que se desea aplicar.

Ubicacion del fallo

Fallos en las comunicaciones Las comunicaciones con el protocoloHTTP pueden fallar si existe una sobrecarga en la conexion TCP/IP, elservidor al que se intenta conectar esta inaccesible o su respuesta tardaun tiempo considerado demasiado alto. Este tipo de fallos, normalmen-te notificados al programador en forma de excepciones o de codigosde error, pueden ser convenientemente tratados tanto desde el codigode las bibliotecas de la plataforma de ejecucion, como por codigo delusuario.

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 deprocesamiento de formularios, las aplicaciones del Web pueden funcio-nar puntualmente de forma incorrecta, devolviendo al cliente paginasde error inesperadas por este. En estos casos, el error no esta ni en laaplicacion de navegacion, ni en la conexion TCP/IP, sino en el servidor.Distinguir una pagina de error (que normalmente ha sido obtenida sinerrores desde el punto de vista del protocolo HTTP), de una paginaque confirme que se han procesado adecuadamente los datos enviadosen un formulario, no es algo realizable de forma generica, sino que de-pendera de la aplicacion y de su forma de devolver paginas de error.Aunque otras medidas son posibles, lo habitual suele ser tratar estoserrores insertando codigo que asevere que la respuesta de una peticionindique que esta ha sido correctamente procesada, tıpicamente con unasentencia del tipo assert. No insertar este tipo de comprobaciones puedeimpedir el tener garantizado que el servidor haya procesado adecuada-mente la peticion recibida. Por otro lado, la pagina devuelta puede noser una pagina de error y contener los datos que espera el cliente, pe-ro puede estar tan mal construida, que no se respeten algunas normasbasicas de construccion de paginas necesarias para su correcto proce-samiento. En esos casos, lo habitual suele ser corregir internamente loserrores de estas paginas antes de que sean manipuladas por el programapara que presenten ante el programador una estructura correctamenteprocesable.

Fallos del cliente por cambios en el servidor Por otro lado, conformea lo expuesto en el apartado 1.4.7, la regularidad estructural de las pagi-nas del servidor puede cambiar en cualquier momento al ser el Web unafuente semiestructurada de datos. Por este motivo, los programas denavegacion en el Web suelen incluir codigo para detectar los cambios deregularidad estructural en las paginas visitadas, de forma que, si estacambia, el programa pueda actuar en consecuencia. Lo habitual sueleser capturar el error y ejecutar reglas secundarias de extraccion de da-tos, o bien no capturar el error, propagando excepciones y confiando enque la regularidad estructural no cambie durante mucho tiempo. De-pendiendo del grado de robustez que se quiera anadir a estos programasy del coste asumible por el programador, se puede insertar un nume-ro mayor o menor de reglas secundarias que redunden en una mayorposibilidad de encontrar el dato buscado ante estos posibles cambios.

43

Naturaleza del tratamiento

Tratamiento generico Los tratamientos genericos son aquellos que pue-den implementarse para solucionar errores producidos en la navegacioncon cualquier servidor o aplicacion accesible desde el Web. Se trata defallos que son procesables en las rutinas de las bibliotecas de la plata-formas de ejecucion y que suelen permitir cierta parametrizacion desdeel codigo del cliente. Ejemplos de estos tratamientos genericos son al-gunas rutinas existentes, como [104, 58, 146], que permiten reparar laestructura de las paginas HTML mal construidas. Otros ejemplos sonlos temporizadores, que limitan el tiempo maximo admisible en el quedebe ser resuelta una peticion en el Web. Tambien puede llevarse acabo una polıtica de reintentos suaves, consistente en reintentar va-rias veces una peticion HTTP que no tenga efectos colaterales hastaque sea correctamente procesada, quiza con un numero maximo de in-tentos. Se denomina peticion sin efecto colateral a la que no modificadatos esenciales en el servidor y puede ser realizada multiples vecessin temor a sufrir efectos colaterales. Una peticion con efectos cola-terales, como por ejemplo una peticion de transferencia bancaria, nodebe ser reintentada multiples veces, salvo que se asuma el coste de sumultiplicidad. Algunas iniciativas como [114] proponen extensiones alprotocolo HTTP para que las peticiones con efectos colaterales puedanser realizadas completamente de forma atomica, o que, en caso de fallo,no tengan efectos colaterales, pero se trata aun de una iniciativa sinestandarizar y carente de soporte en el Web actual. Si todo esto falla,el usuario aun puede tratar el error en su codigo capturando las excep-ciones adecuadas o analizando los errores de estas llamadas con el finde aplicar un tratamiento particularizado.

Tratamiento particularizado Los tratamientos particularizados sonaquellos que no son aplicables de forma generica en bibliotecas, sinoque, al depender de las aplicaciones concretas que esten involucradasen la tarea, son mejor tratables en el codigo del programador (por loque su coste es tambien mas elevado). Son multiples las acciones detratamiento que puede emprender un programador. Por ejemplo, pue-de aplicar una polıtica de reintentos ante peticiones no correctamenterespondidas, como por ejemplo, cuando el servidor indica que esta so-brecargado de trabajo y responde con una pagina en la que indica quese reintente la peticion mas adelante. Tambien es posible inundar elprograma con reglas de extraccion alternativas y redundantes para quese pongan en ejecucion en el caso de fallos de las reglas principales de

44

extraccion de datos. Tambien es posible insertar codigo para asegurar-se de que cada peticion ha sido respondida correctamente y lanzar unmensaje de error y aviso al programador cuando no sea ası. En la ta-bla 1.8 aparece un resumen de las medidas de robustez mas habitualesaplicadas segun el origen del fallo.

Sıntoma Tratamiento generico Tratamiento particular

Lugar Varios Plataforma de ejecucion Codigo de programador

En comunicaciones Excepciones, errores Temporizadores, reintentos suaves Reintentos

Fallos del servidor Paginas de error Reparacion de paginas Asserts, reintentos

Cambios de estructura Fallos en las reglas No Reglas secundarias, asserts

Cuadro 1.8: Resumen de medidas de robustez segun origen del fallo

1.5.3. Coste de mantenimiento

Los programas de navegacion generica no adaptada apenas necesitan la-bor de mantenimiento. Esta esta apenas centrada en algunos browsers, paralos que frecuentemente se lanzan nuevas versiones que mejoran imperfeccionesde sus predecesoras o mejoran alguna pequena funcionalidad. Las modifica-ciones en la regularidad estructural de las paginas no las afecta, como sı lohace a las aplicaciones de navegacion generica adaptada y particularizada.En el caso del Web Semantico, por ejemplo, esas modificaciones deben que-dar convenientemente reflejadas en los metadatos del sitio Web, de formaque el mantenimiento se reduce a una labor declarativa. Sin embargo, en losprogramas de navegacion particularizada, este mantenimiento es una labormuy costosa que debe realizarse habitualmente en el mismo codigo del pro-grama. Por muchas medidas de robustez que se quieran anadir para alargarla vida del programa, inevitablemente algun cambio no contemplado en laregularidad estructural acabara apareciendo tarde o temprano, invalidandoalguna de las suposiciones asumidas por el programador. La labor de man-tenimiento es en estos casos la unica opcion. Con el fin de minimizar costes,suele ser deseable que el mantenimiento lo pueda realizar personal que nonecesariamente tenga una elevada preparacion. Es por ello que resulta tre-mendamente importante que los programas de navegacion particularizadacumplan tres importantes requisitos: legibilidad, brevedad y simplicidad.

45

Legibilidad

Las personas que realizan el mantenimiento de los programas no tienenpor que ser necesariamente las mismas que participaron en su desarrollo.Incluso aun cuando sı sean las mismas personas, las medidas de robustezanteriormente mencionadas pueden haber sido efectivas durante bastantetiempo y el programador que quiera realizar una labor de mantenimientopuede haber olvidado los detalles en los que se baso para su construccion.Por todas estas razones y por muchas otras, la legibilidad de los programasresulta primordial. Para mejorar esa legibilidad, es conveniente usar tecnicasde programacion con un nivel de abstraccion adecuado para la descripcion detareas y que preferiblemente sean conocidas por mucha gente y esten basadasen estandares que eviten la ambiguedad, de forma que cualquier pequeno tro-zo de codigo pueda ser facilmente entendido por las personas que lo analicensin necesidad de tener un conocimiento completo del problema.

Brevedad

La legibilidad no es el unico factor que influye en el coste de mantenimien-to de estos programas. Un wrapper escrito en C o Java puede ser facilmentelegible al estar escrito en un lenguaje de programacion conocido por muchagente, pero si no usa unas bibliotecas de soporte con el adecuado nivel deabstraccion, con primitivas que reflejen cada una de las acciones de la tareaen pocas lıneas de codigo, el tamano del programa final puede facilmentedispararse. Para conseguir programas breves, lo deseable es poder disponerde un potente conjunto de primitivas capaces de reflejar cada paso de la tareaen unas pocas lıneas de codigo.

Simplicidad

Una buena plataforma de desarrollo se caracteriza por la flexibilidad ypotencia de sus primitivas de construccion, las cuales deben ser capaces depermitir a su vez la suficiente parametrizacion para poder controlar todoslos aspectos tecnicos de bajo nivel que requieran ser atendidos. Sin embargo,esa potencia suele conseguirse implicando cierta complejidad de manejo porparte del programador, por lo que es deseable ademas de las propiedadesanteriores de legibilidad y brevedad, la suficiente simplicidad del programapara que cualquier cambio que se realice en el mismo no acabe afectandoa demasiadas lıneas de codigo. Por esa razon, es deseable usar mecanismosque, permitiendo la programacion de complejos algoritmos de navegacion y

46

manipulacion de datos, mantengan lo mas simple posible los programas conel objetivo de que sea poco costosa la labor de localizar y modificar las lıneasde codigo implicadas en un cambio dentro de uno de estos programas. Lasimplicidad de mantenimiento se refleja en la capacidad de que cualquiercambio pueda facilmente localizarse sobre una pequena parte del programa(una lınea de codigo es lo ideal) sin que el cambio implique necesariamenteuna revision del resto del programa. Es importante que la plataforma deejecucion pueda indicar el lugar donde se producen los fallos con el fin detener 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-gacion particularizada para los sitios Web en los ultimos anos. Buena partede ellos aparece resumida en el capıtulo 3. Todos ellos coinciden en presentarsoluciones con serios costes de desarrollo, problemas de aplicabilidad endiversas fuentes de datos (dadas sus enormes heterogeneidades), una elevadafragilidad ante errores y cambios en el servidor, y, principalmente, elevadoscostes de mantenimiento que sin duda han influido en su escasa utilizacion.

Por estas razones, nuevas formas avanzadas de recuperacion y tratamien-to de la informacion para la navegacion Web particularizada, aplicable aldeep Web que se sabe localizada en el Web legado, con las caracterısticasmencionadas en el apartado 1.4, necesitan ser aplicadas, de forma que seaprovechen los avances de los ultimos estandares orientados al Web, con elfin de dar soluciones efectivas a los problemas anteriormente mencionadosminimizando 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 elapartado 1.6. Con el fin de facilitar la automatizacion de tareas en el Weblegado, tanto basado en HTML como en cualquier formato XML, se persi-guen metodos avanzados, para reducir el coste de desarrollo y mantenimientode aplicaciones de automatizacion, de forma que a su vez estas sean lo masrobustas posibles ante posibles errores en las aplicaciones que ejecutan enlos servidores y ante la orientacion a la visualizacion de las paginas y a sus

47

cambios de regularidad estructural. A continuacion se detallan los objetivosde esta tesis:

1. Proponer unos mecanismos de desarrollo de programas que nave-guen automaticamente en el deep Web, de forma que el coste de de-sarrollo de estas aplicaciones, mencionado en el apartado 1.5.1, se veasensiblemente reducido frente a las opciones existentes actualmente y laautomatizacion de tareas en el Web por medio de programas de navega-cion particularizada sea ası asequible a un mayor numero de personas.Estos metodos de construccion deberan tener un adecuado nivel deabstraccion, con el fin de favorecer su comprension, y, en lo posible,permitir su utilizacion por herramientas que ayuden al programador ensu desarrollo.

2. Proporcionar una plataforma que no solo pueda usarse con un elevadonivel de abstraccion y comprensible por los usuarios conforme al ob-jetivo anterior, sino que ademas sea convenientemente parametrizabley con el mayor cubrimiento posible a la ejecucion de aquellas accionesque implıcitamente el browser realiza de forma transparente evitandoen lo posible que el usuario sea consciente de ello. Dichas acciones, queaparecen detalladas en el apartado 2.1, son necesarias para mantenercorrectamente el dialogo y el concepto de sesion con los servidores Webcon los que se dialoga. El fin de esta mejora consiste en abstraer al usua-rio del mayor numero posible de detalles de bajo nivel, permitiendole,sin embargo, tener el control de los mismos cada vez que lo necesite.Consiguiendo que la gestion de estas acciones genericas de cualquiersitio Web queden convenientemente encapsuladas y no formen partedel codigo principal de los programas, los programas se mantienen lomas compactos posible.

3. Si bien es recomendable que la plataforma de navegacion se haga cargode las acciones de las que no es normalmente consciente un usuario quenavega manualmente usando un browser, las acciones que sı tras-cienden al usuario, y que aparecen en el apartado 2.2, como seguirun enlace o rellenar un formulario, deben poder ser activables de la for-ma mas sencilla posible por parte de este. Lo ideal es que cada una deestas acciones pueda ser especificada con una accion sencilla en el casode que use una herramienta (como por ejemplo en un navegador), o conun mınimo numero de lıneas de codigo, en el caso en el que emplee unlenguaje de programacion, usando a ser posible un conjunto pequenopero potente de constructores flexiblemente parametrizables.

48

4. Por otro lado, para las acciones mas complejas que debe especificarel usuario, que se encuentran detalladas en el apartado 2.2 y que nor-malmente se corresponden con las acciones de procesamiento de datosmencionado en el apartado 2.2.6, puede requerirse la especificacion dealgoritmos complicados. Por ese motivo puede ser necesario la progra-macion de varias lıneas de codigo, con sentencias de programacion comollamadas a funciones que manipulen complejas estructuras de datos,diversas condiciones que impliquen varios posibles casos alternativosa tener en cuenta, bucles que se aniden entre sı o con las sentenciascondicionales y datos de diversos tipos. Lo habitual es que el codigoque procese los datos de una tarea sea muy particular y dependientede esta y de la forma en la que el usuario desee realizarla (por ejemplo,seleccionar la mejor oferta de leche fresca de un catalogo segun varioscriterios, como marca, precio, tamano del envase y gastos de envıo). Porello, lo mas aconsejable consiste en permitir la programacion de ruti-nas definibles por el usuario en algun lenguaje de programacionampliamente conocido, como Java, u otros lenguajes igualmente reco-nocidos, de forma que esa rutina pueda ser convenientemente invocadadesde el codigo de programa. De esta forma, pasando por argumentoa esa rutina los datos extraıdos y estructurados de las paginas alma-cenados en repositorios programables (variables, ficheros, ...), la rutinapuede manipular los datos obtenidos del Web.

5. Proporcionar mecanismos adecuados para favorecer la robustez delos programas ante fallos en las conexiones TCP/IP y adaptabilidadante cambios en las paginas, reduciendo el coste de ejecucion falliday que aparece detallado en el apartado 1.5.2. El objetivo consiste enincluir medidas de robustez ante fallos en las comunicaciones y antecambios y fallos en las aplicaciones accedidas por el Web. Estas medidasse plasmaran tanto en la plataforma de soporte a la ejecucion comoen constructores directamente utilizables por el usuario en su propiocodigo. Dicha funcionalidad no aparece en los browsers actuales, aligual que tampoco es comun encontrarla en otros tipos de plataformas.Tambien se debe contemplar una polıtica de alternativas de uso en elcaso de que se encuentren enlaces rotos.

6. Las medidas de robustez pueden amortiguar los efectos de los cambiosde regularidad estructural del Web y pueden alargar el tiempo de vidade las aplicaciones de navegacion automatizada. Sin embargo, debidoal caracter siempre dinamico del Web, es necesario un mantenimien-to para cuando esas medidas fallen. Por ello se pretende proporcionar

49

mecanismos para la minimizacion del coste de mantenimiento de lasaplicaciones de navegacion automatizada, que aparece detallado en elapartado 1.5.3, de forma que este mantenimiento quede reducido a unamınima labor, con un coste sensiblemente inferior a las alternativas uti-lizables hasta el momento, de forma que la mayorıa de las acciones demantenimiento consistan en la modificacion de una accion sencilla, delas reflejadas en el apartado 2.2, facilmente localizada y que normal-mente afecte a muy pocas lıneas de codigo del programa de usuario, sinser necesario revisar el programa completo.

7. Permitir que esa automatizacion se pueda aplicar a practicamente cual-quier fuente o aplicacion del Web legado, es decir, a las tradicionalespaginas HTML orientadas a la visualizacion y cuyos principales atri-butos aparecen detallados en el apartado 1.4 y que mayoritariamenteabundan en el Web actual. La automatizacion de tareas en el Web sedebe poder aplicar no solo a las paginas que, por estar bien construidas,les sean inmediatamente aplicables las modernas tecnologıas de mani-pulacion de documentos y extraccion de datos, sino tambien a aquellasque esten mal construidas (dentro de unos lımites que las permitan serconvenientemente reparadas). Para ello, se incluiran en la plataformade ejecucion metodos capaces de reparar automaticamente esos erroresde las paginas recuperadas de los servidores. Igualmente, deberan pro-porcionarse mecanismos, si no en la plataforma, al menos a disposiciondel usuario, para solventar los problemas derivados del hecho de queesas paginas esten pensadas exclusivamente para el acceso por mediode un conjunto limitado de browsers graficos, o con capacidad de accio-nar eventos especiales desde rutinas embebidas en applets, animacionesFlash o, principalmente, rutinas JavaScript.

8. Permitir aplicar ese tratamiento automatizado de la informacion men-cionado anteriormente tambien a documentos de cualquier lenguajedefinido sobre XML, siempre que al menos su esquema sea conociblea priori por el programador para las tareas mas complejas que ası lorequieran. Ası pues, se pretende que, aunque la mayor parte de las prue-bas de implementacion de esta tesis se realizara sobre paginas HTMLdel Web legado, ese formato concreto no deje de ser solo un ejemploparticular de navegacion sobre documentos en el Web, siendo posiblesigualmente otros lenguajes definibles en XML, no ya solo algunos de lasya conocidos (como WML + WMLScript [61], SMIL [125], RDF [123],RSS [16], SVG [124], MathML [120], ...), sino cualquier otro lenguajeXML en general, actual o futuro, es decir, ya inventado o aun por inven-

50

tar, independientemente de si su uso esta centrado en la visualizacionen un browser o si tiene otra finalidad.

1.8. Estructura de la memoria

El capıtulo 2 presenta un analisis de los principales aspectos de la au-tomatizacion en el Web. Para poder realizar una efectiva automatizacionde tareas en el Web es preciso analizarlas primero, reconociendo sus par-tes o acciones basicas, examinando las alternativas aplicables a cada una deellas, teniendo en cuenta las caracterısticas distintivas de la materia tratada(los datos del Web). Para cada parte, se analizan sus principales ventajas einconvenientes desde los puntos de vista de aplicabilidad y de coste de im-plantacion, con el fin de poder escoger para cada problema la solucion masadecuada. En el capıtulo 3 se describe el estado del arte de la automatizacionde tareas en el Web, analizando desde sus precedentes hasta las tendenciasactuales. Un estudio sobre las soluciones tecnologicas existentes, clasificadassegun 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 lasıntesis de aplicaciones para la automatizacion de tareas en el Web que,basandose en las ideas del capıtulo 2, presentan unos mecanismos de cons-truccion de estas aplicaciones capaces de ser operables en el Web legado yque tienen ademas la aportacion de estar basadas en estandares que reducensensiblemente los costes de implantacion y mantenimiento. El capıtulo 7 in-troduce unos ejemplos que demuestran la aplicabilidad de estas propuestas atareas definidas sobre sitios Web conocidos. Finalmente se enumeran algunasconclusiones del trabajo ası como lıneas de actuacion para trabajos futuros.

51

Capıtulo 2

Analisis de tareas Web

Cuando la gente navega por el Web, aparte de por ocio o entretenimiento,suele hacerlo persiguiendo un fin concreto, un proposito particular. Ejemplosde tareas Web quiza no tan complejas como las del apartado 1.2 pueden verseen la siguiente lista:

Obtener un documento o un conjunto de ficheros multimedia

Leer un periodico

Usar un buscador (o varios)

Enviar postales electronicas

Leer correo Web, lo cual implica las subtareas de identificarse, listarlos mensajes, visitar siguientes, responder, ...

Consultar disponibilidad de habitaciones en un hotel, suponiendo queofrezca esta informacion online

Comprobar que las paginas publicadas en un sitio Web cumplan ciertaspropiedades (no tener enlaces rotos, adherirse a algun formato particu-lar, ...)

Comprar billetes de avion o de tren

Comprar en una tienda electronica, lo cual implica buscar cada artıculo,anadirlo al carrito, estar atento a las ofertas, pagar, ...

Reservar salas de reuniones en la intranet de una organizacion

53

Presentar la declaracion de la renta

Poner una denuncia en la policıa

Y muchas mas

Segun crece el Web, con cada vez un mayor numero de datos y aplicacionesaccesibles, el numero de tareas igualmente aumenta. De hecho, el crecimientodel Web no es el unico impulsor del aumento de tareas realizables en elWeb. Ultimamente comienzan a ser cada vez mas necesarias aplicacionesque combinen la informacion de varios sitios Web, de la misma forma enla que se combinan datos de bases de datos verticalmente fragmentadas ydistribuidas [52]. Esas tareas empiezan a ser inmanejables para ser realizadasmanualmente.

En otras ocasiones, por el contrario, sobre una misma aplicacion accesibleen el Web es deseable ejecutar varias tareas posibles. Pese a las reticenciasde quien no quiere que sus datos sean comparados de forma explıcita por untercero, es poco extrano que un comparador de ofertas como [3] o de aso-ciaciones de consumidores soliciten al Web de un banco la TAE de su mejordeposito bancario a seis meses para compararla con la de su competencia. Dela misma forma, tampoco deberıa resultar extrano que ese mismo dato acabesiendo proporcionado a otra aplicacion encargada de calcular el TAE medioofrecido por los principales bancos espanoles para un estudio estadıstico. Lautilidad que el dato tenga en la tarea es algo que depende mucho de la tareay poco del servidor.

Para poder automatizar las tareas en el Web es preciso analizarlas pri-mero, diseccionando las partes en las que estan estructuradas y reconociendo,de cada una de esas partes, sus capacidades de automatizacion y sus princi-pales retos. Ası, en una etapa posterior, se podran aprovechar esas cualidadesde la mejor forma posible para sintetizar aplicaciones que automaticen el Webde forma mas eficiente y menos costosa.

Acciones basicas

A pesar de la clara e intrınseca heterogeneidad del Web, mencionadaen el apartado 1.4 y manifiesta, no solo en sus datos, sino tambien en susformas de presentacion, lo cierto es que, por debajo de toda esta visibleheterogeneidad, los principios bajo los que se sustentan las tareas en el Webson sencillos. De hecho, la simplicidad de manejo de cualquier browser no esmas que un fiel reflejo de que, efectivamente, las partes de una tarea realizable

54

con una navegacion en el Web se reducen a un conjunto limitado y sencillode acciones basicas.

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 mayorel numero de aplicaciones que se encuentran disponibles a traves del Web.Sin embargo, los innumerables servicios del Web, sean estos simples pagi-nas o bien complejas aplicaciones manejadas por varios formularios, pese asus aparentes diferencias visuales, tienen en comun el hecho de estar todosellos fundamentados en alguna secuencia (o secuencias) de un reducido con-junto de acciones basicas 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 basicas. Por ejemplo, una tıpicatarea de chequeo de cuentas de correo electronico en un portal de correoWeb puede implicar una accion basica de solicitud de un documento dondeaparece un formulario de identificacion que, una vez rellenado y enviado alservidor, 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ıdosy no leıdos. Cada uno de esos mensajes a su vez puede ser leıdo si se sigueconvenientemente un enlace. Tambien puede ser borrado, si se chequea suopcion de seleccion correspondiente y despues se pulsa al boton de borrado.Otras acciones, como responder o reenviar tambien son posibles. Secuenciasdistintas de este reducido conjunto de acciones basicas constituyen el queha-cer diario del trafico Web actual al que dan servicio los numerosos servidoresWeb conectados a la Red. Para la realizacion de una tarea Web, el usuariodebe realizar la ejecucion en secuencia ordenada, de cada una de las accionesbasicas que conforman esa tarea.

Tipos de acciones basicas

Las acciones basicas que forman parte de una tarea no son todas de lamisma naturaleza, pudiendo distinguirse entre acciones basicas implıcitas yacciones basicas explıcitas.

Las acciones basicas implıcitas son aquellas que no deben trascender alusuario y que son realizadas automaticamente por el browser en una nave-gacion manual. En ellas, el usuario no es necesariamente emprendedor de laaccion. Se trata de acciones que se encuentran gestionadas internamente porlos browsers, sin que el usuario deba proporcionar instrucciones explıcitamen-te para ello. Ejemplos de acciones basicas implıcitas son todas las referentes

55

a la gestion de cabeceras HTTP (gestion de cookies, redireccionamientos,identificacion de usuario y de agente de usuario, preferencias en los formatosaceptados o en el idioma, ...), o las que se deben realizar necesariamente conel contenido del cuerpo de la respuesta HTTP (correccion interna de erroresde estructura en el documento, seguimiento implıcito de enlaces, accionesembebidas en lenguajes de scripting, ...).

Las acciones basicas explıcitas son el conjunto de acciones que, en unanavegacion manual, deben trascender al usuario, ya que el browser no puedeo no debe emprenderlas por su cuenta. Es por ello que el browser debe espe-rar instrucciones del usuario, tıpicamente de forma interactiva, para podercontinuar. De esta forma, el usuario se acaba convirtiendo necesariamenteen el emprendedor de la accion. Ejemplos de acciones basicas explıcitas sonel seguimiento explıcito de enlaces, el rellenado y envıo de formularios, laextraccion de datos relevantes del documento o el procesamiento que deberealizarse con los datos recolectados.

Como puede apreciarse, las acciones basicas explıcitas tienen un nivel deabstraccion mas elevado y cercano al usuario, mientras que las acciones basi-cas implıcitas tienen un nivel de abstraccion mas bajo y mas cercano a losaspectos tecnicos de los protocolos HTTP y de los formatos de publicacionen el Web. Como puede comprobarse en la tabla 2.1, que refleja las principa-les diferencias entre las acciones basicas explıcitas e implıcitas, las primerasafectan constantemente al usuario de la navegacion manual. Por el contra-rio, esas acciones son atendidas por un programa que sustituye al usuario enlas aplicaciones de navegacion automatizada, tanto generica como particu-larizada. Las acciones implıcitas, por su parte, disenadas para ser resueltassin conocimiento explıcito del usuario, son transparentemente gestionadaspor los browsers en la navegacion manual. En el caso de la navegacion au-tomatizada, lo deseable serıa que la plataforma de navegacion (el programaque navegue basandose en metadatos, o las bibliotecas usadas para la cons-truccion del programa de navegacion particularizada) ejecutaran todas esasacciones con la misma transparencia de un browser. No obstante, la faltade buenas plataformas de navegacion automatizada para el Web con soportepara todas estas posibles acciones muchas veces acaba obligando al progra-mador a introducir su propio codigo de tratamiento para suplir las carenciasde las plataformas de navegacion. Ello suele ser una fuente de encarecimientode costes de estos programas, segun el nivel de soporte que de estas accionestenga la plataforma.

56

Accion basica explıcita Accion basica implıcita

Navegacion manual Usuario Browser

Navegacion automatica generica no adaptada Robot Segun programa

Navegacion automatica generica adaptada Metadatos Agente Web Semantico

Navegacion automatica particularizada Programador Bibliotecas+programador

Nivel de abstraccion Cercano a la tarea Cercano a formatos y protocolos

Ejemplo Enviar un formulario relleno Gestionar una cookie

Cuadro 2.1: Diferencias entre acciones basicas explıcitas e implıcitas

2.1. Acciones basicas implıcitas

Las acciones basicas implıcitas son realizadas por muchos browsers sinque sus usuarios sean muchas veces conscientes de ello. Pese a su relativa-mente bajo conocimiento por muchos usuarios, las acciones basicas implıcitasson necesarias para aspectos tan fundamentales como el mantenimiento desesiones HTTP, las restricciones de acceso a contenidos, la adecuacion delWeb a preferencias del usuario, o la ejecucion de multiples comportamientosinternos necesarios para la correcta navegacion por cualquier pagina accesi-ble desde el Web. A continuacion aparecen detalladas algunas de las accionesbasicas implıcitas mas importantes.

2.1.1. Gestion de cabeceras HTTP

El protocolo HTTP establece la posibilidad de intercambiar en varioscampos situados en sus cabeceras, informacion relativa a las peticiones yrespuestas intercambiadas. Estas cabeceras pueden ser usadas tanto por elcliente como por el servidor HTTP para obtener informacion que necesitendel otro extremo con el fin de mantener un dialogo correcto. La mayorıade esas cabeceras permanecen inalterables a lo largo de ese dialogo, perootras muchas van cambiando a lo largo de ese dialogo, por lo que deben seradecuadamente gestionadas para poder realizar correctamente la peticionHTTP.

En la tabla 2.2 aparecen las principales cabeceras que deben gestionarlos clientes del protocolo HTTP. Cada una de esas cabeceras tiene su es-pecial importancia. Por ejemplo, algunos servidores Web presentan paginasde error cuando son accedidos por programas que no acreditan ser MicrosoftInternet Explorer en la cabecera de identificacion del cliente, pese a que suscontenidos sean en realidad navegables por otros browsers. En otros casos, no

57

especificar correctamente una cookie o el campo Referer en una peticion a unservidor puede suponer la perdida de la sesion con el servidor. No indicar quese acepta HTML como formato, puede implicar la suposicion por parte delservidor de que debe responder con documentos en formato WML o quiza entexto plano. No indicar que el idioma preferible es el espanol puede implicarque las paginas vengan por defecto en ingles.

Nombre de cabecera Emitida por Significado Ejemplo

User-Agent Cliente Identificacion 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 Identificacion 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 peticion text/html

Content-Length Cliente o Servidor Tamano del documento o peticion 12354

Cuadro 2.2: Principales cabeceras gestionadas por los clientes del protocoloHTTP

2.1.2. Gestion de errores en la comunicacion con elservidor

Las comunicaciones con el protocolo HTTP pueden fallar si existe unasobrecarga en la conexion TCP/IP, el servidor al que se intenta conectaresta inaccesible o su respuesta tarda un tiempo considerado demasiado altopara lo razonable por la tarea. Dependiendo de la gravedad del fallo (no es lomismo que haya un fallo de transferencia en una pagina HTML que lo hayaen la transferencia de una de sus imagenes), el error debera hacerse constarcon mayor o nivel de severidad al usuario o al programa que dirija la tareapara que tome las medidas que considere oportunas.

2.1.3. Reparacion interna de paginas mal construidas

Una vez obtenida una pagina del Web y solventados los problemas decomunicacion con el servidor, debe procederse a analizar la respuesta, nor-

58

malmente contenida en una pagina HTML. Lamentablemente, tal y como semencionaba en el apartado 1.4.3, muchas de las paginas que se encuentranen el Web no cumplen el conjunto de normas basicas de construccion. Poresa razon, resulta necesario reparar internamente esos errores con el fin depermitir el analisis de esa respuesta por el cliente, ocultando al usuario esoserrores en la medida de lo posible. Este trabajo extra en el lado del clientedebe ser realizado debido a la tradicional permisividad ante errores en laspaginas obtenidas de los servidores.

2.1.4. Seguimiento implıcito de enlaces

Una vez correctamente analizada una pagina obtenida del Web, es nece-sario identificar todos aquellos elementos multimedia que forman parte de lamisma con el fin de seguir los enlaces que implıcitamente deban visitarse. Elseguimiento de enlaces puede ser entendido como implıcito, si es el browserel que decide recuperar ese documento, quiza porque forme parte integrantedel que acaba de ser descargado y analizado, o explıcito, si es el usuarioel responsable de la activacion del enlace. Por ejemplo, los enlaces que enHTML se definen con las etiquetas a o area son normalmente seguidos deforma 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 sedefinen con etiquetas como frame, img, script, link u object, es el browserquien determina si deben ser seguidos de forma explıcita o implıcita. Si, porejemplo, se desea emular a un browser grafico como Mozilla [12] o MicrosoftExplorer [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 grafico normalmente descar-ga implıcitamente de cualquier pagina del Web todos sus componentes, comoson los marcos, imagenes, scripts externos y hojas de estilo externas. Por elcontrario, cuando se desea emular a un browser textual como Lynx [10], elseguimiento de los anteriores enlaces se vuelve, si no explıcito, muchas vecesincluso inaccesible, porque se entiende que hay documentos enlazados que noson adecuadamente procesados por el browser. En la tabla 2.3 puede verseun esquema resumido del comportamiento de estos enlaces dependiendo delbrowser en el que se utilizan.

59

Browser a, area img, frame link script, object

Grafico 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. Ejecucion de comportamientos embebidos en laspaginas

Una vez han sido correctamente descargados todos los elementos multi-media de las paginas, los elementos dinamicos de las mismas (rutinas Ja-vaScript o JScript, Applets, controles ActiveX, animaciones en Flash, otrosplugins, ...) pueden empezar a funcionar. Se trata de las rutinas que, me-diante pequenos programas insertados en las paginas Web y, gracias a uninterprete, maquina virtual o plugin embebido en el browser, permiten al di-senador de la pagina tener acceso a ciertos recursos del browser del usuario.Las rutinas JavaScript, que suelen ser las mas usadas, permiten controlarun amplio espectro de acciones tıpicamente manejadas por el browser. Porejemplo, son capaces de manipular aspectos tan diversos como las propie-dades de visualizacion de los elementos de las paginas (tamanos, posiciones,colores, visibilidad, ...) , la descarga condicionada de elementos multimediade una pagina, manipular la base de datos de cookies o modificar al gustodel disenador de la pagina la semantica del comportamiento de los controlesde los formularios. Tanto es ası, que muchas paginas resultan innavegablessi el browser con el que se las intenta acceder no dispone de un interpreteajustado a las especificaciones del JavaScript utilizado en la pagina.

Si la plataforma de navegacion no dispone de estos interpretes o estosplugins, los comportamientos embebidos no son ejecutables. Ello puede nosuponer un problema serio para el procesamiento de paginas con comporta-mientos embebidos que solo afecten a aspectos de visualizacion, siempre queexistan contenidos alternativos ofrecibles al usuario o, simplemente no apor-ten datos relevantes. Sin embargo, puede suponer serios problemas para laaccesibilidad cuando esos comportamientos tienen un papel en la navegacion.

Este tipo de rutinas tiene una caracterıstica muy importante desde elpunto de vista de su automatizacion. Al tratarse de comportamientos quevienen pre-programados en elementos multimedia de las paginas, su compor-tamiento, no se encuentra por lo tanto pre-programado en ningun browser,es decir, no es conocible a priori, por lo que para su correcto funcionamientose necesita del correspondiente soporte para la ejecucion. Sin embargo, dis-

60

poner de ese soporte puede ser difıcil o costoso para muchos usuarios que nosiempre lo encuentran disponible en browsers o plataformas de navegacionautomatizada.

2.1.6. Soporte para otros protocolos

En ocasiones, se deben enviar mensajes por correo electronico. En otrasocasiones, algunos documentos deben recuperarse usando otros protocoloscomo FTP. Tambien es posible que sea necesario acceder a ciertas paginasmediante protocolos seguros, principalmente SSL. Forma parte de las accio-nes implıcitas de la plataforma de navegacion saber gestionar adecuadamenteestos protocolos, de forma que el usuario no sea consciente de esos detallesde bajo nivel de cada uno de ellos.

2.1.7. Tratamiento adecuado de cada campo de formu-larios segun su forma de rellenado

A la hora de asociar valores a los campos de los formularios, es necesariotener en cuenta las reglas de rellenado de cada campo del formulario reflejadasen la tabla 2.4. Por una parte, debe considerarse el tipo de valor que indicala naturaleza del valor asociado a cada campo del formulario. Principalmen-te, pueden distinguirse textos libres especificados por el usuario, ficheros quedeben ser enviados del cliente al servidor y valores ya especificados en lapagina por el servidor. Por otra parte, debe considerarse la especificacion derellenado por el usuario, es decir, aquello que el usuario debe proporcionarpara que dicho campo de formulario quede adecuadamente relleno. Princi-palmente, puede distinguirse entre el rellenado directo, que consiste en elque el usuario proporciona directamente el valor con el que desea rellenarel formulario, o bien un rellenado indirecto, en el que el usuario especificaun criterio de seleccion que sirve para decidir las opciones que deben quedarmarcadas y las que no. El criterio de seleccion consiste normalmente en uncriterio booleano que, aplicado a cada una de las opciones seleccionables,indica si esa opcion debe admitirse o no como seleccionada. Los criterios deseleccion pueden ser de dos tipos, sencillos o multiples, dependiendo de si,cuando son aplicados a un conjunto de varias opciones, deben indicar una ovarias de esas opciones como seleccionadas. Este acomodamiento, o conjuntode restricciones establecidas sobre el conjunto de valores posibles con los quese puede rellenar un formulario, se encuentra ya facilitado por los browsers yes una de las acciones basicas 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 seleccion

select.multiple, input.checkbox Valores especificados por el servidor Criterio de seleccion (multiple)

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 seleccion

Cuadro 2.4: Tipo de rellenado de campos de formularios HTML

2.1.8. Creacion de query-string a partir de un formu-lario relleno

Antes de enviar a un servidor un formulario relleno, es necesario codificarla informacion que encierra para su envıo, de forma que sea correctamenteprocesable en el servidor. Esta informacion codificada, denominada query-string, es enviada como parte de la correspondiente peticion HTTP al servi-dor. En el caso de que la peticion sea del tipo POST, el query-string debeformar parte del cuerpo de la peticion, por lo que ira aislado aparte de lascabeceras HTTP. Por el contrario, si el formulario se envıa con un comandoGET, el query-string es concatenado al final de la URL que se desea visitar.

La accion de codificacion de formularios rellenos debe tener en cuenta suestructura, 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 establecerparejas campo-valor, independientemente de como se hubieran rellenado loscampos de ese formulario. Por otra parte, en la codificacion del query-stringpuede frecuentemente jugar tambien 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 pulsadostampoco deben ser enviados al servidor.

62

2.2. Acciones basicas explıcitas

Las acciones basicas explıcitas son las que definen los pasos en los queesta involucrado el usuario durante la ejecucion de una tarea en el Web. Rea-lizarlas con un navegador suele ser un buen punto de partida para empezar aconstruir el esqueleto basico de una aplicacion de navegacion automatizada.Las tareas del Web son, por lo tanto, especificadas basandose en este tipode 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 automatizacion desde los puntos de vista dela navegacion manual y de la navegacion automatica. Como puede apreciar-se, desde el punto de vista de la navegacion manual, todas ellas, en mayor omenor medida, con mayor o menor soporte por parte del browser, son respon-sabilidad del usuario. Desde el punto de vista de la navegacion automatizada,estas acciones deben recaer en un programa, por lo que se mencionan las par-tes de ese programa que estan afectadas por cada una de esas acciones. Porejemplo, las acciones de seguimiento de enlaces y envıo de formularios ape-nas suelen suponer la correspondiente llamada a las primitivas GET o POSTdel protocolo HTTP, a la que solo hay que parametrizar convenientemente.Sin embargo, el resto de las acciones basicas explıcitas no tiene un coste tanreducido como ese habitualmente, ya que, al ser dependientes de la tarea,deben ser programadas con codigo de usuario.

Accion basica explıcita Navegacion manual Navegacion automatizada

Extraccion de datos relevantes Usuario Reglas de extraccion (regularidad estructural)

Estructuracion de datos semiestructurados Usuario Repositorios estructurados

Seguimiento explıcito de enlaces Usuario + Browser Llamada a primitiva GET

Rellenado de formularios Usuario + Browser Metadatos, codigo 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 basicas explıcitas

2.2.1. Extraccion de datos relevantes

La extraccion de datos relevantes implica la seleccion de los datos consi-derados relevantes embebidos en las paginas Web y su extraccion para poste-riores procesamientos. Estos datos, cuya relevancia se encuentra descrita en

63

el apartado 1.4.4, se suelen encontrar repartidos por varias paginas o marcos.Cuando no se trata de ficheros multimedia, lo normal es que se encuentrenen forma de simple informacion textual (e.g.: precios, titulares, mensajes,telefonos, direcciones, cotizaciones, fechas, cantidades, ...) tıpicamente em-bebida en paginas HTML junto con otra mucha informacion que puede noser relevante para la tarea (publicidad, marcado estructural orientado a lavisualizacion, datos relevantes para otras tareas, ...).

La capacidad de extraer datos del Web, es sin duda de las mas importan-tes, pues juega un papel importante en todos los pasos ejecutados entre lanavegacion por el Web. Seguir un enlace implica seleccionar en primer lugarel enlace que debe ser seguido y extraer de el la direccion a la que apunta.Enviar un formulario implica seleccionar en primer lugar todos los camposque forman parte del mismo y rellenar cada uno conforme a su naturalezay a los objetivos del usuario, para despues activar la accion del formulario.Otros procesamientos mas complejos definidos por el usuario, como compa-raciones, integracion de datos y otros comportamientos, necesitan tambienla realizacion de complejas extracciones de datos. De esta forma se prescindede todos aquellos datos que aparecen en las paginas pero que no intervienenen la tarea.

En el caso de la navegacion manual basada en browsers, el usuario debevisualizar normalmente pantallas enteras para poder detectar visualmentela informacion que le interesa. Es normal que para ello deba examinar variaspantallas y ventanas o hacer scrolling. Desafortunadamente, los browsers dehoy en dıa no reciben especificaciones acerca de cuales son los datos relevan-tes para los usuarios y cuales pueden ser ignorados, con el fin de destacarlos primeros y ocultar los ultimos (esta labor quiza podrıa ser emprendidacon scripts definibles por los usuarios aplicados a documentos del Web, peroello no es una solucion siempre factible). La unica funcion de un browseres mostrar un documento de la mejor forma posible y ejecutar sus orde-nes interactivas, siendo imposible destacar para cada usuario los datos queson interesantes para el y su tarea. Las opciones de destacado de partes dedocumentos estan a merced de los autores de los documentos, no de sus lec-tores, algo que sin embargo algunos trabajos como [48] sı han logrado hacerbasandose en una personalizacion que no todos los sitios Web ofrecen. Aun-que la simple lectura de textos sobre las pantallas de un ordenador puedeser suficiente para algunos usuarios a la hora de pasar a realizar su siguien-te accion, lo cierto es que el Web se caracteriza por presentar demasiadainformacion que presenta costes prohibitivos para ser procesada por perso-nas, razon por la cual una separacion automatizada de los datos relevantesrespecto del resto de datos no relevantes resulta conveniente en esos casos.

64

En el caso de la navegacion automatizada, la extraccion de datos noesta basada en la visualizacion, sino que consiste en una seleccion de da-tos relevantes dentro de documentos semiestructurados, lo cual no es siem-pre sencillo y es ademas claramente dependiente de la estructura interna deesos documentos. Para ello, pueden usarse reglas de extraccion de datosbasadas en una regularidad estructural seleccionando aquellos datos quecumplan un formato esperado. Sin embargo, esta estructura de marcado enla que estan basadas estas reglas esta normalmente muy orientada a los as-pectos de visualizacion, por lo que las reglas de extraccion de datos, apartede ser de las partes con mayor presencia en los programas, son tambien delas mas fragiles, ya que cualquier cambio en la estructura esperada de laspaginas afecta directamente a esas reglas. La facil construccion de estas re-glas de extraccion de datos es vital para conseguir un bajo coste, no solo dedesarrollo, sino tambien de mantenimiento.

En el caso de la navegacion manual, esta labor recae completamente enel usuario. El browser practicamente no interviene ni realiza otra labor masque presentar los datos en la pantalla junto con el resto de la informacion,sin tener capacidad para tan siquiera resaltar el dato para el usuario, pues notiene forma de saber cual de los datos que figuran en la pagina es el dato queinteresa al usuario para su tarea. En el caso de la navegacion automatica,al tratarse de un tratamiento especıfico y dependiente de la estructura de laspaginas, de los datos, y de la tarea que los va a utilizar, esta accion no seencuentra pre-construida en una biblioteca generica de la plataforma, porlo que debe ser programada en reglas de extraccion definibles por el usuario.

2.2.2. Estructuracion de datos semiestructurados

Los datos extraıdos pueden ser necesarios mas de una vez a lo largo dela ejecucion de una tarea, por lo que conviene que sean convenientementealmacenados en un repositorio estructurado. Desde el punto de vista de lanavegacion manual, esta labor recae en la responsabilidad del usuario, quienhabitualmente suele resolver el problema memorizando el dato recientementevisualizado (tıpicamente en su memoria a corto plazo), apuntarlo en un papelo, en el mejor de los casos, recurrir el conocido uso del copiar y pegar en laventana de otra aplicacion. Sin embargo, ni la mente humana, ni el papel, niuna ventana de un editor de texto son repositorios adecuados para el proce-samiento automatizado desde un programa de ordenador. Ademas, los datosobtenibles del Web pueden ser muy voluminosos (de ahı el desbordamientohabitual 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 volumenes de los mismos, muchasveces sin que su tamano sea a priori limitable. Por esa razon, los programasde navegacion automatica suelen usar, no solo variables de memoria, sino es-tructuras de datos de tamano variable, como vectores, listas o ficheros, en losque ir almacenando los valores extraıdos de las paginas para que puedan serposteriormente procesados. Cuando se almacenan las partes seleccionadas deestos documentos en repositorios especializados, los datos seleccionados pue-den ser convertidos a tipos de datos mas facilmente procesables habitualesen los lenguajes de programacion, como numeros, booleanos, fechas, cadenasde caracteres o, quizas, nodos de un arbol de documento.

En el caso de la navegacion manual basada en browsers, el usuario es elresponsable de almacenar los datos y por ello es el quien decide como almace-narlos. Normalmente los suele intentar memorizar o dejar en alguna ventanaabierta del navegador que posteriormente este accesible para poderla volvera leer, pero ello implica la necesidad de tener que volver a extraer de ellanuevamente los datos cada vez que se deseen manipular, y la posibilidad deperderlos si se siguen enlaces en la misma ventana. En el mejor de los casos,pueden almacenarse en otras herramientas externas, pero ello implica unaardua labor de estructuracion con el fin de poder manipular eficientementegrandes volumenes de informacion. En el caso de la navegacion automati-ca, al tratarse de un tratamiento especıfico y dependiente de la estructura delas paginas, de los datos, y de la tarea que lo va a utilizar, esta accion nose encuentra pre-construida en una biblioteca generica de la platafor-ma, por lo que debe ser programada en las correspondientes sentencias dealmacenamiento en repositorios estructurados.

2.2.3. Seguimiento explıcito de enlaces

Los datos en el Web se suelen encontrar distribuidos en multiples docu-mentos que, por lo tanto, deben ser recuperados. Para ello suele usarse elprotocolo HTTP, haciendo un seguimiento explıcito de enlaces conforme ala tabla 2.3. A veces las direcciones de esos documentos no son conocidasa priori por el usuario, sino que tienen que ser obtenidas dinamicamentedesde otras paginas ejercitando la navegacion. En los casos mas sencillos,bastara con visitar una direccion Web en la que se sabe que figuran los da-tos que se desea consultar. En otros casos, es necesario establecer una sesiondesde la pagina principal del sitio Web de forma que hay que seguir variosenlaces y rellenar varios formularios antes de acceder finalmente a la pagina

66

que contiene el dato.

En el caso de la navegacion manual, el seguimiento explıcito de enlacesconsiste en una labor semiautomatica, asistida por el browser, donde la labordel usuario se reduce a seleccionar y activar los enlaces que le interesan. Enel caso de la navegacion automatica, esta accion se encuentra ya comple-tamente pre-construida en las primitivas de varias bibliotecas utilizablesdesde distintos lenguajes de programacion para lanzar comandos GET, por loque tıpicamente la labor de programacion se reduce a parametrizar la llamadaa esta primitiva.

2.2.4. Rellenado de formularios

El rellenado de un formulario Web consiste simplemente en asociar unoo varios valores a cada uno de sus campos (tambien es posible dejar algunosde ellos vacıos). Los valores con los que se rellenan esos campos (tal y comoviene expresado en la tabla 2.4) pueden venir definidos por el usuario, opueden venir predefinidos en el propio formulario, pero en cualquier caso esel usuario el responsable de establecer aquellos valores que le interesen parasu tarea. Por otra parte, puede haber campos de formularios que no sonmanipulados (porque no los ha querido rellenar) o que no son manipulables(porque estan ocultos al usuario), en cuyo caso, conservan el valor con el quevinieron rellenados por defecto en el formulario.

En el caso de la navegacion manual, se trata de una labor semiautomati-ca asistida por el browser, donde la labor del usuario se reduce a interactuarcon los campos de los formularios. En el caso de la navegacion automatica, altratarse de un tratamiento especıfico y dependiente de la estructura del for-mulario, y de la tarea que lo desee rellenar, esta accion no se encuentrapre-construida en una biblioteca generica de la plataforma, por lo que debeser programada en codigo definido por el usuario. Normalmente la compleji-dad del rellenado de cada campo es dependiente de la estructura interna derepresentacion de ese formulario, pues es normalmente sobre ella donde serealizan estas modificaciones para despues proceder a la orden de envıo delformulario, segun la siguiente accion explıcita. En el mejor de los casos, conuna buena representacion donde exista una lista de campos recorrible y unasprimitivas de modificacion acordes con la semantica de cada campo, esa laborpuede realizarse en una simple lınea de codigo para cada uno de esos campos.

67

2.2.5. Envıo de formularios

Una vez que un formulario se encuentra ya relleno, la informacion recogidaen el puede ser enviada al servidor para que sea procesada.

En el caso de la navegacion manual, se trata de una labor semiautomati-ca, asistida por el browser, donde la labor del usuario se reduce a seleccionarun boton de envıo (en el caso en el que haya varios) y pulsarlo. En el caso dela navegacion automatica, esta accion se encuentra ya completamentepre-construida por las primitivas de varias bibliotecas utilizables desde dis-tintos lenguajes de programacion para lanzar comandos GET o POST, porlo que tıpicamente apenas se necesita programar y parametrizar la llamada aesta 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 manipulacion no dista de la que puedehaber en cualquier tarea de tratamiento de datos (no necesariamente invo-lucrada en el Web). Operaciones tales como comparaciones, acumulaciones,reordenaciones, operaciones aritmeticas o logicas o de procesamiento de tex-tos pueden ser combinadas segun las necesidades especıficas de manipulacionde informacion que requiera la tarea.

En el caso de la navegacion manual, el procesamiento que tıpicamenterealizan los browsers a las paginas que recuperan del Web se limita a la meravisualizacion en las pantallas de los ordenadores, facilitando, eso sı, el controlde todos los aspectos visuales y permitiendo al usuario la posibilidad desolicitar nuevos documentos del Web mediante el resaltado en la visualizacionde zonas activables del documento por el usuario mediante teclado o ratonpara el seguimiento de enlaces. Cualquier otro tipo de procesamiento quedadelegado en el usuario.

Muchas veces, ciertamente, estos tratamientos de datos en el Web soncomparaciones sencillas o labores que manejan poca informacion, 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 aritmetico-logicasun poco mas complicadas que las simples comparaciones detectables a simplevista y que escapan del facil calculo mental, el procesamiento manual de esosdatos se convierte en una labor realmente tediosa.

En el caso de la navegacion automatica pueden definirse rutinas que pro-

68

cesen esos datos de otra forma mas adecuada para las tareas. Mediante laprogramacion de rutinas definibles por el usuario, que reciban por argumen-to los datos obtenibles durante la navegacion, el tratamiento de estos datospuede ser realizado por el ordenador. Simplemente deberan procesarse los da-tos relevantes que se encuentran almacenados en repositorios programables,conforme a los objetivos establecidos en la tarea. Tambien es posible queesos procesamientos puedan estar ya implementados en alguna herramientaexterna. En esos casos, el tratamiento consistira en invocar a esa herramientacomo un proceso externo, enviarle los datos para que los procese y esperar deella los resultados. En el mejor de los casos, el procesamiento puede ser tansencillo como la simple impresion por pantalla de unos simples datos obteni-dos, para lo cual es posible programar esos comportamientos con sentenciassencillas dentro del mismo programa principal. La eleccion sobre donde pro-gramar este tipo de comportamientos dependera de la complejidad de losmismos, del hecho de que ya pudieran estar programados en algun programalegado y de la capacidad del programador para reutilizar ese codigo.

En el caso de la navegacion manual basada en browsers, el usuario esel 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-cion automatica, al tratarse de un tratamiento especıfico y dependiente delos datos, y de la tarea que lo va a utilizar, esta accion no se encuentrapre-construida en una biblioteca generica de la plataforma, por lo que debeser programada en rutinas definidas por los usuarios, que no necesariamenteseran dependientes de la cambiante estructura de las paginas al haber sidolos datos convenientemente estructurados en una fase anterior.

2.3. Subsanacion de las faltas de soporte de

la plataforma de navegacion

Finalmente, tal y como se vera en el apartado 3, no todas las plataformastienen un soporte completo a la ejecucion de aspectos de navegacion. Porejemplo, muchas plataformas carecen de soporte a la interpretacion de ruti-nas JavaScript, que se encuentran habitualmente embebidas en las paginasvisitadas. En estas plataformas no esta soportada, por lo tanto, la navega-cion basada en JavaScript, en la que las URL que deben visitarse no figuranexplıcitas en los enlaces que se pretende seguir, sino que dichas direccionesdeben computarse por alguna rutina JavaScript activable por algun eventoprovocado por el usuario con el raton o el teclado. Para poder navegar en

69

estos sitios desde este tipo de plataformas, el programador debe subsanarcon sus propias lıneas de codigo las acciones que simulen el comportamientode esas rutinas JavaScript. En otras plataformas no existe un convenientesoporte de las cabeceras HTTP o una adecuada creacion del convenientequery-string a partir de cada formulario relleno, por lo que el usuario de-be programar estos comportamientos implıcitos con su propio codigo. Todasaquellas acciones que, no teniendo soporte en la plataforma, sean significati-vas para la navegacion, deben ser suplidas con codigo definido por el usuario.Dicho codigo suele tener un coste significativamente elevado. Por esta razon,y para minimizar este coste, es importante, por lo tanto, escoger una buenaplataforma de navegacion.

Soporte de los browsers a las acciones basicas explıcitas

Tal y como puede verse en la tabla 2.5, en la navegacion manual, elbrowser da un soporte semiautomatico a tres de las acciones mas sencillas(seguimiento explıcito de enlaces y rellenado y envıo de formularios), dejandoal usuario la responsabilidad de realizar las otras acciones sin ningun tipo deasistencia por parte del browser. Desde la extraccion de datos relevantes hastael procesamiento que pueda necesitar realizarse sobre esos datos, el usuarioque utiliza browsers es quien debe encargarse de todo.

70

Capıtulo 3

Estado de la cuestion

En este capıtulo se realiza un repaso de los principales conceptos y tecni-cas desarrolladas hasta el momento en el ambito de la integracion de datossemiestructurados, ası como de otras tecnicas, no ya de automatizacion detareas en el Web, sino, mas genericamente, de navegacion automatica en elWeb.

3.1. Consideraciones previas

Antes de comentar esos trabajos aplicados al tema especıfico de la auto-matizacion de tareas en el Web, conviene mostrar como algunos sitios Webafrontan actualmente el uso de sus aplicaciones.

Algunos sitios Web, muy pocos en terminos relativos, proporcionanaplicaciones ejecutables alternativas a los browsers para proporciona-lidad una mayor facilidad de manejo a aquellos usuarios que realizanun numero elevado de transacciones. En estos casos, lo habitual sue-le ser que los desarrolladores de la aplicacion proporcionen al usuariouna forma de acceso indirecto a la aplicacion con la que interactuande forma que el interfaz no este basado en el browser, sino que en unprograma ejecutable capaz de automatizar varias de estas transaccionesminimizando parcial, pero sensiblemente, la interactividad solicitada alusuario. Por ejemplo, eBay [6] o el antiguo QXL (recientemente fusiona-do con Aucland [1]) han proporcionado a sus mejores vendedores unaaplicacion ejecutable (para uso exclusivo en entornos Windows) quepermite la publicacion de multiples subastas en la red con un solo click

71

de raton. Por otro lado, algunas operadoras de contratacion de accio-nes en bolsa, como por ejemplo Consors [4] proporcionan a sus clientesuna interfaz Java (normalmente un applet ejecutable en el navegador)para facilitar a sus usuarios mas activos una plataforma de introduc-cion de ordenes de compra-venta mas manejable que el browser cuandose trata de un numero elevado de operaciones o se requieren algunasfuncionalidades como informacion en tiempo real. Si bien la eleccionde la plataforma tecnologica puede ser muy dispar (existen igualmentesoluciones basadas en controles ActiveX y otras variantes), lo cierto esque este tipo de aplicaciones a veces no proporcionan una funcionalidadcompleta, ya que en ocasiones se limitan las opciones de la version in-teractiva basada en HTML y en la comunicacion a traves del browser,por lo que facilmente pueden no contemplar todas las funcionalidadesque desean los usuarios.

Por otro lado, muchas de las paginas que necesitan ser accedidas, notienen una interfaz especialmente amigable cuando se les usa desde otrotipo de browser distinto a aquel para el que han sido disenadas. Dichode otra forma, sus paginas son poco accesibles.

En cualquier caso, pocos disenadores de sitios Web estan dispuestos afacilitar que sus paginas sean navegadas por programas automatizados (ro-bots) en lugar de por personas usando browsers. Sin duda influyen mas ra-zones sociologicas (miedo a perder atraccion en la publicidad, miedo a quelos contenidos propios sean aprovechados por terceros para hacer negocio sinque el verdadero propietario reciba beneficios, ...) que tecnicas (miedo a versobrecargada la capacidad de respuesta de los servidores).

3.2. Automatizacion de aplicaciones interac-

tivas

Sin duda, estos problemas (el de la menor funcionalidad de las opcionesno interactivas de las aplicaciones y el de la baja amigabilidad del interfaz dealgunas aplicaciones) afectan al ambito de la automatizacion, pero no soloa la del Web, sino, en general, al de cualquier aplicacion disenada para serusada de forma interactiva. Dado que la problematica de la automatizacionde aplicaciones interactivas [149] es anterior al nacimiento del mismo Web,conviene sin duda analizar algunas de sus conclusiones mas relevantes paraaprovechar ası la experiencia desarrollada.

72

3.2.1. Lenguaje Expect

Aunque existen multiples trabajos enfocados en la automatizacion deaplicaciones interactivas en varios entornos, de todos ellos destaca sin du-da expect [84]. En expect, mediante la utilizacion de un nuevo lenguajede scripting especıfico similar al de un shell, se permite realizar facilmente elcontrol de programas interactivos lanzados en entornos Unix que esten prepa-rados para leer del teclado de una terminal. A diferencia de una shell normal,expect resulta especialmente util para emular al usuario desde el tecladocuando este tipo de fuente de datos no puede ser facilmente redireccionadoa un fichero para lectura o cuando es necesario responder adecuadamentea un prompt en un dialogo con la aplicacion interactiva, con peticiones delprograma y respuestas que deben introducirse por teclado en el momento enel que el programa interactivo las solicita.

Tal y como reza en ese trabajo, los tradicionales shells Unix tienen, sobrelas aplicaciones que invocan, un control que se limita a la creacion, espera ydestruccion de procesos, ası como las opciones con las que deben ser invocadosal principio y el redireccionamiento a/desde ficheros pero no tienen apenascontrol sobre aquellos programas que necesitan interactividad durante suejecucion, dejando esa tarea relegada a que el usuario introduzca esos datosdesde teclado. Mediante una filosofıa de lanzamiento de ejecuciones similara la de los shells, pero con extensiones para controlar la ejecucion interactivade estos programas, aplicaciones que hasta ese momento solo podıan usarsede forma interactiva, como telnet, ftp, passwd, rlogin, crypt, fsck, sudoo incluso otras para las que podıa emular al usuario ante otro usuario, comopor ejemplo talk, y en general, cualquier aplicacion (incluyendo las que sepudiera construir el usuario por su cuenta) que pudiera ser usada de modointeractivo desde teclado, pueden ser controladas automaticamente desde unprograma capaz de entender y proporcionar los datos que cada una de esasaplicaciones muestran y solicitan del usuario de forma interactiva. Para ello,se emula al usuario sustituyendolo por la aplicacion de un conjunto de reglascondicionales capaces de detectar los distintos casos de peticiones esperablespor las aplicaciones interactivas y ası asociar a cada regla un conjunto deacciones de respuesta.

El lenguaje desarrollado en ese trabajo, llamado expect, actualmente ins-talado en muchas distribuciones de sistemas Unix, esta basado en la sintaxisde TCL [97] y, entre las conclusiones reflejadas en [84] destaca, para ilustrarsu uso con un ejemplo, como el script de la figura 3.1, disenado para controlarmediante el dialogo interactivo con la aplicacion Unix ftp el acceso a un sitioftp anonimo, sustituyo a un programa equivalente (que hacıa lo mismo) es-

73

crito en lenguaje C, pero que tenıa un tamano aproximado de 60K. El scriptde la figura 3.1 espera a recibir la palabra Name del programa ftp antes deenviarle la palabra anonymous de la misma forma a la que espera a estaridentificado correctamente antes de lanzar una peticion de transferencia deficheros.

#! /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 ejecucion interactiva de ftp

Quiza lo mas llamativo de expect como lenguaje sea sin duda la gran di-ferencia de tamano existente entre la solucion escrita en el y la escrita en C,ambas para solucionar el mismo problema. La diferencia de tamano se puedejustificar en el hecho de que C es un lenguaje de programacion imperativo deuso generico, mientras que expect es un lenguaje de scripting de alto nivelde programacion y orientado al mantenimiento del control del dialogo concualquier aplicacion y capaz de proporcionar distintas respuestas a la aplica-cion dependiendo de lo que ella muestre a su salida. expect es, por lo tanto,un claro ejemplo de lenguaje con un nivel de abstraccion lo suficientementeelevado como para poder ser usado casi a nivel de especificacion de requisitos.

Sin embargo, un lenguaje para la automatizacion, pese a que disponga deun alto nivel de abstraccion, para poder ser aplicable a cualquier herramientainteractiva, debe ser capaz de controlar aspectos de bajo nivel. Para mostrarla flexibilidad del lenguaje expect en este sentido, el script de la figura 3.2ilustra la capacidad de emulacion de un usuario ficticio capaz de dialogar conotro (en un dialogo muy sencillo, pero que podrıa ser facilmente adaptable)mediante el uso de la conocida herramienta talk de entornos Unix. El nivelde control de talk en este caso llega incluso a controlar aspectos como unmodelo de tiempos variables entre pulsaciones de las teclas, dando al usuarioque esta al otro extremo de la comunicacion la ilusion de que realmenteesta dialogando con una persona pese a que en realidad no deja de ser unprograma que emula a un usuario. No ya en una aplicacion como talk sinoen cualquiera donde el numero de posibles salidas pueda ser conocido, unconjunto completo de reglas y acciones que actuen en consecuencia pueden

74

automatizar completamente la gestion de una aplicacion 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 ejecucion 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 abstraccion

Con orientacion al dialogo con aplicaciones existentes

Que reduce sustancialmente el tamano y, por lo tanto el esfuerzo paracrear y mantener, de aplicaciones capaces de automatizar a otras

Capaz de automatizar practicamente cualquier aplicacion interactivatextual (no grafica)

Capaz de analizar la informacion que proporcionan las aplicacionesinteractivas y estructurar su comportamiento basandose en esos casos

Capaz de asociar acciones a cada uno de los casos que se espera queproporcione la aplicacion 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 algun estandar conocido

Estas caracterısticas han sido tenidas en cuenta para la automatizacionde tareas en el Web en el apartado 6.

75

3.3. Web Semantico

Uno de los grandes problemas del Web actual, desde el punto de vistade su procesamiento automatizado, es que esta basado principalmente enHTML (formato difıcil de entender por las maquinas al estar muy orientadoa la mera visualizacion conforme al apartado 1.4.3). Teniendo esto en cuentajunto al hecho de que se espera que XML aun tarde varios anos en implantarsecomo formato para los documentos en el Web, desde el W3C se ha estadopromoviendo en los ultimos anos una ambiciosa iniciativa denominada el WebSemantico [32].

El objetivo del Web Semantico es el de permitir la navegacion automati-zada por parte de programas capaces de entender el significado de los datosque aparecen en las paginas del Web, gracias al hecho de que a estas les acom-panan 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 paginas Web. Laspaginas 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 procesarlos metadatos descriptivos de una pagina puede encontrar para el usuario lainformacion que satisfaga sus requisitos de busqueda con un mayor criterioque la simple busqueda por palabras clave, cuando se busca en un conjuntode paginas unidas entre sı por hiperenlaces.

Siendo el Web Semantico una opcion realmente prometedora para el futu-ro del Web y de la construccion dinamica de caminos de navegacion, guiadapor la consecucion de objetivos, lo cierto es que todavıa es una tecnologıaincipiente a la que aun le falta por demostrar sus capacidades en entornoscomplejos, habiendo solo sido probada en entornos sencillos como [102]. En[64] se cuestiona como un Web dinamico puede tener asociadas paginas demetadatos estaticas, estableciendo diferencias entre las semanticas estaticasde estos ficheros declarativos creados aparte por personas y las semanticasdinamicas necesarias para manejar los datos del Web, que normalmente sedan en el contexto de un lenguaje de programacion, abogando ası por so-luciones no precisamente declarativas. Por otro lado, las necesidades de losusuarios son mucho mas complejas que aquellas a las que puede dar res-puesta un buscador. Una vez delante de la pagina en la que debe empezara trabajar, es necesario desarrollar una tarea cuyos pasos son normalmenteconocidos por los usuarios y no es necesario que sean deducidos.

En lugar de definir programas envoltorio, comunmente conocidos como

76

wrappers para cada fuente de datos accedida, el Web Semantico propone lautilizacion de programas de navegacion generica capaces de autoprogramarsu navegacion a cualquier sitio Web conforme a la informacion suministradapor los metadatos de ese sitio Web. Ello supone, en la practica, delegarcualquier automatizacion de tareas en la construccion de una adecuada meta-informacion de un sitio Web, capaz de dirigir el comportamiento de estosprogramas de navegacion generica por ese Web de forma similar a la que lonavegarıa un programa envoltorio.

El Web Semantico esta en un estado aun inmaduro y carece del soportenecesario de muchas herramientas. Por otro lado, la mayorıa de las paginasdel Web tambien carecen de los correspondientes metadatos, y eso es algoque tardara tiempo en paliarse aun cuando el Web Semantico recale en laconstruccion de Webs. Por todo ello, es previsible que la utilizacion de lastecnicas del Web Semantico tardaran aun bastante tiempo en poder explo-tarse masivamente en Internet para la automatizacion de tareas en el Web.

3.4. Mecanismos de construccion de progra-

mas de navegacion automatizada

Los siguientes trabajos abordan de una u otra medida el tema de la au-tomatizacion de la navegacion en el Web.

En buena parte de los proyectos en los que se desarrollan trabajos para laespecificacion de aplicaciones para la Web, la gran mayorıa de los esfuerzosse vuelcan en la especificacion de aplicaciones accesibles desde el Web quesean funcionales y no produzcan errores a sus usuarios. Ejemplos de estaalternativa son XL [59] y Dicons [27] donde se definen lenguajes de especifi-cacion para la Web, pero en el lado del servidor, no en el lado de un clienteque desee automatizar el uso de esas mismas aplicaciones. Otros trabajos,como WebML [50] intentan aplicar el modelo Entidad-Relacion de las basesde datos relacionales a ciertas paginas del Web. Tal modelado resulta enri-quecedor en el sentido de que aporta una vision muy descriptiva y detalladadel esquema de datos usado al publicar muchas de las paginas Web existen-tes hoy en dıa. Sin embargo, estas aproximaciones no son utilizables en loscasos en los que las paginas y los datos contenidos en las mismas no siguenunas normas establecidas asimilables a las de un modelo Entidad-Relacion.WebML se presenta como una aportacion desde el punto de vista de los di-senadores Web y de la publicacion estructurada y descriptiva de las paginas,sin abordar el tema de la integracion de datos semiestructurados por parte

77

de sus usuarios o lectores.

Ya en el terreno del desarrollo de clientes Web que naveguen automatica-mente, las herramientas mas usadas para la automatizacion de la navegacionde enlaces en el Web suelen ser programas completos (disponibles con multi-ples opciones de ejecucion) para descargar documentos del Web o realizarotro tipo de acciones sencillas desde la Web superficial. Muy usado en estesentido es Wget [20], pese a que solo sirve para descargar documentos. Al-gunas herramientas como Curl [5] permiten un uso mas avanzado al ofreceral usuario la posibilidad de manejar tambien formularios ademas de enlaces,eso sı, solicitando al usuario datos de bajo nivel como el query-string que sedebe enviar, en lugar de crearlo el a partir de una estructura de datos querepresente a un formulario relleno. Estas ultimas no ofrecen la posibilidad derecibir establecido el guion de una sesion completa HTTP mas alla de unasola transaccion, por lo que la secuencia de acciones de la tarea solo puedeser especificada desde fuera de la herramienta, mediante llamadas a la mis-ma, tıpicamente en un lenguaje de interprete de comandos (shell) del propiosistema operativo, y siempre que no sea necesario el manejo de aspectos debajo nivel, como son las cookies [95].

Algunas herramientas, como Veriweb [30], sı son capaces de seguir masde un enlace y formulario en una unica ejecucion, pero se limitan a realizarpruebas de ejecucion sobre herramientas accesibles desde el Web, siguiendosus enlaces y testeando que los caminos o tareas que cada una de esas aplica-ciones permite realizar desde cada una de sus paginas no produzca errores enla aplicacion del servidor ni provoque que al cliente le lleguen paginas de error(que son indeseables para muchos sitios comerciales porque menguan futurasvisitas al site). En cualquier caso, no permiten al usuario la automatiza-cion de una tarea concreta, sino que recorren todos los caminos encontrablesprobando con distintos datos para rellenar los formularios, por lo que susalgoritmos de fuerza bruta no resultan adecuados para la automatizacion detareas condiderables de utilidad para los usuarios.

Por otro lado, existen varias bibliotecas [39, 35, 23, 112, 118] sobre varioslenguajes de programacion (Prolog, Perl, Java, C, ...) que sı permiten laejecucion de una secuencia preprogramada de transacciones Web, combinadaa su vez con la extraccion de datos desde documentos XML obtenidos por lared. En ocasiones, mas que bibliotecas para algun lenguaje de programacion,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 nopermite el dialogo con servidores del Web legado por su falta de manejo deciertas acciones implıcitas que realizan los browsers sin que el usuario sea

78

consciente de ello, como las mencionadas en el apartado 2.1. Tambien suelenaplicar tecnicas de extraccion de datos como son las expresiones regularesy la definicion de analizadores lexicos que tratan a esas paginas como textoplano, 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 proponeuna extraccion de datos semiestructudados basada en XPath. A lo sumo,algunas de ellas, como [29, 80] definen sus propias primitivas de extraccionde datos, pero en ningun caso basadas en el estandar del W3C.

Otras tecnicas, como [81, 54, 80] resuelven bien la parametrizacion deacciones implıcitas (ver apartado 2.1). Sin embargo, dejan no muy bien cu-biertos desde el punto de vista de la mantenibilidad, aspectos tan importantescomo lo es la extraccion de datos del Web, una vez que la pagina que contienefinalmente los datos ha sido recuperada.

Desde el punto de vista de las aportaciones hechas por el W3C, variastecnicas, como XSLT [130] o DEL (Data Extraction Language) [133] han sidopropuestas para la obtencion en formato XML de datos extraıbles de otrosdocumentos XML mediante reglas de extraccion y transformacion. Ambasdefinen etiquetas para crear facilmente lenguajes de script que sean facilmenteinterpretables. Sin embargo, carecen de mecanismos para indicar la forma deobtencion 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 programacion sobre sintaxis XML en donde hayetiquetas capaces de representar variables, bucles, condiciones, y otros tiposde acciones. Este tipo de lenguajes de programacion, definidos sobre estasintaxis es facilmente interpretable por varios programas y muy facilmenteanalizable.

En el W3C, el tema de la extraccion de datos se ha centrado ultimamenteen la definicion del lenguaje de consulta XQuery, una extension de XPath 2.0(en realidad un superconjunto) que permite la consulta para la extraccion dedatos de cualquier documento XML, con funcionalidades avanzadas similaresa las de otros lenguajes de consulta de bases de datos relacionales, como SQL[78]. Sin embargo, estas iniciativas, pese a que ofrecen muy buenas solucionespara ese problema (de hecho esa es la razon por la que en esta tesis se hayapartido de XPath 2.0 para crear un lenguaje de consulta y manipulacion),no se enfrentan al tema de como obtener los documentos XML del Webni tampoco acerca de como integrar los datos que aparezcan repartidos endistintos documentos.

De entre los ultimos proyectos mas avanzados para ser aplicados al Weblegado, puede destacar [94, 111], en el que se aplican modernas tecnicas de

79

extraccion de datos semiestructurados a las paginas HTML, a paginas co-rregidas con Tidy [104]. En [94] se usa XSLT y en [111, 25] se considera alWeb como una base de datos lo suficientemente estructurada como para po-der usar lenguajes de consulta de bases de datos como XQL, un lenguaje deconsulta predecesor de XQuery. Gracias a herramientas como Tidy, algunosusuarios pueden usar herramientas de evaluacion de expresiones XPath como[21] sobre el Web legado. Sin embargo, tres importantes factores no han sidotenidos suficientemente en cuenta por estos trabajos.

En primer lugar, no solventan adecuadamente las dificultades queafronta escoger XSL como lenguaje de manipulacion de datos (se gene-ran documentos de salida en lugar de manipular el arbol del documentoy permitir el almacenamiento de sus partes en repositorios programa-bles).

En segundo lugar, no incorporan mecanismos de mejora a la robustezante fallos, como los muy convenientes Service Combinators [40], siendopoco adecuados para la extraccion de datos en paginas con estructurasde marcado cambiantes e irregulares.

En tercer lugar, ninguno tampoco se ha enfrentado aun al uso del nuevoborrador de XPath 2.0 definido por el W3C para este fin, que incluyemuchas e importantes mejoras respecto de la version actual del estandarque salio a la luz en 1999.

Otros trabajos, como RoadRunner [55], pretenden aplicar algoritmos paragenerar automaticamente wrappers a partir de documentos de entrada. Pesea que ello supone un interesante enfoque capaz de minimizar los problemasde la generacion manual y del mantenimiento de estos wrappers, la casi totalfalta de estructura esperable en los documentos del Web provocan que estetipo de soluciones solo funcionen adecuadamente con ejemplos muy sencillosy muy regulares en su estructura, lo cual no siempre se puede es facilmenteencontrable en las aplicaciones del Web cuyo uso se desea automatizar.

Finalmente, uno de los mas completos trabajos realizados hasta el mo-mento en el campo de la integracion de datos en el Web corresponde sin dudaa [31], donde se tienen en cuenta muchos factores adecuadamente escogidosque facilitan el desarrollo de programas envoltorio por personas con pocascapacidades de programacion. Una herramienta de facil utilizacion permi-te dotar a estos programas de la conveniente robustez ante cambios en laspaginas, minimizando los costes de su mantenimiento. En ese trabajo, doslenguajes han sido desarrollados y soportados para dos propositos bien dis-tintos, pero complementarios entre sı: la obtencion de documentos del Web

80

(mantenimiento del dialogo en una sesion HTTP con servidores Web) y laextraccion de datos relevantes de cada uno de esos documentos. El primerode los lenguajes, NSEQL, es un lenguaje de alto nivel de abstraccion en el quese indica la secuencia fija y preestablecida de acciones que deben activarse enun modulo navegador, una tras otra, para obtener del Web los documentosinvolucrados en una tarea. En dicha secuencia de acciones, se hace tıpica-mente una referencia implıcita al elemento o documento activo seleccionadopor alguna accion anterior, de forma que, ademas de las acciones de segui-miento de enlaces, envıo de formularios y rellenado del valor de sus campos,se contemplan otras mas propias de la orientacion a un browser como lafocalizacion de documentos, formularios o elementos que quedan selecciona-dos como activos para que las siguientes acciones los puedan tomar comoreferencia. Otro lenguaje, llamado DEXTL se encarga de extraer los datosrelevantes de cada una de esas paginas, de forma que el uso combinado deambos lenguajes permite la automatizacion de practicamente casi cualquiertarea 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 generadorde analizadores lexico-sintactico propio, basado en expresiones regula-res y en reglas gramaticales que indican la estructura esperada del textopara ser ası correctamente reconocido y de esa forma poderle aplicar lascorrespondientes reglas de extraccion de datos. Una opcion quiza masinteresante, podrıa haber sido la de aplicar tecnologıas como XPathpara poder seleccionar adecuadamente los nodos relevantes del docu-mento. Ello supondrıa cierta perdida de flexibilidad (XPath no podrıaser aplicable a cualquier fichero de formato textual, como DEXTL sı lopermite), pero habrıa proporcionado quiza un mayor grado de robusteza las expresiones de extraccion de datos en documentos HTML, puestoque una expresion XPath ocupa tıpicamente una unica lınea de codigofacilmente entendible, en lugar de las varias que se necesitan para podercrear una expresion 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 abstraccion las acciones que formanparte de la secuencia de eventos que un usuario genera con un browserdurante un proceso de navegacion, es decir de acciones basicas comolas mencionadas en la tabla 2.5, este API podrıa haber sido un poco

81

mas simplificado, ortogonalizado para hacerlo independiente de los ele-mentos concretos de HTML y sus posibles eventos, y reorientado a larobustez. Dado que NSEQL no se basa en un modelo de datos como elde XPath, sino en los elementos y documentos activos que un navega-dor puede tener en cada momento, muchas de las funcionalidades delAPI se basan en la aplicacion de algun evento a algun tipo concreto deelemento o atributo de HTML. Existe una funcion para seguir enlacesde anchors, que sin embargo no sirve para seguir enlaces de otro tipode elementos, como areas (es decir, mapas de imagenes), que tambientienen 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 asociacion explıcita de nom-bres a las paginas previamente visitadas, impide, por ejemplo, que unamisma pagina visitada con anterioridad a la pagina actual pueda serreutilizada sin tener que abandonar el contexto de la actual. Por ejem-plo, dentro de un bucle en el que ciertas paginas con formularios debanser revisitadas para emprender con ellas el procesamiento de un nuevoconjunto de datos en una labor repetitiva, resulta necesario emular laaccion Back del navegador, que puede implicar traerse una nueva ver-sion de la pagina en lugar de reutilizar la que previamente habıa sidoobtenida.

Por otro lado, buena parte de las funciones del API necesitan recibircombinaciones de tres datos, tıpicamente un texto, un booleano y unnumero entero, indicando que se desea escoger el enesimo elemento deuna lista de posibles que cumplan el tener al texto, bien contenido deforma exacta, bien contenido como subcadena, bien como texto, bienquiza en algun atributo concreto, todo ello dependiendo del argumentobooleano y del nombre concreto de la funcion a la que se invoque. Dichode otro modo, existen funciones para buscar elementos por texto o poralgunos atributos, pero no para seleccionar elementos que cumplan unacombinacion arbitraria de cualquier nivel de complejidad con variosde ellos, abstrayendose de nombres concretos de etiquetas o atributosparticulares de HTML, como sı permiten los predicados de XPath.

Por otro lado, el rellenado de formularios se plantea igualmente conun conjunto predefinido de funciones, cada una de las cuales permiterealizar una accion concreta y predefinida sobre un tipo concreto decampo de formulario, cuando serıa mucho mas simple y flexible, aunquequiza tambien de mas bajo nivel, permitir la modificacion generica decualquiera de sus atributos. Por ejemplo, una de las funciones permite

82

rellenar un campo de texto de un formulario (modificando su atributovalue, se entiende). Otras funciones permiten seleccionar la opcion deuna lista de opciones posibles. Por el contrario, no existen funcionespara cambiar otros tipos de atributos influyentes en los campos deformularios, como checked o disabled.

En practicamente casi todas las funciones, es imprescindible la indica-cion de un numero entero que indique la posicion del elemento que sedesea direccionar dentro de una lista de otros que cumplan una seriede caracterısticas. Ası, por ejemplo, se puede seguir el septimo enlacede una pagina, por ejemplo. Sin embargo, el criterio de la posicion deun elemento dentro de su pagina es altamente sensible a cambios enlas paginas HTML, pues en el momento en el que la pagina del servi-dor anada una nueva opcion a la lista de opciones, las posiciones deestas se ve irremediablemente trastocada, provocando que en la laborde mantenimiento de estos programas se deba proceder a la actuali-zacion de estos valores numericos. Una seleccion basada en contenidosindependientes de posiciones es mas robusta o, en cualquier caso, masfacilmente mantenible.

En cualquier caso, el API esta mas orientado a los eventos que esperarecibir un browser grafico como lo es Microsoft Internet Explorer, que alpropio dialogo HTTP que espera el servidor al que se accede remotamente,puesto que no se dialoga directamente con el servidor sino que de delega estalabor a este browser concreto. Sin embargo, el uso de un browser grafico enla plataforma de ejecucion le aporta una indudable ventaja: y es que estesistema tiene incorporada la ejecucion de rutinas JavaScript, algo que notienen todas las plataformas de navegacion automatizada.

3.4.1. Uso de APIs estandares

Por otro lado, programar con APIs estandares tampoco es una garantıade exito si ello implica la utilizacion inadecuada de la tecnologıa. Por ejemplo,en [115] se explica lo dificultoso que puede ser realizar un programa Java queextraiga 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 serel que aparece en la figura 3.4.

Teniendo en cuenta que existe una expresion 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 direccion completa de Jim Smith y que existen bibliotecas Javacapaces de evaluar expresion XPath, una buena opcion podrıa ser reescribiren 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 mas sencillo por haceruso de XPath. XPath, del que se detallan ventajas e inconvenientes en elapartado 4.2, suele usarse normalmente embebido en un lenguaje anfitrionque normalmente es XSLT. Una hoja XSLT que realiza lo mismo que elprograma Java anterior es la que aparece en la figura 3.6. Como puede verse,una hoja XSLT puede ser tambien muy verbosa y demasiado compleja inclusopara tareas sencillas y saber escoger un estandar adecuado es primordial paramantener bajo el coste de mantenimiento de los programas.

Por otro lado, XML-Binding [34] resulta una tecnologıa novedosa pa-ra la manipulacion de documentos XML con un interfaz mas simple que elproporcionado por DOM. La idea principal de XML-Binding consiste en ge-nerar clases compilables en un lenguaje de programacion, tıpicamente Java,automaticamente a partir de su descripcion en XML Schema [134]. De es-ta forma, los documentos que validen con ese XML Schema son facilmenteprocesables por objetos de la clase correspondiente. Ello es util en entornosdonde DOM ofrece un acceso costoso a los programadores que quieren teneruna vision logica de los datos en lugar de una vision en arbol del documento.Su utilidad es aplicable especialmente en entornos donde los lenguajes XMLSchema son desconocidos a priori o pueden sufrir modificaciones, de formaque esos cambios quedan ocultados por la aplicacion generadora de clases.Sin embargo, este tipo de trabajos no es directamente aplicable al Web legadobasado 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 cuestion

La tabla 3.1 refleja un resumen de las tecnologıas mencionadas en estecapıtulo, comparando unas con otras respecto a varios criterios comunes. Laprimera columna corresponde a las soluciones ad hoc, como [26, 51, 37, 93, 85],basadas en expresiones regulares y en plataformas creadas especıficamentepara resolver problemas concretos. La segunda columna se corresponde conla opcion de usar un parser generico tipo DOM al estilo del empleado en lafigura 3.4, utilizable en una biblioteca utilizable desde un lenguaje de pro-gramacion. La tercera columna, muy similar a la segunda, refleja la opcionde usar JavaScript circunscribiendose a un browser, en tanto que tambienusa DOM, salvo que con otra sintaxis distinta a la de Java. La cuarta opcionse corresponde con plataformas al estilo de Xalan [62], es decir, parsers tipoDOM pero capaces de evaluar expresiones XPath, lo cual simplifica muchola labor de programacion, tal y queda reflejado en la figura 3.5. La quin-ta columna, se corresponde con la opcion de usar WebL [80] y la sexta secorresponde con los resultados de esta tesis a efectos comparativos.

Ad hoc Parser JavaScript Xalan WebL XPlore

Estandar Exp. Reg. DOM DOM XPath+DOM No MSC+XPath

Extraccion Bajo Bajo Alto Alto Alto Alto

Navegacion 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ı

Localizacion 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 extraccion de datos presenta un bajo nivel deabstraccion cuando se emplean expresiones regulares o un parser tipo DOMsobre lenguajes de programacion convencionales (salvo la contada excepcionde JavaScript). A pesar de que todas las opciones presentan un nivel de abs-traccion adecuado para representar las acciones navegacionales del protocolo

87

HTTP, pocas de ellas ofrecen un buen soporte a los aspectos de mas 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 utilizacionde rutinas de usuario para las acciones mas complejas, no siempre es posibledefinir de forma simple el comportamiento en las acciones mas sencillas. Porejemplo, las soluciones ad hoc suelen basar casi todo su funcionamiento enrutinas definibles por el usuario. En cuanto a la robustez ante fallos en la co-nexion, pocas opciones ofrecen mecanismos de recuperacion ante fallos. Porotro lado, la facilidad de localizacion de las zonas de codigo afectadas por unposible cambio en la estructura de las paginas puede ser complicada si se usaun parser tipo DOM, (debido al alto numero de lıneas de codigo involucradasen cada accion) teniendo en cuenta, no obstante, que su legibilidad suele ser,pese a esa verbosidad, aceptable. Algo completamente distinto suele ocurrircon las expresiones regulares, que suelen concentrar en una zona de codigomuy concreta el lugar afectado por un cambio en las paginas, aunque sinembargo proporcionan una mala legibilidad de las mismas debido a su bajonivel de abstraccion. Finalmente, unas u otras opciones son aplicables a cual-quier formato, tanto HTML del Web legado como XML, pudiendo requerirpara 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 estandares

La mayorıa de los trabajos relacionados suelen afrontar el problema de laintegracion de datos semiestructurados desarrollando lenguajes ad hoc parapropositos especıficos, cada uno de ellos adaptado a sus propios propositosespecıficos. La gran mayorıa de ellos suelen estar basados en analizadores lexi-cos basados en expresiones regulares, aplicadas sobre los documentos como sifueran ficheros de texto plano, ignorando la estructura logica de marcas deldocumento, al contrario que como ocurre con la utilizacion de otros estanda-res conocidos. Muchos de estos proyectos, o bien han sido abandonados, obien han tenido poco exito o repercusion en la comunidad, o bien estan sien-do explotados bajo un elevado coste de mantenimiento. Por el contrario, unasolucion basada en estandares resulta mas facilmente mantenible debido auna mayor legibilidad y un mayor nivel de difusion.

88

Bajo nivel de abstraccion

Los trabajos que sı suelen optar por una solucion basada en estandaressuelen muchas veces tropezar con una inadecuada eleccion de la tecnologıaque va a utilizar. Ası pues, de los proyectos relacionados que sı han optadodesde un principio por la utilizacion de estandares XML en sus desarrollos,la gran mayorıa ha escogido usar tecnologıas como SAX [86], DOM [131] (osimilares) [77, 72] o XSLT [130]. Cada una de estas tecnologıas presenta dife-rencias importantes en cuanto a la potencia, eficiencia y nivel de abstraccion.Por ejemplo, SAX tiene un nivel de abstraccion muy bajo pero eficiente (utilpara tareas sencillas sobre datos voluminosos), mientras que el de XSLT esmas elevado. Por otro lado, DOM resulta ser la tecnica mas potente de lastres, pero tambien la que requiere mas conocimientos y experiencia, y por lotanto, dedicacion y recursos. XSLT, disenado como un lenguaje de especifi-cacion de transformaciones y, pese a su gran aceptacion, resulta demasiadosofisticado y verboso cuando las reglas de transformacion que maneja adquie-ren un poco de complejidad (muchos bucles, variables tipadas, condicionalesy expresiones calculando valores temporales para ciertos calculos), en cuyocaso un lenguaje de programacion imperativo puede ser mejor opcion. Encualquier caso, estas tres tecnologıas adolecen de un mismo problema, y esque todas ellas comparten el hecho de requerir varias lıneas de codigo parauna operacion que en principio podrıa ser considerada como sencilla.

Baja escalabilidad

Los sistemas desarrollados hasta el momento no intentan minimizar lacomplejidad del codigo particularizado de acceso a los servidores Web (codi-go envoltorio) [83], por lo que los sistemas desarrollables con estas tecnicasresultan ser muy poco escalables, es decir, muy costosos de desarrollar ymantener en cuanto el numero de servidores a los que se accede crece.

Baja adaptabilidad ante cambios

Los sistemas desarrollados hasta el momento no intentan favorecer, enlas aplicaciones desarrollables con ellos, la adaptabilidad ante cambios en laspaginas del Web. Por esa razon, es comun, que estas aplicaciones desarro-lladas con estas tecnicas acaben dejando de funcionar por la aparicion depequenos y frecuentes cambios, muchos de ellos incluso imperceptibles paralos usuarios si se accede con un browser.

89

Limitaciones en la capacidad de construccion

Buen numero de funcionalidades, principalmente acciones implıcitas ne-cesarias para mantener correctamente la sesion con servidores Web, no estancompletamente contempladas por la gran mayorıa de plataformas de desa-rrollo existentes, por lo que muchos programas desarrollados acaban por nopoderse 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 alque acceden cambie algo que rompa con las suposiciones establecidas implıci-tamente por el programador del codigo envoltorio, por lo que necesitan serrevisados cada poco tiempo, siendo ademas costoso localizar y corregir enel codigo del programa el cambio que ha provocado que la aplicacion ha-ya dejado de funcionar. Como el Web es un ente cambiante que evolucionadinamicamente, resulta bastante imprevisible el momento en el que se va adetectar un fallo o el impacto que un cambio va a suponer en un algoritmode navegacion.

Navegacion superficial

El denominado deep Web [110, 105], esto es, el Web obtenible del vol-cado de bases de datos, esta aun por explotar convenientemente, ya que lossistemas de navegacion existentes apenas permiten seguir enlaces facilmenteobtenibles, como los que tienen una URL estatica o aquellos para los que nohace falta rellenar apenas formularios.

3.6. Limitaciones de las tecnologıas actuales

Buena parte de los proyectos que abordan el tema de la automatizacionde la navegacion en el Web, al igual que este trabajo, reconociendo igual-mente que quizas los beneficios de iniciativas como las de XML o la mejorade la accesibilidad tardaran en poderse apreciar, plantean sus propias solu-ciones directamente sobre las paginas HTML del Web legado. Buena partede esos trabajos plantean sus principios considerando a las paginas Web co-mo ficheros de texto plano, de forma que a las paginas Web obtenidas se lesextraen los datos aplicando patrones basados en expresiones regulares ba-

90

sadas en el codigo HTML que rodea a cada dato que se desea extraer. Sibien la aplicacion de expresiones regulares resulta ser una tecnica lo sufi-cientemente potente como para poder ser aplicada tambien a otros tipos deformatos textuales, lo cierto es que las expresiones regulares resultan ser unatecnica de bajo nivel de abstraccion, donde, toda vez que pequenos aspectossintacticos tales como la aparicion inhabitual de multiples espacios en blancoo fines de lınea, la ambivalencia de comillas dobles y simples, la indistincionde mayusculas y minusculas o el orden de aparicion de los atributos de unaetiqueta hayan podido ser superados, la legibilidad de esas expresiones secomplica notablemente. Por otro lado, mediante el uso de esas expresionesregulares, la estructura de arbol de la pagina HTML no es considerada. Estehecho puede no suponer un problema si la estructura de la pagina HTML yla consulta que se le desea efectuar son lo suficientemente simples. No obs-tante, es deseable a veces poder aplicar patrones de extraccion de datos adeterminados fragmentos especıficos de la pagina, es decir, a cierto numerode subarboles que cumplan determinadas propiedades (porque se sabe quesolo se desea buscar en determinadas zonas relevantes de la pagina), en lugarde a todo el documento. Para estos casos, las expresiones regulares resultanser bastante limitadas.

Los ultimos proyectos que abordan estos problemas han descubierto en lafamilia de especificaciones XML una tecnologıa adecuada con el que poderenfrentarse al problema anterior de una forma mucho mas elegante y robus-ta. Para poder aplicar este tipo de soluciones se necesita, no obstante, de unsoftware capaz de reparar los errores sintacticos habituales en una gran can-tidad de paginas Web. Dichos errores sintacticos, tales como la falta de cierrede etiquetas, el incorrecto anidamiento de las mismas o la ausencia de en-trecomillado en los atributos deben ser corregidos en las paginas segun estasvan siendo obtenidas de los servidores. Los documentos HTML ası obtenidosquedan transformados en sus equivalentes documentos XHTML [117] antesde poder aplicarles cualquier tecnica XML. Si bien existen numerosos progra-mas [58, 146] capaces de obtener una version de la pagina donde se cumplanlos principios de buena formacion de XML, esto es, conforme a la sintaxisbasica de XML, la herramienta Tidy [104] suele ser la mas habitualmenteusada.

Los pocos trabajos que emplean el enfoque de reparacion sobre la marchade la sintaxis de los documentos (con herramientas como [104, 58, 146]), sue-len aplicar a las paginas Web obtenidas, una vez ya corregidas, bien parserstipo DOM [131] sobre los que aplicar directamente codigo programado en len-guajes convencionales de programacion (tıpicamente Java), o bien hojas deestilo XSLT [130] para extraer de las paginas la informacion que les interesa.

91

Cuando las hojas de estilo XSLT no ofrecen toda la funcionalidad deseablepara el problema que desean afrontar, estos sistemas suelen permitir la apli-cacion de funciones de usuario escritas en algun lenguaje de programacionconvencional. Si bien la estructura declarativa de las hojas XSLT permite de-finir un gran numero de tratamientos aplicables a los documentos XHTMLde entrada, muchas veces el tratamiento aplicable a ciertas paginas requierealgo mas que la simple extraccion de datos en documentos de salida. Esaextraccion por sı sola puede ser suficiente en tareas simples de recuperacionde informacion, 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 manipulacion mediante insercion y borradode nodos y/o atributos o la manipulacion repetida de esos atributos en unmismo documento. Los formularios Web son muchas veces un claro ejemploque demuestra, para la tarea de ser rellenados multiples veces, la necesidad deuna manipulacion sencilla y eficiente de pequenas partes de un documento,donde la referencia de un unico arbol accesible representativo del documentosea constantemente visible sin la necesidad de estar creando y destruyendosubarboles mediante la aplicacion de sucesivas hojas XSLT.

Si bien XSLT es una solucion entendible por numerosos programadores, elactual borrador de XPath 2.0 [141] esta suponiendo serios replanteamientosacerca de lo que se espera que seran las futuras versiones de XSLT. Granparte de la expresividad de XSLT 1.0 esta sustentada en la capacidad dela robusta extraccion de datos de XPath 1.0. XPath 2.0, gracias a la incor-poracion de nuevos operadores que no aparecıan en la anterior version y suintegracion dentro del marco de XQuery [142] como lenguaje de consulta,esta constituyendose como un potente mecanismo de direccionamiento dedatos en documentos XML, suficiente por sı mismo como para no necesitarla funcionalidad extra de XSLT a la hora de realizar integradores de datossemiestructurados. De hecho, XPath puede considerarse, a pesar de ciertaslimitaciones de las que adolece, como un mecanismo de extraccion y direc-cionamiento de mayor nivel de abstraccion que el mero uso de expresionesregulares. Una de las contribuciones de este trabajo, de hecho, consiste, apar-te de una plataforma de implementacion que evalua expresiones del borradorde XPath 2.0, en un conjunto de extensiones propuestas para extender XPath2.0 con el fin de convertirlo en un lenguaje completamente funcional y eficazpara esta labor y otras, como la manipulacion de documentos.

Por otro lado, buena parte de los trabajos relacionados mencionados enla bibliografıa han hecho uso de clientes simples del protocolo HTTP, la ma-yorıa de ellos disponibles facilmente desde diversas bibliotecas o programasy en diversos lenguajes de programacion. Si bien la mayorıa de ellos son ca-

92

paces de proporcionar una funcionalidad basica aceptable, lo cierto es quemuchas de las tecnicas actualmente empleadas por algunos servidores Webpara mantener el concepto de sesion con los clientes que a ellos se conectan,resultan no ser tenidas en cuenta por estas soluciones. Si bien las cookiessuelen tener un comportamiento generico normalizado y es posible su facilimplementacion en los clientes HTTP al estar bien recogidas y localizadasentre las cabeceras de este protocolo, otras tecnicas, como ciertos identifica-dores de sesion, que se pueden encontrar ocultos entre los parametros de laspaginas Web, pueden facilmente hacer malfuncionar el comportamiento deun cliente HTTP que no los contemple debidamente. Dicho de otro modo, losactuales clientes HTTP utilizables para los procesos de navegacion automati-ca tienen un bajo nivel de soporte para el conjunto de acciones implıcitas queotras herramientas como los browsers graficos sı realizan bien. Cabe destacarque aquellos enlaces que no figuran explıcitos segun las habituales normasde HTML, sino que funcionan como resultado de la computacion de algu-na rutina de JavaScript o similares, resultan especialmente problematicos entanto en cuanto practicamente no existe ningun tipo de soporte para estoslenguaje en muchos de estos clientes HTTP. Ello provoca que para muchosusuarios la unica forma de acceder a determinados contenidos sea a travesde un browser.

Existen numerosos proyectos que han abordado la tematica de la navega-cion automatica y de la integracion de datos del Web a lo largo de los ultimosanos. Todos ellos, incluyendo el presente, se centran en la creacion de wrap-pers o codigo de programa especializado en el tratamiento particularizado decada fuente de datos. Afrontar el problema desarrollando un unico programacapaz de navegar en cualquier sitio Web, capaz a su vez de solventar todaslas heterogeneidades de cada servidor, resulta algo impracticable en tanto encuanto se necesita para ello introducir semantica necesaria para poder au-todetectar la informacion necesaria para la navegacion, manejando aspectoscomo sinonimos y reconociendo al momento los enlaces que se deben seguiry los formularios (campos incluidos) que se deben rellenar, lo cual resultademasiado complicado incluso para tareas sencillas. El Web Semantico esuna buena alternativa que intenta basar este reconocimiento semantico en eluso de metadatos que permitan ser utilizados para la deduccion acerca decomo efectuar las acciones basicas explıcitas de la navegacion (ver apartado2.2). Sin embargo, el Web Semantico aun tiene importantes flecos que debenresolverse, y, en cualquier caso, no parece estar enfocado al Web legado, sinoa un nuevo Web creado a partir de esos metadatos.

93

Capıtulo 4

Seleccion de tecnologıas para laautomatizacion de tareas en elWeb

En este capıtulo se realiza un analisis acerca de las tecnologıas concretasque han sido estudiadas para ser utilizadas en este trabajo y que de algunau otra manera han planteado alguna contribucion para facilitar la automati-zacion de tareas en el Web. Todas ellas ya existıan antes de la realizacion deeste trabajo y pueden ser consideradas como estandares en sus respectivoscampos de actuacion, razon por la cual, este capıtulo no presenta una con-tribucion especial a esas tecnicas, sino tan solo una breve descripcion de lasmismas. Si acaso, una contribucion original de este trabajo sı puede consistiren la adecuada combinacion de cada una de ellas para resolver de la mejormanera posible el problema de la automatizacion de tareas en el Web, peroeso es algo que aparece desarrollado en los capıtulos 5 y 6. Buena parte delas ideas reflejadas en esos capıtulos proceden de las tecnologıas descritas eneste.

Estas tecnicas estan clasificadas en un metodo formal (Message SequenceCharts), cinco estandares del W3C, algunos de ellos ya evolucionados, comoDOM, o XSLT (aunque existen borradores mas avanzados de la version queha sido objeto de este estudio), otros aun en fase de borrador, como XPath2.0, XPointer y XQuery, y finalmente un estandar de facto como lo es el inter-faz SAX para programacion sobre XML orientada a eventos. Hay que anadirque estas no han sido las unicas tecnologıas que han influido en el disenode la solucion propuesta en esta tesis para la construccion de agentes Web.Otras tecnologıas como el lenguaje de programacion WebL o las expresiones

95

regulares con las que se pretende contemplar el vacıo que en ese aspecto tieneXPath, han influido igualmente realizando su propia aportacion.

4.1. MSC

Los Message Sequence Charts o Cuadros de Secuencias de Mensajes sonrepresentaciones graficas de especificacion de requisitos de diseno de sistemasconcurrentes y que muestran el intercambio temporizado de mensajes entrelos componentes de un sistema. Los MSC constituyen representaciones abs-tractas, capaces de ser usadas en muy diversos ambitos y siendo ademas faci-les de entender por mucha gente, incluso no expertos. Aunque en su nacimien-to, los MSC estuvieron inicialmente pensados para representar el intercambiode senales entre componentes electronicos de sistemas de telecomunicaciones,su incorporacion a los formalismos establecidos por la ITU (International Te-lecommunication Union) de la mano de otro formalismo bien conocido comoSDL (Specification and Description Language) [75] supuso una gran acep-tacion por muy diversos colectivos y muy variados usos, llegando a realizarimportantes aportaciones al mundo de la ingenierıa del software, como lodemuestra su decisiva influencia sobre la representacion grafica de los dia-gramas de secuencia de UML [108], que pueden ser considerados como unaversion orientada a objetos de los MSC con pequenas diferencias que estanintentando ser solventadas por las revisiones de ambas especificaciones. Enesa misma referencia bibliografica se apunta, por ejemplo, que los diagramasde secuencia son una particularizacion algo mas practica y orientada a la pro-gramacion con objetos, mientras que los MSC tienen un fundamento muchomas teorico, vienen acompanados de una semantica formal y son aplicablesa mas campos que el de la orientacion a objetos. De hecho, los MSC puedenaplicarse en otros muchos contextos aparte de los ya contemplados por SDL.

Ademas de la importancia que conceden a la representacion grafica, losMSC incorporan la valiosa aportacion de poder ser representados textual-mente, de forma que resultan igualmente modificables y analizables por he-rramientas no graficas. Dicha representacion textual sirve de base para ladefinicion de la semantica formal que incorporan los MSC y que les permiteestar sujetos a la demostracion automatizada de algunas propiedades de losescenarios reproducidos, como por ejemplo la imposibilidad de que determi-nado mensaje A sea enviado con antelacion a la recepcion de otro evento enel sistema, como la recepcion de otro mensaje B en algun otro componenteo la ejecucion de alguna accion.

96

Los MSC se han convertido en una potente tecnica de especificacion delcomportamiento de un sistema desde el punto de vista de las interacciones desus componentes. Al ser facilmente entendible por no expertos en programa-cion, suelen formar parte de los documentos de especificacion de requisitosque se intercambian ingenieros y analistas con sus clientes, constituyendo unarepresentacion visual muy descriptiva de la interaccion bajo distintos esce-narios entre diversos componentes, especialmente entre aquellos que formanparte de un sistema distribuido. Los MSC pueden ser usados desde los pri-meros pasos del diseno del software, gracias a lo cual, los errores detectadosmediante su uso adelantado son resueltos con un menor coste que en etapasposteriores. En los ultimos tiempos se ha motivado mucho el desarrollo dealgoritmos para una variedad de analisis de MSC consistentes en la detec-cion de condiciones de carreras, conflictos de tiempos, toma de decisiones nolocales, o incluso capacidad de generacion de automatas finitos concurren-tes que simulen el sistema modelado por el MSC, por lo que son varias lasherramientas utilizables para analizar los problemas derivables en etapas dediseno gracias al examen de los MSC.

Desde el ano en el que nacieron (1992) hasta la actualidad, los MSCha venido incorporando nuevas funcionalidades en sucesivas ampliaciones re-visadas por la ITU, la entidad que lo ha estandarizado. Los MSC se hanconvertido en una tecnologıa particularmente util en el modelado de las in-teracciones propias de protocolos en las comunicaciones, ası como tambienpara la representacion de llamadas a procedimientos o metodos, incluyendoRPC. Su interes ha suscitado tambien en los ultimos tiempos, el desarrollo deherramientas capaces de transformar representaciones de MSC en otros tiposde formalismos de especificacion, como SDL, Statecharts [71], o Promela [73].Incluso, los MSC ya han sido empleados como metodo de especificacion en eldesarrollo de aplicaciones alojables en servidores Web, como ocurre con [27].

Los MSC presentan mejores habilidades para representar aspectos de inte-raccion, intercambio de mensajes y concurrencia que otros metodos formalespara el caso del Web frente a otros metodos formales como LOTOS [33],Estelle [116] or SDL [75].

A continuacion se mencionan los componentes mas importantes que sepueden encontrar en un MSC.

4.1.1. Entidades

Estan representadas por lıneas verticales, y modelizan cada uno de loscomponentes (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 deldibujo de un componente le suceden a este con anterioridad a los que estanrepresentados en las partes inferiores. Ello implica que ningun mensaje debeser enviado o recibido y ninguna accion debe ser ejecutada por un componen-te del sistema hasta que, desde el punto de vista de su representacion grafica,no se hayan procesado todos los eventos anteriores que consten previamenteen su representacion. Una representacion de tres entidades puede encontrarseen la figura 4.1.

Figura 4.1: Entidades de un MSC

4.1.2. Mensajes

Estan representados por las flechas, horizontales o diagonales, que nacende una entidad y mueren en otra. El esquema permite a su vez la repre-sentacion de mensajes intercambiados con el entorno externo del sistemarepresentado, ası como posibles mensajes enviados perdidos por el caminoe incapaces de llegar a sus destinos. Un mensaje representado por una fle-cha horizontal entre dos componentes indica que su tiempo de latencia espoco considerable, mientras que otro mensaje que aparezca con mayor dia-gonalidad representa un mayor retardo desde el momento del envıo por elcomponente emisor hasta el momento de la llegada al componente receptor.Una representacion del intercambio de mensajes entre varios componentespuede encontrarse en la figura 4.2.

4.1.3. Acciones

Otros tipos de elementos representables en un MSC lo constituyen lasacciones que cada componente puede realizar sin interaccion con las demasentidades, consistentes en computos internos. Estos procesamientos de datospueden ser realizados para dar respuesta a una peticion codificada en un

98

Figura 4.2: Mensajes de un MSC

mensaje, para preparar el lanzamiento de nuevos mensajes que ser lanzadosa otras entidades, o para analizar el resultado de respuestas recibidas. Lasacciones se representan en los MSC con rectangulos. Las acciones puedeninvolucrar la ejecucion de sentencias como llamadas a funciones o procedi-mientos ejecutados por la propia entidad y solo se consideran terminadascuando los computos terminan o esas llamadas a funciones o procedimientosretornan. Una representacion de una accion ejecutada entre la recepcion deun mensaje a y el envıo de una respuesta b puede contemplarse en la figura4.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 sistemarepresenta la secuenciacion relativa de los eventos que suceden en ese com-ponente, lo cierto es que en dicho eje no existe medida alguna que representetemporizaciones ni medidas acerca del momento exacto en el que se esperaque ocurran los eventos. En un MSC se refleja el orden posible de los eventosque ocurren globalmente en el sistema, pero no necesariamente se dan medi-das acerca de los tiempos que deben transcurrir entre dichos eventos. En lafigura 4.3 aparece claramente representado un sistema de dos entidades i y jde 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 accion y a continuacion envıaun mensaje de respuesta b a la entidad j. Sin embargo, en ningun lugar delmodelo aparecen restricciones acerca de cual debe ser el tiempo transcurridoentre dichos eventos, ni es tampoco predecible ni acotable el tiempo existenteentre el envıo del mensaje a y la recepcion del mensaje b por la entidad j.Para poder contemplar en el modelo la duracion maxima de estos interva-los entre eventos, los MSC permiten definir temporizadores, de forma que alvencimiento de un temporizador en una entidad se pueda provocar el com-portamiento de una accion especial en dicha entidad que haga un tratamientode la situacion. Los MSC ofrecen para ello operadores para crear y desactivartemporizadores, ası como una marca para senalar el evento de activacion deltemporizador. Distintos tipos de operadores de temporizadores, cada uno deellos nombrado con un nombre distinto, y para los cuales hay distintos com-portamientos representados (establecimiento, desactivacion, 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 completamentedeterminado, sino un conjunto de eventos pueden ocurrir en cualquier or-den, de forma no determinista. En aras de que las representaciones sean losuficientemente flexibles y permitan representar en un mismo grafico todaslas posibles variantes de esas ordenaciones, tıpicamente atribuibles a aspec-tos no controlables como retrasos impredecibles en las comunicaciones, enla recepcion o el envıo de varios mensajes, los MSC permiten la definicionde zonas especıficas en las entidades, llamadas corregiones representadas porfragmentos dibujados con trazos discontinuos en las entidades, de forma que

100

los mensajes que parten o llegan a una corregion pueden ser enviados o re-cibidos en cualquier orden posible respecto del resto de los eventos definidosdentro de la misma corregion. Ası pues, dentro de una corregion con n even-tos, se estaran representando los n! casos posibles de ordenacion de una solavez. Un ejemplo de corregion 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 condicion es el cumplimiento de una expresion de verdad, y sirve paraindicar que el sistema ha entrado en un cierto estado. Una condicion, quedesde el punto de vista de programacion se puede asociar con una expresionbooleana, puede afectar a mas de una entidad en un sistema. El sımbolo decondicion en un MSC, que es un hexagono, aparece superpuesto a todas lasentidades a las que afecta. Las demas entidades no afectadas por la condicionse dibujan sin intersecar con el sımbolo de la condicion, o bien aparecensuperpuestas a el. En la figura 4.6 aparece representado un MSC donde laprimera condicion afecta a las entidades i y k, la segunda condicion afectasolo a la entidad i y la tercera condicion afecta a todas las entidades delsistema.

4.1.7. Creacion y destruccion dinamica de entidades

Las entidades pueden estar creadas antes del momento del que parte elmodelado del MSC y seguir existiendo despues del momento en el que terminael modelado. En ese caso, se las considera entidades de creacion estatica, y sucreacion y destruccion no forma parte del modelado del sistema. No obstante,algunas entidades tambien pueden ser creadas y destruidas dinamicamente

101

Figura 4.6: Condiciones de un MSC

en tiempo de ejecucion, dentro del modelado del sistema, como por ejemplo,como respuesta a algun tipo de evento. Tanto la creacion como la destruccionde este tipo de entidades puede ser representada en un MSC facilmente. Lacreacion de mensajes se representa con una flecha discontinua desde la enti-dad creadora (la que invoca la creacion) a la entidad creada (la que aparececomo resultado de la invocacion anterior). La destruccion de mensajes se re-presenta al final de cada entidad con unas aspas en forma de cruz, momentoa partir del cual, la entidad deja de existir. Una representacion de la creacionde dos entidades y la muerte de dos de ellas puede contemplarse en la figura4.7.

Figura 4.7: Creacion y destruccion dinamica de entidades en un MSC

102

4.1.8. Expresiones inline

Una expresion inline es una parte especial de un MSC sobre la cualesta definido un operador que conjuga la forma en la que deben aparecerlos eventos que forman parte de la expresion. Por ejemplo, una expresioninline de bucle indica que los eventos que forman parte de ella pueden serejecutados 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 mas partesde un MSC deben ejecutarse en paralelo (concurrentemente), o para indicarque, de varias partes de un MSC, se debe escoger solo alguna, quiza inclusodependiendo de una condicion que determine cual es la parte que respondeal modelado de los siguientes eventos. Existen operadores tambien para in-dicar repetitividad, es decir, que la secuencia de eventos producidos en unfragmento de un MSC se deben repetir varias veces hasta que se cumpla unacondicion de salida del bucle.

Expresion 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 estan representadas por rectangulos, donde los ope-randos estan separados por lıneas horizontales discontinuas, y donde el nom-bre del operador aparece en la esquina superior izquierda del rectangulo. Lasestructuras inline pueden anidarse unas dentro de otras. Una representa-cion de varias expresiones inline de un MSC, una de ellas anidada dentro deotra, puede contemplarse en la figura 4.8.

4.1.9. Descomposicion modular

Es habitual que en los sistemas mas complejos, el nivel de complejidadde un MSC presente dificultades de legibilidad en la representacion grafica.

103

Figura 4.8: Expresiones inline en un MSC

El numero de eventos y de expresiones inline puede facilmente llegar a serdemasiado grande, o la estructura de anidamientos puede presentar dema-siados niveles, por lo que suele ser necesario simplificar la representacion conconstrucciones mas sencillas, encapsulando las partes de mas bajo nivel paraque puedan ser convenientemente referenciadas, de la misma forma en la quese usan procedimientos y funciones en los lenguajes de programacion. Des-de el punto de vista de los MSC, la solucion habitual consiste en distribuirla informacion del modelo en varios MSC mas simples de forma que unospuedan ser referenciados por otros. Tales referencias se representan con unosrectangulos con las esquinas redondeadas, cubriendo dichos rectangulos aque-llas entidades que intervienen en el MSC referenciado. Una representacion deun MSC que referencia a otros dos MSC externos puede contemplarse en lafigura 4.9.

La figura 4.10 representa un ejemplo de MSC en el que se combinan variosde los elementos anteriores.

4.2. XPath

XPath es una recomendacion del W3C para el direccionamiento de datosen documentos XML. El actual estandar es la version 1.0 [129], recomendadadesde noviembre de 1999. No obstante, a lo largo de los ultimos anos losgrupos 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 version del estandar, la version 2.0 [141], que actualmenteesta todavıa en fase de borrador.

Sin llegar a tener toda la funcionalidad de un lenguaje de consulta tanpotente como XQuery (ver apartado 4.5), XPath permite una especificacionclara y funcional de consultas de datos en documentos y colecciones de ele-mentos XML, pudiendo por tanto ser utilizable para las labores de extraccionde datos mencionadas en el apartado 2.2.1. La expresividad de XPath permi-te que las especificaciones de expresiones de consulta sean lo suficientementepotentes como para resolver la mayorıa de las consultas usando apenas unaexpresion simple y facilmente entendible que ocupa normalmente una uni-ca lınea de texto. Ello ha permitido, por ejemplo, que actualmente se utiliceXPath 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 recorrenla 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 lascaracterısticas necesarias para poder ser utilizado por sı solo como un lengua-je de programacion completo. XPath esta disenado para ser utilizado dentrode un lenguaje anfitrion, el cual debera ser capaz de proporcionar a XPathun entorno de ejecucion con acceso a las variables del entorno y capaz deencargarse de todas aquellas tareas ajenas a la labor para la que XPath hasido disenado. Por ejemplo, XPath no contempla funcionalidades relaciona-das con la transferencia de documentos en la Red, el acceso al sistema deficheros, el envıo de formularios, la comunicacion con programas externos,la peticion de datos al usuario ni tampoco la presentacion de datos a este.Todas esas funcionalidades son ajenas a XPath, y por lo tanto, quedan dele-gadas como labores del lenguaje anfitrion en el que XPath este hospedado.Los unicos repositorios que reconoce XPath para almacenar datos son varia-bles en memoria capaces de ser accedidas y modificadas tanto por el comopor el lenguaje anfitrion en el que esta hospedado XPath. Ejemplos de co-nocidos lenguajes anfitrion de XPath son XSLT y XUpdate, pero no sonlos unicos posibles. La existencia de varios posibles lenguajes anfitriones nodebe sorprender, puesto que la sintaxis compacta de XPath esta orientadaprecisamente a facilitar su hospedaje en varios posibles lenguajes anfitriones,especialmente los basados en XML, donde las expresiones XPath son idoneaspara ser almacenadas en atributos de etiquetas XML. Sin duda, gran partedel exito de aceptacion de XSLT es debido a que buena parte de su fun-cionalidad recae sobre XPath aprovechando este sencillo y elegante tipo dehospedaje.

106

La presencia de XPath, desde que aparecio su primera version, ha estado,pese a sus multiples posibilidades, principalmente limitada a dos campos.Por una parte, XPath ha sido usado en varias bases de datos XML, donde esempleado como lenguaje de consulta para la extraccion de elementos XMLresultado. Por otra parte, y de una manera quiza mucho mas destacada porsu mayor impacto de utilizacion en un mayor numero de personas, XPathha sido una de las bases de las hojas de estilo XSLT. En XSLT, XPath esempleado para seleccionar los nodos del documento de entrada a los que seles debe aplicar las plantillas de transformacion declaradas en una hoja deestilo.

El aumento de expresividad adquirido en los borradores de la ultimaversion de XPath (concretamente en la version 2.0, actualmente en fase deborrador donde aun hay aspectos en fase de discusion) ha sido realmente im-portante en los ultimos anos. Estos aumentos de expresividad, que aparecendestacados en negrita en la figura 4.11 sobre los de la version 1.0 de XPath,permiten a XPath 2.0 ser usado, mas que un simple lenguaje de construccionde expresiones sencillas de direccionamiento de datos en documentos XML,practicamente como un pequeno mini-lenguaje de programacion de funcio-nalidades muy recortadas. Pese a que ambas versiones son en el fondo muyparecidas, la nueva version no es aun completamente compatible con el ante-rior estandar, lo cual esta provocando numerosas revisiones y debates [122]entre los grupos de trabajo del W3C donde se esta llevando a cabo el procesode homogeneizacion.

La aplicacion del nuevo borrador de XPath 2.0 para el direccionamientode datos en las paginas Web no ha sido contemplada por los trabajos rela-cionados en el capıtulo 3, ni por practicamente ningun trabajo recientementepublicado, al menos en lo que concierne al autor de esta tesis. Una de lasrazones principales que puede justificar esta falta de aplicacion de XPath 2.0reside en que este es aun un borrador que no ha pasado a ser un estandarconsolidado por el W3C, razon por la cual los desarrolladores prefieren usarla version recomendada de XPath 1.0, preferentemente en algun entorno am-pliamente conocido como lo son las hojas de estilo XSLT. Por otra parte, lagran mayorıa de las paginas Web no cumplen las reglas basicas necesariaspara poderles ser aplicadas tecnologıas XML, por lo que aplicar XPath sobreellas directamente resulta, en primera instancia, impracticable.

XPath 2.0 tal y como aparece definido, es un lenguaje funcional basado enexpresiones que necesita estar hospedado por un lenguaje anfitrion que seacapaz de albergarlo proporcionandole un conjunto de funcionalidades basi-cas, tales como mantenimiento de un entorno de ejecucion que secuencialice

107

adecuadamente la evaluacion de las distintas expresiones XPath de consulta,o que se encargue de la recuperacion y lectura de las paginas a las que se de-ben aplicar las expresiones XPath de consulta. Un tıpico ejemplo de lenguajeanfitrion para XPath es XSLT, el lenguaje de transformacion de documentosXML mediante hojas de estilo. Lenguajes de programacion convencionales,como Java, tambien pueden ser anfitriones de XPath, como ocurre cuando sehace uso de bibliotecas capaces de evaluar expresiones XPath recibidas comoargumento [62] y que devuelven sus resultados en tipos de datos conforme aun 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 version recomendadade XPath 1.0, y todavıa no hay implementaciones fiables que sirvan paracalcular expresiones XPath 2.0.

XPath esta definido como un lenguaje de expresiones, lo cual significa queson estas, las expresiones, los bloques basicos de construccion de XPath. Ellenguaje contempla varios tipos distintos de expresiones que pueden ser cons-truidos con palabras clave, sımbolos y operandos. En general, los operandosde una expresion construida con un operador son a su vez otras expresiones.La figura 4.11 contiene un resumen de las mas importantes destacando ennegrita las que son aportaciones de XPath 2.0 respecto de XPath 1.0. Lassiguientes secciones contienen una descripcion detallada de cada una de ellas.

4.2.1. Secuencias

El valor de una expresion es siempre una secuencia de valores. Una secuen-cia es una coleccion ordenada de varios valores, con un numero de elementosilimitado, pero finito, incluyendo tambien el caso de la secuencia vacıa, es de-cir, la secuencia que no contiene ningun valor. Los elementos posibles de unasecuencia son valores de tipos denominados como atomicos, esto es, valoressimples no formados por la composicion de otros valores. Ejemplos de valoresatomicos son los valores numericos (de distintas subcategorıas dependiendode su precision, como valores enteros, decimales y de coma flotante), valo-res logicos (o booleanos) y las cadenas de caracteres (strings). Cuando unasecuencia tiene un unico elemento se le denomina sigleton y el valor de lasecuencia se asimila al del unico elemento que contiene. Es decir, para XPathel valor efectivo de la secuencia (3), formada por un unico elemento cuyovalor numerico es 3, es asimilable a ese mismo valor numerico. Asimismo,las secuencias deben ser todas planas, es decir, no se admite la definicionde secuencias cuyos elementos sean a su vez otras secuencias. Por otro lado,mientras que en XPath 1.0 los tipos de datos atomicos son apenas unos po-

108

Ejes: Expr/Expr, Axis::NodeTest

Predicados: Expr[Expr]

Referencia a variables: $Var

Expresiones aritmeticas: Expr + - * div mod Expr

Llamada a funciones: QName(Expr)

Expresiones logicas: 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, basicamente los mencionados anteriormente junto con los nodos(referencias a elementos del documento XML, incluyendo el elemento raızo pagina), en los posteriores borradores del estandar el conjunto de tiposbasicos posibles ha sido ampliados con la incorporacion de tipos de datosprovenientes de XML Schema (como fechas, duraciones, URIs, ...). Ello hadotado al lenguaje de una mayor riqueza al incluir ası tipos especializadosque, 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 suentorno. Gracias a las variables, expresiones XPath pueden utilizar los resul-tados de otras expresiones XPath. El acceso al valor de una variable dentrode XPath se representa con el sımbolo del dolar $ seguido del nombre de lavariable. Las variables de XPath son accesibles por el lenguaje anfitrion deXPath de forma que este tambien es capaz de manipular los resultados deexpresiones XPath.

4.2.3. Operadores aritmetico-logicos y de comparacion

XPath permite especificar operaciones aritmeticas (sumas, restas, mul-tiplicaciones, divisiones, ...) ası como operaciones logicas (and, or, not) ycomparaciones de diversos tipos (igualdad, menor que, menor o igual que,mayor que ...), incluyendo tambien operadores para comparar el orden deaparicion de nodos dentro del documento. Todo ello permite la creacion deexpresiones sencillas capaces de calcular operaciones habituales de analisisde datos en paginas XML que pueden ser combinadas facilmente.

4.2.4. Ejes de navegacion

Los ejes de navegacion son indicadores acerca de los caminos que de-ben seguirse para saltar de un nodo a otro dentro del arbol del documento.Normalmente esta navegacion necesita hacerse en varios saltos, razon por lacual las expresiones XPath estan divididas en distintos steps o pasos, deli-mitados por barras inclinadas /. Dentro de cada paso, los saltos entre nodosestan condicionados por los denominados ejes de navegacion que indican larelacion vecinal existente entre el nodo de origen y el nodo destino de cada

110

salto. Estas distintas formas de proximidad vecinal son contempladas por elestandar de forma que sean ası explorables todos los nodos, tanto internosa un nodo cualquiera (child y descendant), como externos al mismo (pa-rent, ancestor, preceding-sibling y following-sibling). El acceso a losatributos XML de un nodo se puede realizar atravesando el eje attribute.XPath proporciona a su vez una sintaxis abreviada para cada uno de esosejes de navegacion, lo cual permite la construccion de expresiones mas cortasy 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 incluyendolo

attribute Solo los nodos atributo del arbol

child Los nodos directamente contenidos por el nodo actual

descendant Los nodos del subarbol cuya raız es el nodo actual

descendant-or-self Lo mismo, pero incluyendolo

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 quemuchas veces el atravesamiento de ciertos de esos nodos que aparecen di-reccionables por un eje de navegacion resultan no deseables. El uso de losejes de navegacion, aunque este bien combinado con una adecuada eleccionde los nombres de los elementos, resulta muchas veces insuficiente para evi-tar la navegacion por nodos no deseados. Por esa razon, XPath proporcionamecanismos adecuados para permitir la seleccion, conforme a criterios espe-cificables por el usuario, de los elementos de una secuencia obtenida en cadapaso de una expresion XPath, de manera que solo sean seleccionados del

111

documento XML aquellos componentes que cumplan un conjunto de requi-sitos establecidos, siendo descartados aquellos elementos de la secuencia queno cumplan esa propiedad. Las funciones encargadas de filtrar o seleccionaraquellos elementos de una secuencia que cumplen las propiedades especifi-cadas en una condicion se denominan predicados, y son una parte muyimportante de XPath, pues en ellos reside gran parte de su expresividad. Lospredicados se representan en XPath rodeados de corchetes [] que, situados ala parte derecha de cada paso, rodean la condicion que deben cumplir cadauno de los elementos seleccionados en ese paso para poder formar parte delresultado final.

4.2.6. Llamadas a funciones

Con el fin de poder especificar tratamientos especializados, XPath permitela llamada a funciones parametrizables con argumentos. Dichas funcionesaparecen detalladas en una biblioteca definida para el lenguaje, e incluyemultiples tipos de tratamientos para cada uno de los distintos tipos de datosmanejables en XPath. No obstante, el conjunto de funciones llamables resultaun tanto limitado ya que XPath no permite la definicion de funciones deusuario y la biblioteca utilizable tiene un conjunto cerrado de primitivas.

4.2.7. Constructores de datos secundarios

Por otro lado, si bien la idea basica de XPath es la de permitir la ex-traccion y direccionamiento de datos tal cual estos aparecen en el documentoXML (datos primarios), el estandar contempla ademas operadores capaces deobtener datos que, no figurando como tales en el documento XML de entra-da, sı son capaces de ser computados mediante sencillos algoritmos a partirde los datos que aparezcan en el documento. Ejemplos de estos operadoressencillos son la media, la suma, el mınimo y el maximo, aunque la lista esmas extensa.

4.2.8. Modificaciones introducidas en XPath 2.0 res-pecto de XPath 1.0

El actual borrador de esta tecnica es el de XPath 2.0, que, desde su pri-mera publicacion en diciembre de 2001, ha sufrido varias revisiones, siendo[141] la mas reciente de ellas. Desde entonces, el borrador de XPath ha in-

112

corporado una serie de modificaciones importantes que le han dotado de unamayor expresividad y capacidad de especificacion. Algunas de ellas son lassiguientes:

Generalizacion del concepto de secuencia

En XPath 1.0 el tipo basico de datos es el node-set, en el que el orden delos elementos es el mismo que en el documento y no se admiten elementosrepetidos. Por el contrario, en XPath 2.0, el concepto de node-set ha sidosustituido por otro mas abierto como es la secuencia, donde, a diferencia de supredecesor, se permite la aparicion de elementos repetidos y se pueden definirotros criterios de ordenacion distintos al de la aparicion en el documento.

Expresiones condicionales y de iteracion (if y for)

XPath 2.0 incorpora tambien novedades respecto a su version anterioren el campo del control de flujo para la evaluacion de expresiones XPath,algo que no aparecıa en las versiones anteriores del estandar. Nuevos cons-tructores de expresiones condicionales del tipo if-then-else y repetitivas deltipo for-in han sido incorporados, gracias a la influencia de XQuery parala definicion de expresiones condicionales y repetitivas. No obstante, la defi-nicion de este tipo de expresiones no es la misma que cabrıa esperar en unlenguaje imperativo, ya que se trata de constructores de expresiones, masque constructores de sentencias. Es decir, una expresion for de XPath, lejosde constituir un conjunto de sentencias ejecutadas secuencialmente, en rea-lidad construye una expresion en sı misma que tiene como valor la secuenciaformada por los elementos construidos en cada una de sus iteraciones.

Expresiones cuantificadas

Las expresiones cuantificadas sirven para comprobar que se cumple unadeterminada propiedad en todos los elementos de un conjunto o al menos enalguno de ellos. Para ello, proporciona dos cuantificadores, llamados some yevery, que, una vez aplicados a una propiedad o valor de verdad y a una listade elementos, determinan si la propiedad es cierta para, al menos alguno, opara todos los elementos de la secuencia.

113

Operaciones de conjuntos

Otra de las novedades incorporadas en la nueva version de XPath son losoperadores definidos para construir nuevas secuencias a partir de otras se-cuencias preexistentes. De este modo, existen operadores para crear la union(union), la interseccion (intersect) o la diferencia (except) de secuenciascomo si fueran conjuntos, esto es, eliminando los elementos repetidos y dejan-do de considerar la existencia de un orden entre sus elementos. La secuenciaformada por la union o por la interseccion de dos secuencias A y B es laformada 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 primeroque intenta, al menos en lo que el autor es consciente en la fecha de escriturade este documento, utilizar en profundidad aquellas nuevas funcionalidadesde XPath 2.0, que no estan en XPath 1.0, en el campo de la integracion dedatos semiestructurados en el Web legado basado en paginas HTML. Paraello se ha desarrollado una extension de XPath 2.0 basada en un conjun-to pequeno de nuevos, pero potentes operadores que mantienen al mınimolas diferencias con el borrador de XPath 2.0 y que aparecen detalladas enel apartado 5.5. Por otro lado, se ha proporcionado un lenguaje anfitrion,detallado en el capıtulo 6 distinto a los habitualmente usados para XPathhasta el momento, que son XSLT o las bases de datos XML. Finalmente, seha proporcionado una plataforma de ejecucion capaz de evaluar expresionesde consulta descritas en la extension propuesta de XPath de forma que losresultados de esas expresiones de consulta sean utilizables por un lenguaje deprogramacion asequible al usuario y que le permita automatizar facilmentetareas en el Web.

XPath es un lenguaje funcional basado en expresiones que esta definidocomo una recomendacion del W3C orientada al direccionamiento de partesde documentos XML. XPath permite de una forma sencilla, y con alto ni-vel de abstraccion, tener una vision en forma de arbol del modelo de datosdel documento XML, de forma que la navegacion entre los nodos del mismoresulta sencilla, pudiendo estar enfocada directamente a las partes relevan-tes del documento, sin que para ello tengan que ser tenidas en cuenta laspartes consideradas como no relevantes. El cometido para el que XPath hasido disenado es el de permitir, de una forma clara, sencilla y no ambigua,el direccionamiento de datos (textos, numeros, condiciones, y conjuntos de

114

informaciones semiestructuradas en general) dentro de documentos XML,proporcionando una vision del documento similar a la de un arbol de direc-torios en un sistema de ficheros, aunque con mayores capacidades de selecciony filtrado. XPath toma su nombre de su uso como una notacion de path ocamino a traves de la estructura jerarquica de los documentos XML.

4.3. XPointer

XPointer es un borrador del W3C [138] que esta definido como una am-pliacion de XPath para permitir el direccionamiento de partes de XML queno se corresponden con los nodos de un arbol de documento y que no podıanser direccionadas con XPath. Para ello, XPointer expande la definicion detipos utilizada en XPath con tres nuevos tipos de datos que se resumen acontinuacion:

4.3.1. Puntos

Los puntos (point) se definen como posiciones entre dos componentesdentro de los documentos XML. Un punto representa la posicion anterior oposterior a un elemento de datos del documento, como puede ser cualquiercaracter individual, entidad o nodo de un documento XML. Los puntos estandefinidos como un par formado por un contenedor y un numero entero nonegativo llamado ındice, que indica la posicion del punto dentro del conte-nedor. Cuando el contenedor es un elemento que contiene texto, el ındiceindica la posicion en caracteres del punto dentro del contenedor. Cuando elcontenedor es un elemento que puede tener nodos hijos, el ındice indica laposicion de aquel nodo hijo, cuya localizacion de inicio se corresponde conel punto. La figura 4.12, tomada de la especificacion de XPointer [138] delW3C, refleja un ejemplo en el que aparecen detallados varios puntos y nodosde texto, ası como su relacion 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. Tengase en cuentaque ello permite definir trozos de documento que no necesariamente estandentro del mismo contenedor. Por ejemplo, puede definirse un rango que em-pieza en la mitad de un parrafo y terminan en la mitad del parrafo siguiente.

115

Figura 4.12: Representacion de elementos XPointer en un fragmento XML

Los rangos son asimilables a cualquier fragmento contiguo de un documentoXML, como el que facilmente podrıa ser seleccionado mediante una herra-mienta visual haciendo una operacion de drag & drop.

4.3.3. Patrones de texto

Una de las grandes necesidades en el campo del direccionamiento de datossemiestructurados consiste en la posibilidad de reconocer textos medianteexpresiones regulares. XPath, enfocado principalmente al direccionamientode nodos, no proporciona, al menos en sus primeras versiones de XPath 2.0,funciones capaces de devolver aquellas partes de los documentos XML dondese cumple una concordancia entre el texto del documento y un patron detexto usado para hacer busquedas o reconocimiento de textos basados enexpresiones regulares. Mediante la funcion string-range() de XPointer, estoya es una realidad, pero el string recibido por esta funcion como patron esbuscado literalmente en el documento (sin posibilidad de ser interpretadocomo una expresion regular), por lo que el tipo de busquedas que se puedenrealizar con este patron 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 extension de laparte basica de XPath es un buen enfoque, porque permite ampliar la fun-cionalidad de un lenguaje preexistente dotandole de una mayor complejidad,sin que para ello se retoque la parte basica del estandar, la cual puede ser, sinembargo, suficiente para tareas mas sencillas. Teniendo en cuenta el caractereminentemente especializado de los nuevos operadores sugeridos por XPoin-ter, su relativamente bajo numero (tres), su escasa relacion con los operadoresde XPath y el hecho de que XPath por sı mismo es capaz ya de dar respuestaa 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 formadoparte de una definicion externa a XPath, en lugar de ser incorporadas alborrador de XPath como nuevos conjuntos de operadores. Sin embargo, pesea este flexible enfoque segun el cual se podrıa disponer de una tecnologıa maspotente que la que ofrece XPath gracias a unas pocas, pero importantes ex-tensiones de funcionalidad, XPointer presenta algunas caracterısticas que leimpiden ser considerada como una tecnologıa apropiada para el desarrollo deeste trabajo. Ciertamente hay buenas ideas que aporta esta recomendacionde las que tomar buena nota, pero existen igualmente problemas, entre losque se destacan unos a continuacion:

La especificacion de XPointer prohibe explıcitamente la definicion defunciones de usuario, lo cual supone una restriccion inasumible para po-der afrontar los objetivos de esta tesis, entre los cuales esta la definicionde comportamientos encapsulables por parte de los usuarios.

string-range por sı solo resulta presentar una funcionalidad algo limi-tada, ya que solo permite buscar texto tal cual dentro del documento,sin permitir generalizar las busquedas con expresiones regulares.

XPointer, desarrollado por un grupo de trabajo en el W3C distinto al dela definicion de XPath, esta basado en la version de XPath 1.0, y por lotanto no recoge las importantes ampliaciones de los nuevos borradoresde XPath 2.0. Ello probablemente dejara de ser un problema en cuantolos disenadores de XPointer empiecen a trabajar en una version basadaen 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, losavances que el grupo de XPointer ha conseguido por su cuenta no hansido incorporados en los borradores de XPath que han aparecido conposterioridad.

117

Finalmente, tampoco resulta interesante todas las nuevas funcionali-dades de XPointer. Por ejemplo, la definicion de puntos basada enposiciones numericas es muy poco tolerante a cambios en el documento(la simple insercion de una palabra o un nodo inesperado provocara uncambio en la posicion del elemento que se desea extraer, lo cual implicauna reprogramacion de las reglas basadas en posicionamientos expre-sados con posiciones numericas) y no todos los rangos definibles porXPointer interesan.

Pese a estas mınimas diferencias, buena parte de las ideas con las queXPointer extiende a XPath han sido tenidas en cuenta en el capıtulo 5.5para ampliar la funcionalidad de XPath en aquellos aspectos en los que laexperiencia ha demostrado que tales extensiones son convenientes. Para ello,no obstante, se han restringido aquellas extensiones que no aportaban unafuncionalidad interesante para acometer los objetivos de esta tesis.

4.4. XSLT

XSLT [130] es un formato de hojas de estilo muy conocido que se utilizamucho para la transformacion de documentos XML en otros documentos. Adiferencia de las tecnologıas mencionadas en este capıtulo (salvo quiza XUp-date y una version de XQuery orientada al procesamiento automatizado,llamada XQueryX [135]), XSLT sigue una sintaxis XML, donde se utiliza elconcepto de plantilla para aplicar unas reglas de transformacion a elemen-tos de documentos XML direccionados con XPath. Precisamente esa buenarelacion de complementareidad entre las hasta ahora utilizadas versiones deXSLT y XPath (versiones 1.0 en ambos casos), se ha convertido en una delas razones del exito de aceptacion de XSLT. No obstante, por debajo delenfoque de simple transformacion de XSLT, se esconde todo un lenguaje deprogramacion funcional capaz de ser un buen lenguaje anfitrion para XPath.El modelo de trabajo de XSLT es sencillo. Basta con aplicar una a una elconjunto de plantillas al modelo en arbol DOM del documento de entrada,para ası ir generando los resultados deseados en el documento de salida. Pesea usar la complejidad de DOM para acceder a un documento XML, XSLTno permite la manipulacion del documento XML de entrada, sino que sologenera nuevos documentos.

118

4.4.1. Aportaciones de XSLT

Pese a su aceptacion por un gran conjunto de desarrolladores, XSLT resul-ta ser un lenguaje limitado en varios aspectos que le impiden ser una solucioncompatible con los objetivos de esta tesis. Para empezar, su sintaxis XMLle hace ser facilmente procesable por aplicaciones, pero demasiado verbosa yextensa, por lo que resulta difıcil de mantener. De hecho, simples operacionesprogramadas en el lenguaje pueden facilmente requerir la programacion debastantes lıneas de codigo, razon por la cual los programas desarrollados conXSLT acaban teniendo un tamano similar al que podrıa tener su equivalenteen un lenguaje de programacion convencional. XSLT proporciona una visionde alto nivel en el documento y su notacion funcional le hacen ser un lenguajeapropiado para tratamientos sencillos. Sin embargo, las hojas de estilo XSLTresultan bastante poco flexibles para realizar tareas complejos.

Por otro lado, el nuevo borrador de XSLT 2.0 se encuentra ahora mismoen un serio debate de reformulacion debido a los conflictos de intereses quehan aparecido como consecuencia de la extension de XPath 2.0. Actualmenteexisten importantes problemas de integracion con XPath 2.0 debido a que laextension de este ultimo desde su recomendacion anterior ha incluido variosoperadores cuya funcionalidad ya estaba siendo contemplada por operadoressimilares de XSLT, lo cual ofrece multiples fuentes de ambiguedad para losdesarrolladores. Es por ello que esta integracion esta siendo objeto de estudiopor el grupo de trabajo. A continuacion se muestran algunos ejemplos queilustran este tipo de conflictos recientemente aparecidos:

1. En la figura 4.13 se muestran dos versiones del codigo XSLT necesariopara calcular el valor maximo de un par de variables. La primera versionesta basada en XPath 1.0, por lo que, dada la simplicidad del estandar,casi toda la labor acaba recayendo en la funcionalidad proporcionadapor XSLT. La segunda version, basada en XPath 2.0, resulta mucho massimple y compacta por el simple hecho de traspasar la funcionalidadde XSLT a XPath, quedando en una unica lınea de codigo lo que en laversion XSLT requerıa varias.

2. En este ejemplo se puede comprobar el sensible aumento de expresivi-dad y de nivel de abstraccion experimentado por XPath experimentadopor sus expresiones cuantificadas. Ambas expresiones XPath intentandeterminar la condicion de que, en un documento XML que refleja losresultados de unas encuestas, los participantes de la misma no hayandejado ninguna pregunta (question) sin contestar (el atributo @valuedebera ser no nulo). Expresar esa condicion 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: Expresion XPath reformulada con el operador if

Para ello, la expresion en XPath 1.0 contabiliza el numero de preguntasefectivamente contestadas y comprueba que ese numero coincide con elnumero de preguntas de la encuesta. Esto, que es una solucion perfecta-mente valida implica realizar siempre dos contabilizaciones que puedenser muy costosas cuando el numero de elementos es muy elevado. Por elcontrario, usando el nuevo cuantificador universal de XPath 2.0, la so-lucion, ademas de ser mas eficiente de calcular en termino medio, puesen el momento en el que se encuentra una pregunta sin contestar pue-de interrumpirse la busqueda para dar un resultado negativo, resultamas elegante, ya que simplemente se pregunta si todos los elementos dela lista de preguntas cumplen la condicion de estar respondidas. En lafigura 4.14 pueden comprobarse las formas de expresar una misma con-dicion, tanto en XPath 1.0, como en XPath 2.0, con el nuevo operadorcuantificado.

<xsl:if test="count(//question[

number(@value) > 0])=count(//question)">

<xsl:if test="every $question in

//question satisfies $question/@value > 0">

Figura 4.14: Expresion XPath reformulada con el operador every

120

4.5. XQuery

Paralelamente al lanzamiento de XPath 2.0, el mismo grupo de trabajode ese borrador ha estado trabajando en el lanzamiento de la primera versionde XQuery [142], actualmente definido tambien como borrador (aun sujeto acambios). XQuery se define como un lenguaje de consultas estructuradas pa-ra documentos XML de entrada de forma que los resultados se almacenan ennuevos documentos XML de salida. XQuery 1.0 abarca a XPath 2.0 como unsubconjunto del lenguaje al que se le han anadido extensiones especıficas nocontempladas en XPath 2.0. Esto quiere decir que toda expresion XPath 2.0es considerable a su vez como una expresion XQuery 1.0 y debe devolver elmismo resultado. El lenguaje de consultas XQuery permite realizar consultasa un documento XML como si este fuera una base de datos relacional, dandoası una vision muy estructurada del documento. Cuando el documento XMLno tiene una estructura asimilable a la de una tabla, entonces entran en juegolos operadores de XPath capaces de dar una vision en arbol. La compene-tracion entre XPath y XQuery esta garantizada, no solo por ser un objetivodel grupo de trabajo que redacta ambas especificaciones, sino tambien porel hecho de que buena parte de la funcionalidad de XQuery se encuentra yarecogida en la de XPath, donde el conjunto de operadores que pertenecen aXQuery y no pertenecen a XPath suponen una pequena, aunque significativaparte de la especificacion. XQuery es el resultado del trabajo conjunto devarias personas que han recopilado esfuerzos provenientes de varios proyec-tos relacionados con la creacion de lenguajes de consulta, tales como SQL[78], XQL [107] o XML-QL [56] entre otros. El lenguaje mantiene un granparecido con SQL y define reglas de construccion del documento XML desalida, que contendra los resultados de la busqueda.

4.5.1. Aportaciones de XQuery

Al estilo de XPointer, XQuery se presenta como una ampliacion de XPath.Sin embargo, pese a este flexible enfoque, segun el cual se permitirıa mante-ner una especificacion simple para solucionar la mayorıa de los problemas yuna especificacion mas especializada para solucionar los problemas mas com-plejos, el enfoque de XQuery hacia las bases de datos estructuradas acabarestando valor a XQuery para ser contemplado como una tecnologıa validapara afrontar los objetivos de esta tesis. A ello hay que anadir el hecho de queXQuery esta orientado, al igual que XSLT, a la creacion de un documentoXML de salida que contiene los resultados de la busqueda, pero no permiterealizar modificaciones directamente sobre el documento de entrada. No obs-

121

tante, XQuery aporta algo muy positivo de lo cual carece XPath, que es laposibilidad de asociar expresiones XPath a distintas fuentes de documentosası como integrar los datos de varias de esas fuentes.

4.6. DOM

Sin duda alguna, DOM [131] ha sido, desde su nacimiento, el interfaz deprogramacion mas conocido para el procesamiento de datos XML. Estan-darizado casi desde el nacimiento del propio XML, el interfaz DOM defineun conjunto de primitivas sencillas y potentes que permiten la manipulacionflexible del documento XML, manteniendo en memoria una representacionen forma de arbol en la cual se pueden recorrer los nodos en varios sentidos ydirecciones, incluso de forma repetida si se desea. El almacenamiento en for-ma de arbol tiene como ventaja anadida a su gran navegabilidad el hecho deque es facilmente modificable en memoria, siendo muy eficiente este modelopara pequenas modificaciones sobre grandes documentos. Sin embargo, entresus desventajas esta un elevado consumo de recursos espaciales, de formaque una representacion en memoria, dicho sea de paso, puede ocupar signifi-cativamente mucho mas espacio que la version serializada en un fichero. Sinembargo, la vision del documento como un arbol en memoria permite unagran facilidad de programacion para modificaciones en la estructura arboreadel documento. Por ejemplo, la insercion, el eliminado de nodos o la manipu-lacion repetida del valor de atributos, puede ser realizada de forma directaatacando las partes del arbol afectadas sin que el resto sufra modificaciones,siendo estos tratamientos a su vez muy eficientes en el tiempo, toda vez queel principal consumo de recursos se realiza en el analisis inicial del documen-to. Ası pues, DOM resulta ser una tecnologıa especialmente adecuada pararealizar tareas para las que otras tecnologıas mencionadas en este capıtulo,como XSLT o XQuery no son adecuadas. Ademas, dado que, los documentosdel Web no suelen ser demasiado grandes, el problema de esta los requisitosde memoria de DOM pasan a estar en un segundo plano cuando se trata deser aplicado al tratamiento de paginas Web.

4.6.1. Aportaciones de DOM

Sin duda alguna, de todas las tecnologıas de este capıtulo, DOM es la maspotente y flexible para realizar tareas de integracion de datos semiestructu-rados en el Web. Su capacidad de permitir recorridos por el documento encualquier forma y sentido la convierten en ideal para poder realizar diversas

122

extracciones de datos de un mismo documento, algo, por otra parte habitualen el ambito de trabajo afrontado en esta tesis. La supuesta sobrecarga derecursos necesarios para su procesamiento tampoco es en sı un problema, yaque los clientes, muy al contrario que muchos servidores Web, tienen muchasveces recursos mas que suficientes para procesar las paginas del Web que vanconsultando, las cuales, dicho sea de paso, tampoco suelen tener un tamanoexcesivo.

Ahora bien, si bien la idea de representar documentos en forma de arbol esuna aportacion realmente importante para el trabajo de esta tesis, el interfazDOM en sı mismo presenta la importante desventaja de presentar al usuarioun nivel de abstraccion bastante bajo, lo cual redunda en que, incluso paralas operaciones mas sencillas, sean necesarias varias lıneas de codigo. Ademassu orientacion imperativa precisa que cualquier tipo de navegacion en el do-cumento deba realizarse solicitando al programador todo lujo de detalles, enlugar de usar expresiones de mas alto nivel de abstraccion. Una solucion alproblema podrıa ser la combinacion de bibliotecas para XPath 2.0 usadas des-de programas implementados conforme al interfaz DOM. Lamentablementeno existen bibliotecas disponibles que implementen la funcionalidad de XPath2.0, ya que las pocas existentes estan definidas sobre la version anterior deese estandar. En definitiva, DOM aporta una excelente forma de represen-tar documentos navegables en memoria en forma de arbol, pero su interfazconcreto 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 electronico xml-dev hadesarrollado un interfaz de programacion orientado al procesamiento eficientede documentos XML. Para ello, en lugar de procesar todo el documento paraobtener una representacion en memoria del mismo, este interfaz se encarga depermitir al usuario definir el comportamiento del procesador del documentoante el evento de leer cada una de sus partes segun estas van siendo obtenidasdel documento de entrada. Ello permite que el analisis de grandes documentosXML pueda realizarse segun los elementos del documento XML van siendoprocesados, uno a uno, sin necesidad de ir guardando todo lo leıdo hastael momento. SAX es un interfaz que permite, pues el analisis en secuenciadel documento XML de entrada y es muy recomendable para el analisis degrandes documentos. Una de sus principales desventajas, sin embargo, sederiva del hecho de que SAX no es un interfaz de programacion adecuado

123

para la manipulacion de documentos, ya que en el codigo de la programacionde cada evento ocurrido en el procesamiento, no se puede tener acceso a laspartes del documento procesadas con anterioridad.

4.7.1. Aportaciones de SAX

Aunque factible para realizar ciertas labores sencillas, SAX resulta seruna tecnologıa inapropiada para afrontar los objetivos de esta tesis. Su bajonivel de abstraccion, 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 extraccion de datos relevantes endocumentos XML, no solo por la dificultad que impone el interfaz para elacceso a estructuras de datos de complejidad media o alta, sino por el hechode que implica realizar programas con un elevado numero de lıneas de codi-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 paginas de tamano relativamente bajo estando losretrasos causados principalmente por la latencia en la respuesta de los servi-dores y la red, mas que el consumo de recursos de memoria de los clientes,por lo que, aunque sin perder de vista el factor de la eficiencia, este resultano ser algo crıtico en los momentos actuales, al menos dentro del procesa-miento de documentos XML. Sin embargo, SAX es una opcion basada en eluso de comportamientos definibles por el usuario y es muy adecuada para elprocesamiento de documentos de gran tamano. Pese a que en los ejemplospracticos el tamano de los documentos en el Web no suelen ser demasiadovoluminosos, un interfaz basado en este tipo de procesamiento puede ser de-seable para automatizar tareas en el Web donde el volumen de los datos enun mismo documento suponen un tamano considerable, por lo que no debendescartarse las aportaciones de SAX cuando sea necesario un tratamientomas eficiente de los documentos.

124

Capıtulo 5

XTendedPath: Lenguaje para laconsulta y modificacion dedocumentos XML

El lenguaje XTendedPath descrito en este capıtulo es una propuesta delenguaje que tiene dos usos principales: la consulta y la modificacion dedocumentos XML, labores clave en el tratamiento automatizado de datos porparte de tareas que navegan automaticamente por el Web. La consulta dedocumentos es clave para la extraccion de datos relevantes, una de las ac-ciones basicas explıcitas mencionadas en el apartado 2.2. La modificacion esclave para otras acciones, como la eliminacion de datos irrelevantes, la emu-lacion de comportamientos JavaScript cuando estos afectan a la estructuradel documento o para otros comportamientos relacionados con formularios.Por ejemplo, muchas veces, el documento Web no esta formado solo por con-tenidos generados en el servidor, sino que otros son generados en el clientepor JavaScript. Por otro lado, en ocasiones la mejor representacion internade un formulario relleno es el propio subarbol del documento que contieneese formulario como elemento. Ası pues, realizar modificaciones en el relle-nado de ese formulario requiere entonces poder realizar modificaciones en larepresentacion arborea del documento.

XTendedPath, al contrario de otras propuestas ya existentes como lasmencionadas en el capıtulo 3, esta basada en varios estandares del W3Cespecıficamente disenados para el direccionamiento de datos en el Web, comoson el actual borrador de XPath 2.0 [141] y el estandar XPointer [138], aunquetambien toma ideas de XQuery, DOM y XUpdate. Hasta el momento actual,ningun trabajo conocido por el autor dentro del campo de la extraccion de

125

datos del Web legado ha utilizado XPath 2.0. De los trabajos mencionados enel capıtulo 3, solo los mas avanzados, como [94] han usado apenas XPath 1.0,que es la version que esta estandarizada actualmente, la cual se ha encontradonormalmente embebida dentro de hojas de estilo XSLT 1.0, para extraer losdatos en forma de documentos. Otros trabajos, como [111] hacen uso deXQuery como lenguaje de consulta, pero solo son aplicables a paginas Webmuy estructuradas, asimilables a tablas y datos muy regulares, lo cual noes siempre factible. Por el contrario, XTendedPath esta disenado para poderser usado en cualquier pagina HTML o XML pese a que esta carezca de unafuerte estructura.

5.1. Problemas de XPath 2.0

Un problema general de la actual especificacion de XPath 2.0, al menostal y como esta definido su actual borrador es que algunas tareas de extrac-cion de datos no pueden ser realizadas con XPath 2.0. Por otro lado, otrastareas sı pueden ser realizadas, pero de una forma muy ineficiente. Todo elloesta debido a ciertas carencias del lenguaje que son abordadas en esta secciony para las que XTendedPath, descrito en el apartado 5.3 se presenta comouna solucion, extendiendo a XPath 2.0 y a XPointer con un conjunto mınimode constructores para poder aumentar considerablemente su expresividad.

Si bien las carencias de XPath 2.0 a las que se hace referencia en esteapartado pueden ser resueltas mediante el uso de funcionalidades propias desus lenguajes anfitrion (normalmente plantillas XSLT), el hecho de delegaren esos lenguajes externos la programacion de estas tareas impide a XPathser usado por sı mismo como un lenguaje de consulta autocontenido yutilizable en entornos legados. A continuacion se muestran algunos ejemplosde esos problemas, mencionados en [127]:

5.1.1. Procesamiento incremental

La expresion “for” en XPath 2.0 no puede ser usada cuando el resultadode procesar cada elemento en una secuencia depende del procesamiento delos elementos anteriores. Es posible que en algunos casos ese procesamientosı pueda realizarse, pero de una manera muy ineficiente. Por ejemplo:

Calcular el producto de todos los numeros 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 solucion XPath 2.0 es difıcil e ineficiente es elsiguiente:

Dada una secuencia de nodos book dentro de un documento XML querefleja las ventas de una tienda, calcular la cantidad de dinero vendido porcada libro (calculada como el producto de su precio por su numero 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 secuenciae importe acumulado es el importe acumulado por las ventas de los libroshasta ese momento, desde el principio de la secuencia de libros hasta el librocorrespondiente a cada posicion.

Para obtener ese resultado, se puede usar la expresion escrita en XPath2.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: Expresion XPath 2.0 que calcula importe de ventas con subtotalesparciales

La expresion de la figura 5.1 tiene complejidad cuadratica. Es decir, siN es el numero de elementos dentro de $items, se realizan N × (N + 1) /2 sumas y N × (N + 1) / 2 multiplicaciones, lo cual es bastante ineficientedesde un punto de vista de complejidad de algoritmos.

Para conseguir expresar el algoritmo con complejidad lineal, mucho maseficiente, serıa necesario usar una variable que acumulara las sumas parcialesrealizadas hasta el momento, con el fin de no volverlas a recalcular en poste-riores iteraciones. Ası pues, el algoritmo anterior deberıa poder reescribirsede 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: Pseudocodigo basado en variables que calcula subtotales

127

Pese a lo que pudiera parecer, la expresion de la figura 5.2 no es unaexpresion XPath. XPath es un lenguaje funcional basado en expresiones, noun 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 serevaluadas una detras de otra como sentencias imperativas. El constructor forde XPath solamente admite una expresion return en su interior, que sirvepara devolver el elemento que debe formar parte de la secuencia resultado,conforme se va recorriendo una secuencia de entrada. Por otro lado, pese aque en los lenguajes imperativos sea algo comun que una variable vaya siendosobreescrita con diversos valores a lo largo de la ejecucion, los lenguajes fun-cionales no permiten ese tipo de efectos laterales, porque se dedican a la meraevaluacion de expresiones funcionales en las que los resultados se obtienende aplicar funciones a unos argumentos. Dicho de otro modo, las variables enXPath pueden ser consultadas facilmente, pero no pueden ser sobreescritascomo en un lenguaje de programacion imperativo. Por ese motivo, el codigode 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 notacioncompletamente 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: Pseudocodigo basado en funciones que calcula subtotales

Como puede apreciarse en la figura 5.3, el codigo que aparece tiene unanotacion completamente basada en expresiones y no en sentencias, propio deun lenguaje de programacion funcional. Para ello se ha creado una funcionauxiliar 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 acarreandopara el resto de los elementos de la secuencia.

Para construir el codigo de la figura 5.3 se han usado dos importantescaracterısticas no existentes en XPath 2.0. Por un lado, se ha definido unafuncion auxiliar de usuario, denominada sumalibros de dos argumentos yposteriormente se ha llamado a esa funcion para calcular el resultado final. En

128

terminos de programacion funcional al nombre sumalibros se le ha asociadouna expresion lambda [90] o funcion de usuario.

Los lenguajes funcionales suelen definir tambien variables con una cons-truccion let en la que se declara una variable a la que se le asocia un valorque es inmutable a lo largo de toda la ejecucion, como por ejemplo en laexpresion: let $i = 3 in $i + $i, cuyo resultado serıa 6. Sin embargo, ni lasexpresiones lambda ni el constructor let forman parte del lenguaje XPath. Elconstructor let (que a su vez tambien puede ser reescrito como una expresionlambda) forma parte del lenguaje XQuery (basado en XPath 2.0), pero noesta considerado en XPath 2.0. Por otro lado, aunque en XPath esta permi-tida la llamada a funciones, estas no tienen forma de ser construidas por losusuarios y su uso se limita a un conjunto reducido de funciones localizablesen bibliotecas del lenguaje.

5.1.2. Dificultad para calcular valores agregados

XQuery permite la definicion de funciones de usuario y del constructor let.Sin embargo XQuery, al igual que XPath, presenta dificultades para calcularvalores agregados de una secuencia, especialmente cuando esos valores debenser calculados de una forma no trivial. Por ejemplo:

Obtener los nodos con maximo valor de una secuencia, especialmenteen el caso en el que el valor de cada nodo de esa secuencia deba sercomputado por una expresion compleja.

Obtener los nodos con distinto valor de una secuencia, especialmenteen el caso en el que el valor de cada nodo de esa secuencia deba sercomputado por una expresion compleja.

En XPath 2.0 no existe una forma generica de evaluar este tipo de expre-siones recibiendo como parametro una funcion que evalue esas expresionescomplejas a las que se hace referencia. Por esa razon, en XPath 2.0 deben es-cribirse multitud de expresiones similares, cada una de ellas para cada posibleexpresion compleja y sin posibilidad de ser reutilizadas. Estas repeticiones yla falta de capacidad de reutilizacion del codigo provoca grandes consumosde tiempo, propension a errores y generalmente ocasionan la generacion decodigo difıcilmente mantenible y poco reutilizable.

Ejemplos de problemas de este tipo son los siguientes:

Obtener la suma de los cuadrados de los numeros de una secuencia

129

Extraer aquellos numeros de una secuencia, para los cuales f(item) esmınimo

Para una funcion f(), comprobar que todos los valores f(item) de unasecuencia son mayores que cero (o menores o iguales a cualquier otrovalor)

Para una funcion f(), comprobar que todos los valores f(item) de unasecuencia aparecen en orden creciente

Para las expresiones anteriores, aunque es posible encontrar una solucionbasada en XPath, esta sera difıcil e ineficiente. Ademas, para cada posiblefuncion f() debera reescribirse cada expresion, ya que las funciones no puedenser pasadas como argumentos a otras funciones.

5.1.3. Combinar dos o mas secuencias en una nueva

Es posible querer combinar dos o mas secuencias en una sola. Dadas (a1,a2, ..., aN) y (b1, b2, ..., bN) con XPath no es sencillo calcular expresionescomo:

(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) (conjuncion logica and elemento aelemento)

...

5.1.4. XPath no puede expandirse indefinidamente

La complejidad de XPath ha crecido considerablemente en los ultimostiempos, pasando de ser un sencillo conjunto de expresiones a un lenguajemucho mas potente. Sin embargo, la capacidad de seguirse expandiendo re-sulta un tanto limitada. Por otro lado, aunque en el grupo de trabajo estantrabajando en una homogeneizacion del lenguaje, existen ahora mismo variasformas de expresar tareas similares. Ello indica hasta que punto es necesarioreordenar la capacidad de expansion del lenguaje, y que actualmente esta aunen una fase inmadura y es compleja y difıcil de organizar. Un lenguaje que

130

proporcione soporte al orden superior puede proporcionar una solucion 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 mientrasque el lenguaje permita que nuevas funcionalidades puedan ser facilmenteproducidas y acumuladas en una biblioteca de funciones reusables de usogeneral.

5.1.5. Poca flexibilidad para llamar a ciertas funciones

La llamada a funciones como sort o distinct-values resulta poco flexible yaque no es posible especificar las funciones de comparacion entre elementos.Serıa deseable poder ordenar una secuencia pudiendo especificar el criteriode ordenacion en una funcion definible por el usuario y con la que se pudieraparametrizar el comportamiento de la funcion sort.

5.1.6. Poca reusabilidad para expresiones de tipo “for”

En la expresion de la figura 5.4, la expresion expression no puede serreutilizada, salvo que se copie y pegue en otro sitio, debiendo ser modificadade forma que las referencias a la variable del rango que recorre la secuenciasean convenientemente renombradas.

for $i in $sequence

return expression

Figura 5.4: Ejemplo de expresion de tipo for

Por el contrario, con soporte a funciones de orden superior, podrıa usarsela funcion map(f, $sequence) como equivalente a la de la figura 5.4 de formaque el codigo de la funcion 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 dedefinir funciones de usuario, para demostrar la facilidad de programacionde esta aproximacion y su facil legibilidad por los usuarios programadores,los siguientes ejemplos estan proporcionados en lenguaje Haskell [113]. En elapartado 5.5.2 se proporciona una reescritura de este tipo de funciones enXTendedPath, la extension de XPath que se presenta en el apartado 5.3. Ellenguaje Haskell se usa en este apartado solamente como ejemplo de conve-niencia. En ningun caso se intenta recomendar con ello que su sintaxis seaadoptada por XPath 2.0. Para comprender los siguientes ejemplos, algunasconvenciones de Haskell deben ser explicadas.

Convenciones de representacion en Haskell

Definir una funcion en Haskell es muy sencillo. La expresion f x y = x *y define una funcion f que devuelve el producto de sus dos argumentos.

La expresion [1, 2, 3] expresa una lista formada por tres elementos, similara la secuencia (1, 2, 3) de XPath. [] denota la secuencia vacıa, equivalente a() en XPath.

Un operador infijo puede ser usado como una funcion cuando se le escribeentre parentesis. De esta forma: (+) 1 2 = 1 + 2 = 3.

El operador : es usado para indicar que un elemento esta al principio deuna lista. De esta forma, x : xs define una lista donde x es el primer elementoy xs es el resto de la lista.

La funcion flip toma como argumento una funcion y otros dos argumentosy produce como resultado la llamada a esa funcion tomando los argumentosen orden inverso. Ası: flip f x y = f y x.

Igualmente, la recursion a lo largo de los elementos de una lista puede serdefinida como aparece en la figura 5.5. La funcion foldl toma tres argumentos,una funcion f(), que toma dos argumentos, un valor z y una lista. foldl es unade las funciones mas generales que trabajan sobre listas. Recorre la lista deizquierda a derecha, aplicando f() a cada elemento y al resultado acumuladohasta el momento, que es tenido en cuenta para el siguiente elemento de lalista. De una forma similar, tambien puede ser definida foldr.

Como puede comprobarse facilmente, foldl (+) 0 xs es la suma de todoslos elementos que aparecen en la secuencia xs. De la misma forma, podrıaescribirse sum xs = foldl (+) 0 xs para definir la funcion sum. Analogamente,se podrıa definir product xs = foldl (*) 1 xs que calcularıa el producto delos elementos de una secuencia, lo cual serıa una solucion 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 cualquiere decir que las definiciones anteriores podrıan haber sido reescritas dela siguiente forma: sum = foldl (+) 0 y product = foldl (*) 1.

Invertir el orden de una lista (problema apuntado en la seccion 5.1.1)puede ser facilmente realizable con reverse = foldl (flip (:)) [].

Concatenar los elementos de una lista (problema tambien apuntado en laseccion 5.1.1) puede realizarse llamando simplemente a la funcion concat =foldr (++) [] donde (++) es el operador de concatenacion para listas.

Por otro lado, combinar dos listas de igual longitud en una sola puede serrealizado con la funcion zip() que aparece en la figura 5.6. En ella, la funcionf() es aplicada a cada par de elementos de la misma posicion en ambas listas,y el resultado de esa funcion forma el elemento que esta en esa posicion dentrode 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 funcion zip() resuelve directamente muchos de los problemas mencio-nados en el apartado 5.1.3. Por ejemplo (a1 + b1, a2 + b2, ..., aN + bN) essolamente zip (+) as bs. (a1 × b1, a2 × b2, ..., aN × bN) es solamente zip(*) as bs.

Una funcion muy util 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 todoslos resultados intermedios acumulados, de forma que el primer elemento dela lista resultado es q y el ultimo es el resultado acumulado de toda la listade entrada. La longitud de la secuencia de salida es superior a la de entradaen una unidad.

En el caso en el que este garantizado que la secuencia de entrada xs noeste vacıa, la siguiente funcion scanl1 puede ser definida, conforme a la figura5.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 comobase o elemento neutro, sino que toma al primer elemento de la lista comoelemento base para calcular las acumulaciones. Como puede comprobarse,scanl1 op xs produce una lista de longitud igual a la de xs en la que aparecenlos resultados acumulados de la operacion op desde el principio de la listahasta la posicion actual. Por ejemplo: scanl1 (+) [1, 2, 3] = [1, 1+2, 1+2+3]= [1, 3, 6].

scanl1 puede ser usado en combinacion con zip para resolver el problemamencionado en el apartado 5.1.1. Por ejemplo, scanl1 (+) (zip (*) [1,2,3][2,2,2]) devuelve [2, 6, 12], que es basicamente lo que se querıa calcular conel problema de las ventas de los libros.

Si se asocia a la funcion filter el significado de los predicados de XPath,de forma que filter p xs = [ x | x ∈ xs ∧ p x ], pueden encontrarse facilmentesoluciones para los problemas mencionados en el apartado 5.1.2. Por ejem-plo, se pueden calcular todos los elementos de una secuencia para los cualesf(item) es mınimo con la expresion de la figura 5.9. En ella se declara ys comouna lista temporal que almacena el resultado de aplicar la funcion f() a lasecuencia de entrada, se declara fmin como el mınimo valor de esa secuencia,y a continuacion se seleccionan aquellos elementos de la secuencia de entradapara los que f() da ese valor mınimo fmin. El punto es considerado en Haskellcomo el operador de composicion 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 funcion f() devuelveresultados positivos.

Finalmente, comprobar que, para una secuencia y una funcion 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 ordenadacreciente, 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 lasecuencia de entrada. Posteriormente, la lista zs es fragmentada en dos sublis-tas. init zs contiene la sublista en la que se ha eliminado el ultimo elementoy tail zs contiene la sublista en la que se ha eliminado el primer elemento.Para esas dos sublistas, se comprueba que los elementos estan ordenados porparejas y finalmente se dilucida si todas esas parejas cumplen el hecho deestar ordenadas o si, por el contrario, hay algun 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: extension de

XPath 2.0

XPath es muy util para direccionar elementos en un documento XML,cuando estos son facilmente ubicables en un arbol del documento, es decir,cuando el direccionamiento sea sencillo y la extraccion de datos que se debenobtener no sea demasiado complicada y se corresponda con algun elemento oatributo. 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 oatributos del documento, sino que son trozos de este, o datos secundarios, esdecir, cuando son datos que deben ser procesados por algun computo espe-cificable por el usuario. XTendedPath presenta algunas soluciones siguiendolas 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 extraccion de datos en el Web que aparecen mencionadasen el apartado 2.2.1 resultan sencillas de construir y faciles de mantener. Deesta forma, expresiones XTendedPath de consulta aplicadas a cualquier docu-mento XML, son capaces de extraer los datos relevantes que cualquier tareapueda necesitar. Estas expresiones, al estar basadas en XPath 2.0, son apli-cables a cualquier documento XML y mantienen siempre una misma sintaxisuniforme e independientemente del lenguaje XML concreto que este siendousado por cada documento. En esto se difiere de algunos API como [139]que estan 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 enotro tipo de documentos. Gracias a esa generalidad, XTendedPath es aplica-ble no solo a lenguajes XML como WML, RSS, SVG, MathML o NewsML,sino que es igualmente a las paginas HTML del Web legado, aunque se re-quiere que estas tambien sigan los principios de buena formacion de XML.La plataforma sobre la que se ejecuta XTendedPath proporciona al progra-mador mecanismos adecuados para que este facilmente consiga pretratar losdocumentos que no cumplen esta propiedad con el fin de transformarlos endocumentos equivalentes bien formados. Esta transformacion se lleva a cabogracias a aplicaciones externas disenadas para esa labor, como [104, 58, 146].

Modificacion de documentos XML

Por otro lado, XTendedPath tambien puede ser usado para la modifi-cacion de la version almacenada en memoria de los documentos XML. Lamodificacion de esta estructura del documento puede afectar solo a los atri-butos, manteniendo intacta la estructura arborea de los elementos de undocumento, o puede afectar tambien a la disposicion de los elementos de undocumento modificando su estructura arborea mediante la insercion o borra-do de algunos de los mismos. Ejemplos de ambas situaciones son descritos a

136

continuacion:

Un ejemplo de modificacion que afecta exclusivamente a los atributosde los elementos de un documento puede ser el rellenado de formularios.Dicho rellenado puede facilmente llevarse a cabo modificando simple-mente en la representacion arborea del documento los valores de susatributos, de forma que queden ası rellenos de otra forma distinta aaquella en la que vienen por defecto. Basta con cambiar en una paginael 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 formulariocon nuevos datos.

La modificacion de documentos consistente en la insercion, modifica-cion o borrado de elementos dentro del arbol de un documento puedeformar parte de muy diversas tareas. Por ejemplo, en una tarea dedi-cada a eliminar la publicidad de ciertas paginas, se deseara el borradode ciertos nodos dentro del arbol de un documento. En otras ocasiones,la modificacion de la estructura de un documento realizada de formaexplıcita puede estar motivada por la falta de soporte por parte de laplataforma de ejecucion de acciones implıcitas programadas en ruti-nas JavaScript, algo que como ya se vio en el apartado 3.4 es bastantehabitual. En esos casos, la emulacion del codigo de las rutinas JavaS-cript puede ser necesaria por parte del programador de la tarea desdesu programa principal. Por ejemplo, se deseara insertar nuevos nodosdentro del documento si se desea emular a la accion JavaScript docu-ment.write, consistente en embeber en una pagina nuevos elementosescritos dinamicamente por el browser. Acciones de borrado de nodosson tambien realizables mediante XTendedPath.

Relacion de XTendedPath con XPath 2.0

XTendedPath no puede ser considerado un pionero en la extension deXPath 2.0, puesto que existen otros lenguajes igualmente basados en eseborrador del W3C. El lenguaje XQuery (ver apartado 4.5) es un supercon-junto de XPath 2.0 para la extraccion de datos de documentos y bases dedatos XML. XQuery es usado como lenguaje de consulta en documentos ybases de datos XML, pero no ha sido considerado para este trabajo porqueesta enfocado a la generacion de nuevos documentos XML, en lugar de ala estructuracion 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]tambien esta basado en XPath 2.0. Igualmente, XPointer (ver apartado 4.3)tambien esta basado en XPath, aunque su version actual toma como basela version estandar 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 enXPath.

Lenguaje Estatus Relacion con XPath Finalidad

XQuery W3C WD Extension de XPath 2.0 Extraccion de datos

XSLT 1.0 W3C Rec Anfitrion de XPath 1.0 Transformacion

XSLT 2.0 W3C WD Anfitrion de XPath 2.0 Transformacion

XPointer W3C WD Extension de XPath 1.0 Direccionamiento de partes contiguas

XUpdate XML-DB WD Anfitrion de XPath 1.0 Modificacion

XTendedPath Extension de XPath 2.0 Consulta y modificacion

Cuadro 5.1: Resumen de los lenguajes basados en XPath

XPath 2.0 es un lenguaje bastante potente, al que sucesivas revisionesrealizadas desde su nacimiento han ido incorporando cada vez una mayorfuncionalidad. Frente a la simplicidad de XPath 1.0 capaz de direcciona-mientos sencillos pero facilmente entendibles por personas que no necesaria-mente tengan conocimientos profundos de programacion, XPath 2.0 ha idoincorporando un potente conjunto de constructores que han ido aumentandosensiblemente su potencia como lenguaje de direccionamiento, asemejandolocada vez mas a un lenguaje de programacion. Un mayor detalle de esas di-ferencias entre XPath 2.0 y XPath 1.0 puede ser encontrado en el apartado4.2. Sin embargo, a pesar de esta mayor potencia de direccionamiento deXPath 2.0 respecto de su antecesora XPath 1.0, XPath 2.0 presenta algunaslimitaciones debidas principalmente a su capacidad de direccionar exclusiva-mente elementos y atributos de paginas (no pueden direccionar otras partesdel documento), y al limitado conjunto de funciones de obtencion de datossecundarios que ofrece una pequena biblioteca que no es extensible por losusuarios ni ofrece capacidades de manipulacion adecuadas para tratamientosmas complejos de los contemplados por las primitivas accesibles en esas bi-bliotecas. Por esta razon, XTendedPath ha sido creado como una extensionlo mas cercana posible de XPath 2.0. XTendedPath permite eliminar algunasde 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 debenajustarse a ser un elemento o un atributo, a la vez que permite mejorar laconstruccion de expresiones definibles por el usuario. El conjunto de estas ex-tensiones es relativamente pequeno, pero significativamente importante comopara aumentar significativamente la capacidad de expresion del estandar.

Asimismo, en XTendedPath han sido eliminadas algunas construccionesde 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 nocontemplados por XPath 2.0 (las extensiones para aumentar la flexibilidadde XPath 2.0 y su habilidad para modificar documentos). Sin embargo, lasdiferencias entre ambos lenguajes son relativamente muy pequenas. Amboslenguajes coinciden en gran parte, permitiendo que muchas construccionespuedan ser escritas de forma similar tanto en XPath 2.0 como en XTended-Path sin apenas diferencias semanticas, tal como puede verse reflejado en elapartado 5.4.

Una de las caracterısticas mejorables que ofrece XTendedPath y dondereside la mayor parte de las diferencias con XPath 2.0 es su sintaxis. XTen-dedPath esta definido con una notacion sintactica de expresiones funcionalesparentizadas, algo bastante diferente a la sintaxis reflejada por XPath, forma-da como una secuencia de pasos que implıcitamente toman como argumentolos 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 sintactica. Dehecho, en muchas de las funciones de XTendedPath que aparecen en el apar-tado 5.4 se define la expresion XPath equivalente. La notacion parentizadaen la que esta definido el lenguaje XTendedPath no es quiza la mejor quepodrıa haberse utilizado para definir los operadores del lenguaje. No obstan-te, es la que la plataforma de navegacion automatizada en su estado actualha permitido y, aunque mejorable, sus diferencias con respecto a la versionoriginal de XPath son meramente notacionales mas que semanticas. Aunquela notacion parentizada es mas verbosa, esta resulta estar mas enfocada a unamas sencilla traducibilidad ya que el arbol de llamadas de expresiones quedaen XTendedPath mas parecido a otros lenguajes de programacion graciasa esa parentizacion. No obstante, muchos parentesis que en otros lenguajesno deberıan aparecer, aquı deben escribirse para encerrar a los distintos ar-gumentos de las funciones. La aplicacion parcial de funciones currificadaspermite declarar mas facilmente algunas expresiones muy usadas en XPathque no son evualuables en el momento sino que se evaluaran en el momento

139

en el que les corresponda cuando exista para ellos un conjunto no vacio denodos de contexto a los que ser aplicadas. Las variables de XTendedPath,por su parte, no van precedidas del sımbolo del dolar $ como en XPath. Noobstante, es esperable poder mejorar esta sintaxis en futuras versiones dellenguaje gracias a una herramienta de traduccion como las que se estan de-sarrollando en el marco de unas herramientas CASE como proyectos fin decarrera dirigidos por el autor de este trabajo. Gracias a estos traductores,estas diferencias sintacticas acabaran finalmente por ser salvadas.

XTendedPath toma como base una version funcional parentizada deXPath 2.0 a la cual se le anaden nuevas funcionalidades. Ası pues, para empe-zar a definir XTendedPath se necesita empezar definiendo como se reescribenen XTendedPath los distintos componentes que ya aparecen recogidos en elestandar de XPath. El apartado 5.4 contempla esa parte comun entre amboslenguajes, mientras que el apartado 5.5 enumera las principales extensionesque 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 practicamente los mismos delos de XPath, salvo por el hecho de que se han agrupado algunos de ellospara ganar simplicidad, se les han impuesto algunas pequenas restriccionesy se les ha ampliado con algunas extensiones. Por ejemplo, en XPath 2.0las expresiones de tipo secuencia pueden albergar cualquier tipo de datoatomico, por lo que a una misma secuencia pueden pertenecer tanto valoresnumericos como nodos de un documento. En XTendedPath, para simplificarel procesamiento a los programadores, se ha impuesto la restriccion de quetodos los elementos de una misma secuencia deben ser del mismo tipo dedatos, de forma que las secuencias puedan ser solo de numeros, solo de nodoso solo de cualquier tipo de dato. Al igual que en XPath, las secuencias desecuencias estan prohibidas, por lo que todas las secuencias deben ser planas.La tabla 5.2 refleja un resumen de como los principales tipos de datos deXPath 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 semanticas

Para proporcionar una semantica no ambigua a cada uno de los opera-dores de XTendedPath, se definen a continuacion unos operadores que noforman parte del lenguaje XTendedPath. Como ya hicieron en [145, 144]con XPath, sirven para explicar formalmente la semantica de muchos de losoperadores de XTendedPath.

Funcion name

La funcion name devuelve para una etiqueta, su nombre.

name: node → string

Funcion size

La funcion size devuelve para una secuencia (de cualquier tipo), su nume-ro de elementos.

size: a* → integer

Funcion children

La funcion children devuelve los hijos de un nodo.

children: node → node*

141

Funcion parent

La funcion parent devuelve el padre de un nodo, que de existir es siempreunico. El padre del elemento raız es ∅.

parent: node → node{0,1}

Funcion attribute

La funcion attribute devuelve el valor de un atributo de un nodo. Si elnodo no tiene ese atributo, el resultado es ∅.

attribute: string → node → string{0,1}

Funcion siblings

La funcion siblings devuelve los nodos que son hijos del mismo padre delargumento.

siblings: node → node*

siblings(x) = {z | ∃ y ∈ parent(x) ∧ z ∈ children(y)}

Funcion properSiblings

La funcion properSiblings devuelve los nodos hermanos del argumento.

properSiblings: node → node*

properSiblings(x) = {y | y ∈ siblings(x) ∧ x 6= y}

Funcion self

La funcion 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 elsegundo 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 incluira x), mientras que children∗(x) son todos los descendientes de x (incluyendoa x).

Con estas funciones auxiliares, se puede empezar a definir la semanticade los operadores de XTendedPath.

5.4.3. Funciones de comparacion

Para facilitar la programacion de expresiones de comparacion, estos ope-radores se han reescrito como funciones currificadas. En la tabla 5.3 puedeverse el significado de esos operadores tanto en XPath como en XTended-Path. Puede apreciarse tambien la existencia de parentesis para separar losoperandos debido a que en la implementacion actual todos los argumentosde las funciones deben estar rodeados entre parentesis. No obstante, estasalvedad sintactica seguramente sera mejorada en futuras versiones.

Cabecera funcion 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 comparacion en XTendedPath

143

5.4.4. Funciones logicas

Para facilitar la programacion de expresiones logicas, varios de los conec-tores logicos mas habituales tambien se han reescrito como funciones currifi-cadas. En la tabla 5.4 puede verse el significado de esos operadores tanto enXPath como en XTendedPath.

En cuanto a las operaciones aritmeticas, como las sumas, restas, multi-plicaciones y divisiones, se escriben en XTendedPath igual que en XPath yen la gran mayorıa de los lenguajes de programacion.

Cabecera funcion 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 logicos en XTendedPath

5.4.5. Funcion TO: (generador de secuencias numeri-cas)

La funcion TO sirve para generar secuencias de valores numericos enteros.Se corresponde con el operador infijo to de XPath. La tabla 5.5 refleja lasformas 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 numericas en XTendedPath

144

5.4.6. Funciones EVERY y SOME: (expresiones cuan-tificadas)

Las expresiones cuantificadas EVERY y SOME sirven para dictaminarsi, bien todos, bien alguno, de los elementos de una secuencia cumplen unadeterminada propiedad. La tabla 5.6 expresa la semantica 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.

Funcion C: (eje child)

El eje de navegacion child:: de XPath sirve para seleccionar los nodoshijos de un nodo contexto. En XTendedPath es reescrito como una funcioncurrificada, 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 biendirectamente una lista de nodos de la que se deben seleccionar exclusivamen-te aquellos que sı cumplan la propiedad de ser hijos del nodo contexto. Elsegundo argumento de la funcion es una lista de nodos contexto a partir delos cuales debe empezar a evaluarse la expresion anterior de descendencia di-recta. El resultado final es una secuencia de nodos. La cabecera de la funciones la siguiente:

C: (string|node*) → (node|node*) → node*

En la tabla 5.7 se detalla la semantica de la funcion C. En todos los casosse 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: Semantica de la funcion C

A modo de ejemplo, la tabla 5.8 muestra el significado currificado de lafuncion C. En todos los casos se asume que b: node*, s: string, a: node*. Elvalor, como cabe esperar es el de una expresion lambda como la que apareceen 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 aplicacion de la currificacion en la funcion C

Funcion D: (eje descendant)

El eje de navegacion descendant:: sirve en XPath para seleccionar losdescendientes del nodo de contexto a cualquier nivel de profundidad. Dichooperador se reescribe en XTendedPath de forma similar a como se reescribe eleje child::, conservando, al igual que en las siguientes funciones, la forma deexpresion currificada, razon por la cual, no se va a detallar el uso currificadode esas funciones de ahora en adelante en detalle. Su semantica es practica-mente la misma que la del eje child, salvo que se no restringe solo al primernivel de descendencia directa, es decir, a los hijos, sino que se exploran todoslos niveles de descendencia.

D: (string|node*) → (node|node*) → node*

En la tabla 5.9 se detalla la semantica de la funcion D. En todos los casosse asume que b: node*.

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: Semantica de la funcion D

Funcion DORSELF: (eje descendant-or-self)

El eje de navegacion descendant-or-self:: se reescribe en XTendedPath deforma similar al eje descendant::, salvo por el hecho de que se incluye al nodocontexto entre el resultado. La funcion DORSELF sirve para calcular esosdescendientes.

DORSELF: (string|node*) → (node|node*) → node*

En la tabla 5.10 se detalla la semantica de la funcion DORSELF. Entodos 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: Semantica de la funcion DORSELF

Funcion P: (eje parent)

El eje de navegacion parent:: se reescribe en XTendedPath de forma si-milar al eje child::, salvo por el hecho de que ya no se buscan nodos hijosdel actual, sino el nodos padre de cada nodo de la secuencia recibida comosegundo argumento. La funcion P devuelve la secuencia formada por estospadres.

P: (string|node*) → (node|node*) → node*

En la tabla 5.11 se detalla la semantica de la funcion P. En todos los casosse asume que b: node*.

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: Semantica de la funcion P

Funcion A: (eje ancestor)

El eje de navegacion ancestor:: se reescribe en XTendedPath de formasimilar al eje descendant::, salvo por el hecho de que ya no se buscan nodosdescendientes del actual, sino nodos ancestros del mismos. La funcion A sirvepara calcular esos ancestros.

A: (string|node*) → (node|node*) → node*

En la tabla 5.12 se detalla la semantica de la funcion A. En todos loscasos 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: Semantica de la funcion A

Funcion AORSELF: (eje ancestor-or-self)

El eje de navegacion ancestor-or-self:: se reescribe en XTendedPath deforma similar al eje ancestor::, salvo por el hecho de que se incluye al nodocontexto entre el resultado. La funcion AORSELF sirve para calcular esosancestros.

AORSELF: (string|node*) → (node|node*) → node*

En la tabla 5.13 se detalla la semantica de la funcion AORSELF. En todoslos 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: Semantica de la funcion AORSELF

Funcion PS: (eje preceding-sibling)

El eje de navegacion preceding-sibling:: se reescribe en XTendedPath deforma similar a los ejes anteriormente mencionados, salvo por el hecho deque ya no se buscan nodos hijos del actual, sino los nodos hermanos que seananteriores al mismo. La funcion PS devuelve una secuencia formada por esosnodos.

PS: (string|node*) → (node|node*) → node*

En la tabla 5.14 se detalla la semantica de la funcion PS. En todos loscasos se asume que b: node*.


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: Semantica de la funcion PS

Funcion FS: (eje following-sibling)

El eje de navegacion following-sibling:: se reescribe en XTendedPath deforma similar a los ejes anteriormente mencionados, salvo por el hecho deque ya no se buscan nodos hijos del actual, sino los nodos hermanos que seanposteriores el mismo. La funcion FS devuelve una secuencia formada por esosnodos.

FS: (string|node*) → (node|node*) → node*

En la tabla 5.15 se detalla la semantica de la funcion FS. En todos loscasos se asume que b: node*.

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: Semantica de la funcion FS

Funcion PREC: (eje preceding)

La funcion PREC extrae de un documento todos aquellos nodos que apa-recen antes del nodo contexto en el orden del documento, sin incluir a susnodos ascendientes, tal y como especifica el estandar de XPath para el ejepreceding.

PREC: (string|node*) → (node|node*) → node*

En la tabla 5.16 se detalla la semantica de la funcion 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: Semantica de la funcion PREC

Funcion FOLL: (eje following)

La funcion FOLL extrae de un documento todos aquellos nodos que apa-recen despues del nodo contexto en el orden del documento, sin incluir a susnodos descendientes, tal y como especifica el estandar de XPath para el ejefollowing.

FOLL: (string|node*) → (node|node*) → node*

En la tabla 5.17 se detalla la semantica de la funcion 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: Semantica de la funcion FOLL

Funcion AT: (eje attribute)

El eje de navegacion attribute::, se utiliza para direccionar en XPath a losatributos del nodo de contexto. Este eje es reescrito en XTendedPath comouna funcion currificada, donde el primer argumento es un string que almacenael nombre del atributo seleccionado. El segundo argumento de la funcion esuna secuencia de nodos contexto para los cuales se busca el atributo cuyonombre esta en el primer argumento. Como de cada nodo contexto solo sepuede sacar al menos un atributo con el nombre del valor del atributo igualal especificado como argumento, el resultado final es una secuencia de stringscon una longitud menor o igual a la del segundo argumento. La cabecera dela funcion es la siguiente:

AT: string → (node|node*) → string*

En la tabla 5.18 se detalla la semantica de la funcion AT. Se asume queb: node*.


AT(s)(b) $b/attribute::s {x | ∃ y ∈ b ∧ x ∈ attribute(s)(y)}

Cuadro 5.18: Semantica de la funcion AT

Funcion TEXT: (texto)

La funcion TEXT extrae el texto (sin etiquetas) de los nodos que recibepor argumento y los devuelve concatenados en el resultado. Para ello, se tieneen cuenta el texto de todos sus nodos descendientes, eliminando marcado, co-mentarios y atributos. Tengase en cuenta que el texto resultado aparecera enel mismo orden que en el documento solo si la secuencia de entrada esta enese mismo orden. Ası pues, la cabecera de la funcion 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. Funcion F: (predicados)

Los predicados en XPath se escriben como expresiones booleanas entrecorchetes a la derecha de cada paso o step que forma una expresion XPath.Los predicados sirven para establecer una condicion de filtro de forma quese seleccionan exclusivamente aquellos nodos contexto que superen una con-dicion, descartandose ası aquellos que nodos que no la cumplan. Por ejemplo,la siguiente expresion forma en XPath la secuencia de numeros pares entre 1y 10.

(1 to 10)[. mod 2 = 0]

Desde el punto de vista de XTendedPath, los predicados son funciones,tıpicamente anonimas (no tienen nombre, sino que se especifican in situ), quese aplican al nodo contexto para dictaminar si este cumple las condicionesde pertenecer o no a la secuencia resultado. Dicho de otra forma, se tratade expresiones lambda construidas para la ocasion por el programador que,tomando como argumento una secuencia de nodos contexto o de elementosde cualquier otro tipo, devuelve un valor booleano para cada uno de ellosque decide si el elemento forma parte del resultado o si por el contrariono forma parte del mismo. Si la aplicacion de la funcion recibida sobre unelemento contexto devuelve un valor booleano de cierto, el elemento pasa aformar parte del resultado del predicado. Si la aplicacion de la funcion sobreel elemento contexto devuelve un valor booleano de falso, el nodo contextono forma entonces parte del resultado. Los predicados se pueden aplicar alresultado devuelto por otros predicados aplicados previamente.

En XTendedPath los predicados se reescriben como una funcion currifi-cada, donde el primer argumento es la funcion de filtro que debe aplicarsecada vez sobre los distintos elementos individuales que forman parte de lasecuencia recibida como segundo argumento. El resultado final es el subcon-junto de elementos del segundo argumento que cumplen como caracterısticahaber recibido un valor de verdad de cierto cuando se les evaluo con la fun-cion recibida como primer argumento. La cabecera de esta funcion aparece acontinuacion.

F: (a → boolean) → a* → a*

Ahora bien, los predicados en XPath tambien tienen otra cabecera po-

152

sible, esto es, otra semantica bien distinta que tambien es considerada enXTendedPath. Cuando el primer argumento de la funcion F, en lugar de seruna funcion que devuelva cierto o falso para cada nodo de contexto, es unsimple valor numerico entero, el resultado de la funcion F debe ser el elementode la secuencia del segundo argumento que esta en la posicion indicada por elprimer argumento, empezando por el valor 1 y terminando por el valor de lalongitud del segundo argumento (valor last()). Dicha semantica de funcion secorresponde con la siguiente cabecera. Notese, que, en este caso, el tipo finalde resultado ya no es una secuencia, sino un unico elemento de la misma.

F: integer → a* → a

Finalmente, existe una tercera forma de reescribir los predicados de XPathen XTendedPath, que es mediante la aplicacion de una funcion que, al con-trario de la primera, en lugar de devolver un booleano para cada elementode 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 deentrada, pero no necesariamente. Si esa secuencia esta vacıa, se asimila queel elemento no debe formar parte del resultado, pero sı debe formar partede ese resultado en el caso en el que esa secuencia sı tenga algun elemento.Esta forma de expresion es usada habitualmente para seleccionar nodos deelementos que cumplen la propiedad de tener ciertos descendientes o ascen-dientes que a su vez puedan cumplir otras propiedades definidas con otrospredicados. La ventaja de poder componer predicados es que permite al pro-gramador definir funciones que deben aplicarse a elementos que aun no hansido 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 semantica de la funcion F en estas tresposibilidades. 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: Semantica de la funcion F

153

5.4.9. Elemento raız del documento

El elemento raız de un documento, que normalmente se representa enXPath como una barra inclinada (/), tambien tiene su correspondiente re-presentacion en XTendedPath. Ası pues, en XTendedPath se ha definido lafuncion ROOT la semantica 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 enel documento del que son extraıdos, sino que son computados a partir deun subconjunto de datos primarios (que sı residen en el documento y porlo tanto son directamente extraıbles sin computaciones). Al igual que enXPath, XTendedPath define las siguientes funciones de datos secundarios,cuya semantica 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

SUM: number* → number SUM(a) xf:sum($a)∑

a

COUNT: a* → number COUNT(a) xf:count($a) size(a)

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 union, interseccion y diferencia de con-juntos, conforme a la tabla 5.23. En las tres expresiones (union, interseccion

154

y diferencia) se eliminan los elementos que ya esten replicados, de forma queformen parte del resultado una unica vez. En XTendedPath, las operacionesse han definido como funciones currificables, en lugar de operadores infijoscomo 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 expresion XTendedPath (a continuacion figura la expresionXPath equivalente) calcula los elementos que deben procesarse para rellenarun 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 borradorde XPath y que incrementan sensiblemente la expresividad y capacidad dedireccionamiento y anadiendo nuevas funcionalidades. Estas extensiones sonrespetuosas 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 ambitos.

1. Por un lado, se han analizado las ventajas e inconvenientes de algunosde los operadores genuinos de XPointer, y se han seleccionado aque-llos que aportaban alguna funcionalidad util que no estuviera presenteen XPath. Gracias a esa seleccion, se han incorporado a XTendedPathdos nuevos tipos de datos no contemplados en XPath: los puntos ylos 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. Ademas, se han establecido

155

tambien algunas restricciones enfocadas, por una parte a mejorar larobustez de las reglas de extraccion que manejan esos nuevos tiposde datos, conservando la semantica definida de aquellos operadores deXPath que tienen correspondencia con primitivas de XTendedPath, ypor otra, asegurando que las operaciones definidas sobre los nuevos ti-pos de datos solo pueden dar resultados correctamente procesables yconformes a la buena formacion de XML. El apartado 5.5.1 contemplala descripcion de estas extensiones dentro del lenguaje XTendedPath.

2. En segundo lugar, para mejorar la capacidad de encapsulacion y reuti-lizacion del codigo de las expresiones XTendedPath, se les ha dotado aestas de una forma de definir funciones de usuario sin nombre, estoes, expresiones lambda conforme a las recomendaciones mencionadasen el apartado 5.2, a las que se las ha acompanado de una bibliotecaextensible de funciones de orden superior. Por supuesto, con elconstructor let es posible asociar nombres a esas expresiones lambdapara crear ası funciones con nombre. Estas funciones definibles por elusuario permiten que el usuario pueda reutilizar su propio codigo encap-sulandolo en funciones ubicadas en sus propias bibliotecas de usua-rio, algo que no es realizable en XPath. El apartado 5.5.2 contemplala descripcion de estas extensiones dentro del lenguaje XTendedPath.

3. En tercer lugar, se contemplan las extensiones para la modificacionde 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. Hayalgunas que, modelizando una idea simple, resultan muy utiles para pro-porcionar robustez. Otras, permiten mejorar con nuevos tipos de datos lagranularidad de los resultados accesibles, pero solo un subconjunto de esosnuevos tipos de datos resultan interesantes, pues hay algunos de ellos que nopueden participar en ciertas operaciones, razon por la cual su incorporaciona XTendedPath viene acompanada de un conjunto de restricciones.

Evaluacion alternativa

La evaluacion alternativa es un concepto muy sencillo que, apareciendoen la recomendacion de XPointer, no aparece sin embargo en la de XPath 2.0.El principio basico de la evaluacion alternativa consiste en permitir el acceso

156

a un dato, estableciendo, no una, sino varias expresiones de acceso alternati-vas. Mediante la utilizacion de varias expresiones de consulta alternativas, sialguna falla en su cometido, otra expresion 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 mismaexpresion alternativa, se representan concatenadas una a continuacion de laotra en una secuencia. El resultado sera la secuencia vacıa solo si todas lasexpresiones que forman la secuencia dan ese mismo resultado. La primeraexpresion por la izquierda que de un resultado distinto de la secuencia vacıaes considerada como satisfactoria, razon por la cual no se considera necesariala evaluacion de las expresiones que estan a la derecha de esta. A la hora deevitar posibles ambiguedades al incorporar esta expresion en XTendedPath,se ha elegido el uso de un operador binario denominado EVALALT, querecibe dos argumentos, tal y como figura su descripcion en la tabla 5.24. Laevaluacion de mas de dos expresiones alternativas se puede realizar combi-nando el operador con el uso de los parentesis.

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 evaluacion alternativa

Tipo punto

Los puntos (point) se definen como posiciones concretas dentro de losdocumentos XML. Un punto en XPointer representa la posicion interme-dia entre dos componentes del documento, dondequiera que cualquiera deesos componentes pueden ser caracteres de una zona de texto, entidades onodos (elementos) de un documento XML. Los puntos, al ser simples posi-ciones intermedias, no albergan por sı mismos ningun dato y, por lo tantono tienen, en principio, interes desde el punto de vista de la integracion dedatos semiestructurados (razon por la cual no forman seguramente parte della especificacion de XPath). Sin embargo, pueden ser utiles para definir loslugares en los que pueden aplicarse modificaciones puntuales a documentosXML o pueden servir como delimitadores de los rangos, esto es, de fragmen-tos de documentos que aparecen como una generalizacion del concepto denodo y que aparecen comentados mas adelante en este documento, tambiencomo extension 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 enXPointer la utilizacion de constructores basados en posiciones numericas queal ser posiblemente cambiantes en futuras versiones del documento, por lotanto, resultan ciertamente poco robustos como modelo para direccionarlos.Sin embargo, otros puntos sı pueden ser mas robustamente direccionables yno sufrir tanto las variaciones ante cambios producidos en los documentos.El mismo XPointer establece ası una clara distincion entre los node-points ylos character-points, los cuales merecen las siguientes consideraciones.

Los character-points no tienen vınculos con la estructura arborea deXML, sino con los fragmentos de texto alrededor de los cuales estandefinidos. En terminos generales, la estructura arborea de un documen-to XML suele mantenerse relativamente estable en el tiempo frente a lasmodificaciones que suelen afectar al resto del documento. Para mejorarla robustez ante las modificaciones que sufre el documento, se puedetomar como referencia algun contenido textual que, se pueda esperarque aparezca invariantemente en el documento. De esta forma, se defineun 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ı estan vincula-dos a la estructura arborescente del documento XML. En XPointer, aligual que ocurre con los character-point, los node-points aparecen de-finidos como una tupla formada por un contenedor de referencia y unnumero entero no negativo que indica la posicion relativa del punto en-tre los hijos directos de ese nodo. Esta forma de modelizacion permiteciertamente mucha flexibilidad a la hora de poder direccionar cualquierposible punto del documento, pues todo punto tiene asociada, graciasa esa formalizacion, al menos una expresion que lo define. No obstan-te, no todos los puntos tienen la misma robustez de direccionamiento.En general, resultan mas robustamente direccionables aquellos puntosque aparecen justamente adyacentes al principio o al final de etique-tas de apertura o de cierre de elementos que cambien poco dentro dela estructura arborea del documento. Estas consideraciones permitenredefinir la modelizacion de puntos, simplificando la definicion originalde XPointer como una tupla formada por un nodo cualquiera y un va-lor de entre cuatro posibles que indiquen los cuatro puntos tangentes alas etiquetas de inicio y fin de ese nodo, tal y como aparece definido acontinuacion.

158

node-point ≡ (node,{firstchild|lastchild|prevsibling|nextsibling})

Cualquier nodo con contenido no nulo define ası cuatro puntos vinculadosal mismo, que son los puntos adyacentes a sus etiquetas de apertura y decierre, y que aparecen reflejados en la tabla 5.25. Sin embargo, cuando elnodo esta formado por una etiqueta vacıa, el numero de puntos se reduce ados, pues la misma etiqueta sirve como etiqueta de apertura y de cierre delnodo. En el caso de que exista una etiqueta de apertura y otra de cierre, peroel contenido del nodo sea la cadena vacıa, el numero de puntos direccionableses en realidad de tres, puesto que los dos mas internos del mismo, es decir, losreferentes a firstchild y a lastchild hacen referencia en realidad a un mismopunto. De este modo, menos puntos resultan definibles que en XPointer,pero los que sı lo son resultan mas interesantes desde el punto de vista delprogramador y ademas son mas 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 union de los node-point y loscharacter-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 nocion de nodo. Los rangos son fragmentos que estancomprendidos entre dos puntos de un documento, tal y como se mencionaen la descripcion de XPointer en el apartado 4.3. Conforme a esa idea, debetenerse en cuenta que, en XPointer, se pueden definir rangos que empiecena mitad de un parrafo y terminen a la mitad del siguiente, no participando,por lo tanto, de la estructura arborea de XML. Ello, pese a que quizas puedaser interesante desde el punto de vista de una herramienta de visualizacion

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 arboreadel documento. Para que los rangos puedan ser insertados o borrados de undocumento XML sin alterar las reglas de construccion de arboles, se necesitaque esos rangos sigan el principio de buena formacion, tal y como esta ex-presado en la condicion de la figura 5.12. En ella se indica que todo rangodelimitado por un par de puntos p1 y p2 debe cumplir que, para cualquiernodo, el nodo debe estar contenido dentro del rango, o bien el rango debeestar contenido dentro del nodo, o bien el nodo figura o bien antes o biendespues del rango en el documento sin intersecarlo en ningun 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: Restriccion que debe cumplir todo rango en XTendedPath

Los rangos de XTendedPath son aquellos rangos de XPointer que cumplenla restriccion definida en la figura 5.12. De ello se deduce que los puntosdelimitadores del rango, tanto el de inicio como el del final, deben estardefinidos en un mismo contenedor del arbol, para que el rango pueda serinsertado o borrado manteniendo la estructura arborea del documento. Esdecir, un documento XML al que se le inserte o borre algun rango debeseguir siendo un documento XML bien formado. La validez respecto de unDTD o XML Schema no esta garantizada con el uso de estas operaciones.

Otra caracterıstica importante de los rangos definidos de esta forma esque son un superconjunto de los nodos, es decir, los nodos son subconjuntosde 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 arborea del documento XML, no forman parte de la misma, y por lotanto no son accesibles por los ejes de XPath. Ningun rango se puede conside-rar hijo o descendiente de ningun nodo de la misma forma en la que tampoconingun nodo o rango se puede considerar a su vez hijo o descendiente deningun rango dentro del cual este definido. Las relaciones de descencencia yparentesco no son aplicables a los rangos por el hecho de que ellos no formanparte de la estructura arborea. Debe tenerse en cuenta que en un arbol deun documento son multiples los posibles rangos que pueden ser definidos encualquier 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 comun) y que la construccion de un rango no in-volucra ninguna operacion especial aparte del hecho de anotar los puntos deinicio y de fin de dicho rango.

Patrones de texto

Los patrones de texto son un tipo especial de constructores de rangos.La delimitacion de los mismos no viene dada ya por la definicion explıcitade sus puntos de inicio y de fin, tal y como aparece en sus constructores,sino que tal delimitacion viene dada de una manera implıcita, especificandouna propiedad de coincidencia respecto a un patron de texto o plantilla. Elrango sera aquella parte del documento cuyo contenido de texto se ajuste aun patron especificado. Los patrones de texto vienen definidos en XPointermediante su constructor string-range() y permiten definir como rangos aque-llas porciones de documento en las que el texto embebido (el PCDATA) seaidentico al argumento del constructor. Es decir, el argumento string recibidopor este constructor como patron es buscado literalmente en el documentocomo un substring, sin la posibilidad de aplicar expresiones regulares queflexibilicen ese patron. Ası pues, el tipo de busquedas textuales en XPointerresultan 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 secumpla una concordancia entre el texto del documento y un patron de textousado para hacer busquedas o reconocimiento de textos basados en expre-siones regulares. No obstante, tras varios meses de deliberaciones desde elinicio de la etapa del nuevo borrador, desde su version del 16 de agosto de2002 se incluye un nuevo operador que pretende aplicar expresiones regula-res a los documentos, pero que aun deja algunos aspectos sin definir, comola sintaxis de esas expresiones. En cualquier caso, sin desatender un posiblecambio en la especificacion de XPath 2.0, para ir solventando el problema, seha incorporado a XTendedPath un constructor propio de rangos basado enpatrones de texto que utilizan expresiones regulares basadas en Perl5 [147].Futuras definiciones de la semantica del operador recientemente introducidoen XPath para manejar esta misma funcionalidad replantearan seguramen-te la existencia de este constructor en XTendedPath. Sin embargo, se le haincluido de momento con el fin de poder formular consultas basadas en co-rrespondencias con patrones de texto mientras tanto, intentando mantenersu interfaz lo mas simple posible. La cabecera de la funcion de patrones detexto, tal y como esta definida en XTendedPath, es la siguiente:

161

STRPAT: string → integer → (range|range*) → range*

Basicamente, la funcion STRPAT se define como una funcion currificadaque devuelve una secuencia de rangos en el documento en los que se cumpleque el texto de dichos rangos se ajusta a la expresion regular almacenadaen su primer argumento. El segundo argumento de la funcion es un nume-ro entero que indica cual es la parte de la expresion regular que debe serconsiderada a la hora de devolver los resultados. En Perl5, las expresiones re-gulares admiten la posibilidad de definir partes posteriormente recuperablesde forma aislada con ese numero. Cuando la expresion regular no fragmentaen zonas o subapartados la entrada, ese numero debe ser el valor numerico 0.Sin embargo, si la expresion regular recibida como primer argumento definevarias posibles zonas de subdivision, el valor numerico sirve para distinguircual de ellas es la que contiene el dato de interes. En ese caso, el numero indi-ca la posicion de esa zona de interes, empezando por el el 1 y siguiendo en elorden de aparicion en la expresion regular. Finalmente, el tercer argumentode la funcion recibe el conjunto de rangos del documento sobre el cual se vaa aplicar la expresion regular de busqueda. La tabla 5.26 contiene ejemplosde la aplicacion de esta funcion que, aplicada sobre una lista de rangos de undocumento, es capaz de devolver una lista de rangos de texto de un documen-to en los que se representen dıas, meses o anos, descritos en formato textual,encontrados en las fechas detectadas por la expresion regular entrecomillada.

Entrada Expresion 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 programacion y de acceso a determinadosdatos asequibles a partir de los documentos, se han incluido ademas, lassiguientes funciones adicionales que realizan labores auxiliares utiles para elprogramador:

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 funcion MARKUP devuelve como resultado un string conel marcado de un rango en el documento, incluyendo su texto y todassus 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 sucontenido interno como si fuera simple texto plano.

CONTENT La funcion CONTENT devuelve como resultado un string conel marcado de un rango en el documento, incluyendo su texto y las eti-quetas de marcado internas, pero sin incluir las etiquetas delimitadorasdel nodo, en el caso de que el rango sea tal. Dicho string puede usarsede forma similar al que devuelve la funcion MARKUP, con la salvedadde que ya se sabe que no incluye las etiquetas de inicio y de fin paralos nodos.

ISNODE La funcion ISNODE aplicada a un rango indica si dicho rangose corresponde con un nodo o no.

En la tabla 5.28 aparecen unos ejemplos de rangos direccionables en unsimple elemento de una pagina XHTML, de forma que se puede apreciar elsignificado resumido de los operadores anteriores. En esa misma tabla, semuestran algunos rangos de ‘‘<a>Hello Madam, bye</a>".

Operadores jerarquicos

Como consecuencia de la introduccion 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 ademas, unos operadores jerarquicosque figuran en esta seccion, para representar relaciones de contenido entrerangos de un documento. Los operadores jerarquicos suponen una generali-zacion de los ejes de navegacion de XPath, para cuando se manipulan rangosen 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

semantica concuerda con la de algun operador XTendedPath previamentedefinido de los que contemplaban los ejes de navegacion y que aparecen men-cionados en el apartado 5.4. Solo cuando alguno de sus operandos no sonnodos, sino rangos, se extiende el significado del eje para dotarle al operadorde un mayor grado de generalidad.

INSIDE: (range*, range*) → range*

El operador INSIDE recibe un par de secuencias de rangos y devuelvecomo resultado la secuencia formada por rangos del primer argumentoque cumplen la condicion de estar definidos dentro de algun rangocontenido en el segundo argumento. Cuando el primer y el segundoargumento estan formados exclusivamente por nodos, el operador IN-SIDE tiene la misma semantica que la funcion D de XTendedPath. Latabla 5.29 refleja la semantica de INSIDE, dependiendo de los tipos desus argumentos.

Condicion 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: Semantica de la expresion INSIDE(a,b)

La tabla 5.30 muestra dos ejemplos de uso de la funcion INSIDE pa-ra calcular una secuencia de rangos de texto formados por aquellas

164

palabras que esten en italica y en negrita a la vez (independientemen-te del orden de anidamiento de estas dos etiquetas) dentro del rangoalmacenado en la variable P.

Expresion

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 jerarquico 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 condicion de contener algun rango pertene-ciente al segundo argumento. Cuando el primer y el segundo argumentoestan formados exclusivamente por nodos, el operador CONTAIN tie-ne la misma semantica que la funcion A de XTendedPath. La tabla5.31 refleja la semantica de CONTAIN, dependiendo de los tipos desus argumentos.

Condicion 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: Semantica de la expresion CONTAIN(a,b)

Gracias a los operadores jerarquicos, la formula de la figura 5.12 puedereescribirse 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: Restriccion de rangos reescrita con operadores jerarquicos

165

5.5.2. Orden superior

Las extensiones de este apartado permiten usar XTendedPath como len-guaje de programacion funcional. Basicamente, ello se consigue definiendoconstructores de expresiones lambda y una biblioteca de rutinas de ordensuperior.

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 programacionfuncional que permite la definicion de expresiones que, aplicadas a unos argu-mentos, devuelven unos resultados. Las expresiones lambda se pueden usarcomo funciones anonimas a las que, opcionalmente, se les puede dar nombre,que es como normalmente se usan en los lenguajes de programacion conven-cionales. Las expresiones lambda forman sin duda una de las extensiones masimportantes de XTendedPath. Para ello, se puede usar el constructor FUNque figura a continuacion:

FUN: (a,b) → (a → b) / FUN(a,b) ≡ λa.b

Por ejemplo, FUN(x,2*x) define una funcion que devuelve el doble de suargumento.

Constructor LET: (definiciones locales)

El constructor LET permite definir localmente una variable con el valorde una expresion dentro de otra.

LET(variable,value,expr) ≡ (λvariable.expr)(value)

Por ejemplo, LET(doble,FUN(x,2*x),doble(3)) calcula el doble del nume-ro 3, asignando a la funcion que calcula el doble de su argumento el nombredoble, 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 expresioneslambda, algo que no esta contemplado en XPath, y de una forma sencilla.En el lenguaje XTendedPath las expresiones lambda son consideradas comoun 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 XTendedPathestan predefinidas las funciones de orden superior que aparecen en la tabla5.32. Dichas funciones se encuentran disponibles en la biblioteca del lengua-je. El usuario puede incluir facilmente mas funciones definiendo sus propiasbibliotecas si lo desea.

Expresion 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 Ultimo elemento

INIT(z) INIT: a* → a* z − LAST(z) (quitando el ultimo)

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 ∗ estan escritas con la sintaxis del lenguajede programacion funcional Haskell [113]. La gran mayorıa de esas funcionesson ya habitualmente conocidas en numerosos lenguajes de programacionfuncional. RED es la funcion reduce, tambien conocida como foldr. ACCes la funcion accumulate o foldl. O es la composicion de funciones, muy utilpara definir predicados. La funcion O sirve para componer funciones sencillasen otras mas complejas. El resultado es una nueva funcion que, cuando seaevaluada sobre su argumento, pasara como argumento de la primera funcionel resultado de evaluar la segunda funcion sobre el argumento recibido. Estasfunciones se encuentran definidas en XTendedPath en la figura 5.14.

Aunque existe la posibilidad de anadir un numero mucho mayor de fun-ciones de orden superior a XTendedPath, el conjunto anterior ofrece ya depor 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 expresionesXPath y sus correspondientes expresiones XTendedPath. En ellas se asumeque P0 es una variable que contiene una pagina o un rango de la misma yque 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 implementacion interna de estas funciones, la opcion emprendidaen este trabajo ha sido la de programarlas en el mismo lenguaje de programa-cion generado por el traductor de XTendedPath, usando para ello bibliotecasenlazables con ese codigo. Aunque otros lenguajes son posibles, dentro deeste trabajo, el traductor que se proporciona traduce las expresiones XTen-dedPath a lenguaje WebL [80], y es en bibliotecas de ese lenguaje en dondeestan predefinidas la mayorıa de las funciones de orden superior usables des-de XTendedPath. Si el traductor convirtiera las expresiones XTendedPath aotro lenguaje, como, por ejemplo, Java, para que los programas Java genera-dos pudieran ser compilados y enlazados en prototipos ejecutables, deberıausarse una biblioteca que implementara estas funciones en ese lenguaje.

Por ejemplo, si para reescribir una expresion lambda se deseara generarcodigo C, habrıa que programar una funcion con un nombre auxiliar y usar

169

su nombre, pues en C las funciones no son nunca anonimas, aunque sı se pue-den pasar por argumento. En el caso de que se deseara generar codigo Java,el hecho de que en ese lenguaje no existe la posibilidad de definir funcionesanonimas podrıa solventarse de otra forma. Por ejemplo, podrıa aprovechar-se la peculiaridad que permite definir objetos anonimos con metodos connombres conocidos. El codigo Java de la figura 5.15 permite la aplicacional numero 4, de una funcion que devuelve el doble de su argumento. Estafuncion no es una funcion anonima, pero sı un metodo con nombre conocido(exec) definido dentro de un objeto anonimo.

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 expresion lambda definida en Java

5.5.3. Modificacion de documentos

Para la modificacion de los documentos, XTendedPath tiene cuatro opera-dores basicos, dos de ellos para la manipulacion de atributos y otros dos parala manipulacion de la estructura arborea de nodos. En todos los casos, losoperadores tienen como efecto colateral la modificacion de la representacioninterna del documento.

En el caso de los atributos, el operador SETATTR permite modificarel valor de un atributo en un conjunto de nodos dentro de un documento.Por otro lado, el operador DELATTR permite eliminar un atributo de unconjunto de nodos.

En el caso de la modificacion de la estructura arborea, el operador IN-

170

SERTRANGE permite insertar un nuevo rango en un punto concreto deun documento. El operador DELETERANGES elimina del documento losrangos recibidos. La tabla 5.34 refleja un resumen de estos operadores.

Cabecera Significado

SETATTR: string → string → node* → page Modificacion del valor de atributos

DELATTR: string → node* → page Eliminacion de atributos

INSERTRANGE: point → range → page Inserta un rango en el documento

DELETERANGES: range* → page Eliminacion de rangos del documento

Cuadro 5.34: Operadores basicos de modificacion de documentos

La modificacion de atributos dentro de un documento puede ser muy utilpara rellenar formularios. Por ejemplo, sea campotexto una variable que con-tiene un campo de formulario de tipo texto cuyo valor se deba rellenar. Seabotonessi una secuencia de campos de formulario de tipo checkbox que de-ben ser marcados y botonesno los que no deben ser marcados. Sea opcionessilas opciones de una seleccion que deben ser seleccionadas y opcionesno lasopciones de una seleccion que no deben ser seleccionadas. La figura 5.16 con-tiene expresiones XTendedPath que rellenan adecuadamente esos campos deformulario, 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

Mascaras

En ocasiones interesa extraer datos de versiones modificadas de los do-cumentos. Es habitual que esas modificaciones consistan en la eliminacionde ciertas partes, consideradas como molestas para la extraccion de datos,de forma que, una vez eliminadas, la extraccion de datos resulta mucho massencilla. Una solucion que puede emplearse puede consistir en modificar eldocumento original eliminando esas partes y ası despues poder hacer ese

171

calculo o extraccion. Sin embargo, posteriores calculos pueden necesitar reci-bir el documento original sin modificaciones, es decir, sin los efectos lateralesde los operadores de modificacion de la tabla 5.34.

Una opcion clara para este tipo de operaciones puede ser entonces la demanipular solo una copia del documento, de forma que sobre ella se hacenlas modificaciones y los computos, manteniendo intacta una version originaldel documento. Haciendose copias temporales de esos documentos, el progra-mador podra manipularlas y modificarlas a su gusto, teniendo ası una visionlibremente modificable de un documento en la que poder hacer librementesus computos. Posteriormente, el documento modificado podra ser eliminado.Para realizar todas estas operaciones facilmente en una sola lınea sin que elprogramador tenga que estar dando nombres a las variables que almacenanesas copias del documento temporalmente modificadas para hacer computos,se ha ideado el operador de mascara.

El operador de mascara permite al usuario construir nuevas partes de undocumento donde, sin modificar el documento de entrada, se generan nuevosfragmentos de documento en los que se proporciona una vision en la quelos rangos recibidos en el primer argumento son invisibilizados en los ran-gos que son recibidos en el segundo argumento. Estas enmascaraciones serealizan eliminando esos fragmentos sobre las copias de los fragmentos delos documentos, no sobre el documento original. El resultado de la funcionde mascara es un conjunto de fragmentos de documento que son copia delos recibidos en el segundo argumento donde se han enmascarado los frag-mentos recibidos en el primer argumento, siendo el documento obtenido undocumento distinto del original. Esta operacion podrıa estar implementadainternamente con hojas de estilo XSLT que generaran un documento nuevoeliminando la parte que se desea enmascarar. Sin embargo, su implemen-tacion esta hecha internamente aprovechando los trozos de documento queresultan de la eliminacion de un nodo para construir directamente con ellosel nuevo documento en memoria y con estructura de arbol sin necesidad detener un motor XSLT.

MASK: range* → range* → range*

La tabla 5.35 define ejemplos de uso de la funcion de mascara.

Un ejemplo de la capacidad de expresion de XTendedPath comparadocon otras alternativas estandares como las que aparecen en las figuras 3.4 y3.6 es el que aparece en la figura 5.17.

172

Expresion Significado

MASK(STRPAT(“bomba”)(0)(P))(P) Eliminacion de las palabras “bomba” de P

TEXT(MASK(D(“i”)(P))(P)) Texto de P eliminando sus italicas

COUNT(STRPAT(“\w+”)(0)(MASK(D(“del”)(P))(P))) Numero de palabras de la actual version de P (ver [119])

MASK(F(AT(“onchange”))(D(“select”)(f)))(f) Formulario sin sus select de navegacion 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 funcion MASK

F(O(EQ(name))(O(TEXT)(C("addresse"))))(D("address")(source))

Figura 5.17: Expresion XPath equivalente asource//address[addressee[text() =name]]

173

Capıtulo 6

XPlore: Lenguaje para lanavegacion y procesamiento dedatos 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 tareasque manejan aplicaciones interactivas preexistentes, si bien los tipos de esasaplicaciones interactivas son bien distintos en cada trabajo. Mientras quecon expect, como aplicacion interactiva se contempla cualquier programa nografico controlable desde teclado y lanzable desde un interprete de coman-dos en sistemas operativos Unix, con el Web, como aplicacion interactiva secontempla cualquier aplicacion ubicada en algun servidor Web accesible pormedio de formularios embebidos en paginas tıpicamente HTML. Estas apli-caciones de servidor Web pueden ser consideradas como interpretes de cadauna de las peticiones que se les puede enviar a traves de esos formularios. Enel primero de los casos, expect esta encargado de sustituir al usuario que usael teclado para interactuar con la aplicacion. En el segundo, un programa denavegacion automatizada debe emular al usuario que usa un interfaz interac-tivo (el browser) para interactuar con una aplicacion que ejecuta alojada enun servidor Web. En ambos casos, el de la automatizacion de tareas gestio-nando programas con expect y el de la automatizacion de tareas gestionandoaplicaciones localizadas en el Web, se propone el uso de un lenguaje capaz derepresentar adecuadamente esos dialogos, especificando adecuadamen-te las pautas de navegacion que deben seguirse para llevar a cabo una tarea.En el caso del Web, el lenguaje propuesto para ese proposito es XPlore, cuya

175

descripcion se lleva a cabo en este capıtulo.

Analizando los lenguajes actualmente existentes para el desarrollo de apli-caciones capaces de navegar automaticamente en el Web, mencionados en elcapıtulo 3, ninguno de ellos resulta completamente adecuado para la automa-tizacion de aplicaciones Web. Muchas de las bibliotecas desarrolladas para sermanejadas por lenguajes de programacion habituales y algunas soluciones adhoc de la literatura para la automatizacion de la navegacion Web, permitenespecificar facilmente sencillas pautas de navegacion, basicamente visitandopaginas de direcciones conocidas de antemano. Muy pocas de ellas permitenla especificacion de caminos de navegacion complejos, donde se deben seguirvarios enlaces y en los que se debe hacer referencia con algun patron de ac-ceso a enlaces extraıdos de los documentos recientemente visitados. Todo lomas, suelen ofrecer sencillas llamadas a las primitivas GET y POST, perono proporcionan al usuario los mecanismos de extraccion de datos necesariospara parametrizar convenientemente esas primitivas en caminos de navega-cion compleja en los que es necesario establecer una sesion con los servidoresWeb accedidos. Por otro lado, las soluciones existentes no tienen un nivel deabstraccion lo suficientemente elevado capaz de abstraer en pocas lıneas decodigo operaciones comunes de la navegacion o el procesamiento, lo cual dalugar a grandes programas difıciles de mantener.

En muchos casos, no existe un conjunto adecuado de tipos de datos sobrelos que estructurar los datos obtenidos del Web u homogeneizarlos si pro-vienen de diversas fuentes, que es un paso primordial, segun se describe enel apartado 2.2.1. En la mayorıa de los casos, el procesamiento de los datosque se describe en el apartado 2.2.6 no se contempla como una labor propiade ninguna herramienta debido al particular funcionamiento de cada posi-ble tarea, requiriendo que el usuario programe esos procesamientos en rutinasdefinibles por el. Ello obliga a separar la estructura de estos programas en dis-tintas partes, una enfocada a la navegacion y otra al procesamiento delos datos obtenidos de esa navegacion. Ello es, sin duda, una opcion loable,pues permite mantener facilmente disociadas partes del programa que sondisjuntas para el programador. Sin embargo, para pequenos procesamientosmuy sencillos y muy habituales, esta separacion, tıpicamente realizada enficheros dispersos, resta mucha claridad a los programas, por lo que serıadeseable que algunos procesamientos sencillos fueran especificables desde elpropio lenguaje de navegacion. Por otro lado, muchas de las soluciones quesı presentan un alto nivel de abstraccion medianamente adecuado, proporcio-nan graves deficiencias que las impiden ser utilizadas en tareas que permitanel uso en cualquier aplicacion del Web. La automatizacion de estas tareas de-be poder estar facilmente representada en el nivel de abstraccion adecuado,

176

en un formato de representacion capacitado para especificar adecuadamentedialogos faciles de entender entre aplicaciones, capaz de representar a su veztareas complejas y ademas ir acompanada de una plataforma capaz de darsoporte a la ejecucion de esos programas.

Entre esas capacidades de abstraccion, se requiere poder representar facil-mente el dialogo formado por las peticiones y respuestas que se deben desa-rrollar con las aplicaciones de Web cuyo uso se desea automatizar, pero a lavez integrando ese dialogo con el manejo de otros recursos, como el manejodel sistema de ficheros e interaccion con el usuario, el uso de temporizado-res y gestion de hilos concurrentes para manejar varias comunicaciones enparalelo, ası como operaciones de control de flujo habituales en lenguajes deprogramacion imperativos (bucles, condiciones, variables, llamadas a funcio-nes, ...). Basicamente, se requiere la completa funcionalidad de un lenguajede programacion con las siguientes caracterısticas:

Capacidad de representacion de sesiones en el Web con alto nivel deabstraccion. Ello implica la capacidad de poder especificar facilmente elseguimiento de enlaces y envıo de formularios rellenos de forma sencilla.

Manejo de tipos de datos habituales de los lenguajes de programa-cion, para estructurar los datos de la forma mas adecuada y poderlosprocesar facilmente.

Buen soporte a la ejecucion sobre las paginas del Web legado.

Y, preferentemente, para distinguirlo aun mas si cabe de las alternativasexistentes en la literatura, basado en estandares reconocidos comoadecuados para facilitar su utilizacion.

Existen muchos estandares para realizar disenos y especificaciones conbuen nivel de abstraccion, pero practicamente ninguno de ellos ha sido usadoen el ambito de la automatizacion de tareas en el Web, al menos desde elpunto de vista de la creacion de clientes. Uno de los estandares mas adecua-dos para estas representaciones han sido los MSC, segun lo visto y justificadoen el apartado 4.1, por su facilidad para representar dialogos entre compo-nentes que se comunican entre sı intercambiando mensajes. Sin embargo,para el dominio del Web, no se conocen plataformas que den ejecucion a estetipo de representaciones de dialogos automatizadas. Por otro lado, ademasde representar dialogos, es necesario representar la extraccion de datos dedocumentos y para ello se ha escogido a XPath, por su clara orientacion aser el lenguaje de direccionamiento para documentos XML. Ambos lenguajes

177

ofrecen la ventaja de ser completamente complementarios el uno respecto delotro y de ofrecer conjuntamente una solucion apropiada de las necesidadesque se desean automatizar. De hecho, una primera aproximacion de ambastecnologıas fue usarlas de forma conjunta tal y como habıan sido cada unade ellas habıa sido concebida, embebiendo expresiones XPath en las accionesdefinibles dentro de los MSC. Sin embargo, algunas pequenas singularida-des de esa union ofrecıan algunas cuestiones que requerıan ciertas mejoras.Mejoras que ademas podıan simplificar notablemente el nivel de abstraccionteniendo en cuenta el uso que se pretendıa dar a esta solucion, que es laautomatizacion de tareas en el Web. Por esa razon nacio XPlore.

XPlore es un lenguaje de programacion de alto nivel de abstraccion para lacreacion de programas de navegacion automatica (asistentes de navegacion,programas envoltorio, ...), es decir, de algoritmos de navegacion, que sirveademas como anfitrion a XTendedPath, una extension del lenguaje XPathque aparece detallada en el apartado 5.3. XPlore es concebido como unaadaptacion restringida con reglas de la representacion textual de losMSC enfocada al contexto de la programacion de aplicaciones de navegacionautomatizada, donde, por otro lado. XPlore hereda, por tanto, sus princi-pales caracterısticas de la representacion textual de los MSC, utilizando elsubconjunto de elementos mas representativos de este formalismo. XPlore esun lenguaje imperativo que permite construcciones tıpicas de los lenguajesde esa naturaleza, como secuencializacion de sentencias, bucles, sentenciascondicionales, uso de variables y funciones. Ademas, al tener incorporadoXTendedPath como un subconjunto del lenguaje, tambien ofrece los cons-tructores de programacion funcional que ya incluye XTendedPath, por loque pueden usarse expresiones lambda para la definicion de funciones, ası co-mo la posibilidad de usar y/o definir funciones de orden superior, tanto porparte del usuario como las contenidas en una biblioteca que se le proporcio-na. A su vez, XPlore puede ser traducido a un lenguaje de programacion quesera posteriormente compilado o ejecutado.

XPlore surge como una particularizacion de la representacion textual delos MSC dentro del campo de la creacion de aplicaciones de navegacion au-tomatica. Sin embargo, los MSC en sı mismos constituyen una representa-cion muy generica, aplicable a muy diversos entornos. Es por ello que cuandose usan en un entorno como el Web en el que son conocidas una serie derestricciones o condicionantes, estos deben tambien tener cabida en la repre-sentacion. En este nuevo lenguaje se han introducido algunos requisitos a losMSC. Todo MSC que cumpla estos requisitos es un programa XPlore, mien-tras que todo programa XPlore es, a su vez, un MSC. Principalmente se harespetado la sintaxis inicial, pero se le han anadido una serie de restricciones

178

semanticas, con el objetivo de evitar que determinadas construcciones, sien-do sintacticamente correctas desde el punto de vista de los MSC, pueden sersemanticamente inadmisibles, esto es, erroneas, desde el punto de vista de unalgoritmo de navegacion Web. De esta manera, se reducen aspectos como laambiguedad o la posibilidad de especificar sistemas incoherentes, imposibles,no deseados o no traducibles a lenguajes de programacion, sin que la perdidade flexibilidad provocada por esas restricciones afecte a la esencia principaldel lenguaje de expresion de algoritmos ni tampoco a la expresividad del mis-mo. Dicho de otra forma, el propio comportamiento del Web, algo distinto delde la comunicacion de senales en componentes de telecomunicaciones de bajonivel (que es el ambito para el cual los MSC fueron inicialmente aplicados),obliga a que algunas construcciones de los MSC se vean indisolublementeunidas las unas a las otras (por ejemplo, que toda peticion en el lado delcliente sea seguida temporalmente por su correspondiente respuesta). Elloprovoca que existan construcciones de una granularidad un poco mayor ala que permiten de por sı los constructores de los MSC. De esta forma seconsigue ademas compactar aun mas los programas de navegacion, lo cual esdeseable conforme a los objetivos planteados por esta tesis.

Ası pues, desde un punto de vista tecnico, existen dos notaciones del len-guaje XPlore. Por un lado, la notacion MSC es una representacion textualbasada 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 notacion, debe tenerse el cuidado de seguir una serie de restriccionesde escritura para evitar la especificacion de sistemas absurdos o no desea-bles. Por otro lado, existe una notacion compacta que es en la que estanbasados algunos de los operadores de este capıtulo y que es la que se traducea lenguaje de programacion para generar los prototipos ejecutables. Ambasnotaciones son semanticamente equivalentes y sus diferencias son meramentesintacticas y estan 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 esperableque en un proximo futuro programas escritos en una notacion MSC puedenser automaticamente traducibles a una notacion compacta, por lo que nosera necesario el manejo de la notacion compacta.

Al contrario de lo que ocurre con la mayorıa de los lenguajes disenadosen los trabajos relacionados, XPlore no dispone de una plataforma que lede directamente soporte de ejecucion, es decir, no es directamente interpre-table por ninguna aplicacion. Esto es, no existe ningun programa capaz deanalizar un algoritmo de navegacion escrito en XPlore y ejecutar una a unasus 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 interprete. En su lugar, XPlore viene acompanado por untraductor que transforma los programas escritos en XPlore (notacion com-pacta) en programas de lenguajes de programacion preexistentes. Esta laborresulta mucho mas sencilla que la de la interpretacion y no resta funcionalidada los programas escritos en XPlore.

La utilizacion de MSC para modelar el comportamiento de aplicacionesen el Web no es novedosa de este trabajo. Los MSC han estado vinculadosa SDL [75], y por lo tanto su ambito de uso ha estado bastante restringidoal desarrollo de sistemas mediante la utilizacion de metodos formales, tıpi-camente en el desarrollo de software para sistemas de control en equipos detelecomunicaciones. Existen precedentes del uso de MSC para el modelado yespecificacion de aplicaciones orientadas al Web [27]. No obstante, se trata deaplicaciones centradas en el modelado de aplicaciones Web desde el punto devista de los servidores Web. En este caso, uno de los componentes del sistemaes el servidor Web cuyo comportamiento se desea especificar, mientras que elresto de los componentes del sistema son clientes Web que interactuan conel servidor, principalmente porque la aplicacion ası modelada esta orientadaa la comunicacion y colaboracion de varios usuarios mediante el uso de unportal con el fin de conseguir en la colaboracion de todos un objetivo comun.En la comunicacion entre los componentes, los mensajes intercambiados porla aplicacion y los clientes estan llevados a cabo mediante el envıo de correoselectronicos y el acceso de paginas Web y rellenado de formularios.

Son varios los motivos por los que se ha seleccionado el formalismo delos MSC para este trabajo. Mas alla de su simplicidad, de su comprensibili-dad por personas sin conocimientos tecnicos especiales, de disponer de unasemantica formal, o de una representacion textual, o de sus posibilidades paraser transformados en distintos formalismos de especificacion o de implemen-tacion, lo cierto es que los MSC resultan ser una tecnologıa muy adecuadapara representar las comunicaciones en el Web [44], tanto desde el punto devista de especificacion y desarrollo de aplicaciones para los servidores comopara las de los clientes, tal y como aparece documentado en el apartado 4.1.

A continuacion se describen los componentes del lenguaje XPlore.

180

6.1. Componentes de XPlore orientados a la

navegacion

6.1.1. Transacciones HTTP

Las transacciones del protocolo HTTP se pueden modelizar facilmente enun MSC. Basta representar un mensaje de peticion HTTP desde el clientehasta el servidor y otro de respuesta del servidor al cliente. Desde el punto devista del servidor, entre la recepcion de la peticion y el envıo de la respuestadel servidor al cliente deben ejecutarse todas aquellas acciones necesariaspara procesar la peticion con el fin de devolver la pagina de respuesta. Ellopuede conllevar la ejecucion de programas externos como CGI [89] o servlets[69] o puede ser tan simple como devolver el contenido de un fichero existenteen el sistema de ficheros del servidor.

Sin embargo, desde el punto de vista del cliente, una transaccion HTTP escontemplada como una peticion de respuesta sıncrona, por lo que la ejecuciondel cliente debe quedar paralizada hasta que se reciba la correspondienterespuesta del servidor. El tiempo desde que se tramita una peticion HTTPhasta que se recibe su respuesta es bastante significativo y depende de muchosfactores externos (velocidad y calidad de conexion, sobrecarga en el servidor,...), razon por la cual el hilo debe quedar entretanto bloqueado. Un cliente quedesee aprovechar ese tiempo para efectuar otras acciones, debe optar por lautilizacion de varios hilos de ejecucion, de manera que puedan ser ejecutadosmientras el hilo que lanzo su peticion esta esperando su respuesta. Para ellopuede usarse el operador de concurrencia mencionado en el apartado 6.2.9,creando ası hilos de ejecucion capaz de realizar concurrentemente mientraslos hilos ocupados en realizar transacciones HTTP estan bloqueados.

Para modelizar una transaccion HTTP desde el punto de vista del cliente,el lenguaje XPlore define las operaciones GET, HEAD y POST, cada unade ellas asociable a los comandos HTTP del mismo nombre. Estos coman-dos suelen encontrarse habitualmente implementados en bibliotecas propias[112, 147] de lenguajes de programacion como Java o Perl. Sin embargo, nosuelen controlar ciertos aspectos avanzados de las cabeceras HTTP, comolas cookies y las cabeceras de identificacion HTTP, restringiendose mınima-mente al control de las cabeceras cuya presencia es siempre obligatoria ycon un valor por defecto difıcilmente configurable. Por el contrario, cualquiercabecera HTTP, tanto las definidas actualmente, como cualquier otra nuevacabecera que pueda requerirse en un futuro, gracias a las cuales suele definir-se el concepto de sesion en los servidores Web, sı estan controladas por estas

181

primitivas en el lenguaje XPlore, pues estan implementadas internamente enla biblioteca de soporte del lenguaje. Otras muchas acciones implıcitas men-cionadas en el apartado 2.1 son tambien igualmente consideradas en estasbibliotecas de soporte.

El comando GET recibe como primer argumento la URL de la pagina quedebe traerse. El comando POST recibe como primer argumento el formulariorellenado que debe enviarse. Ambos comandos pueden opcionalmente recibirun segundo argumento que ayude a configurar las opciones de bajo nivelmencionadas en el parrafo anterior, y devuelven como resultado la paginaque 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 transaccion POST en XPlore y sus corres-pondientes representaciones equivalentes grafica y textual en notacion MSC.El comando GET es similar. Como puede verse, la notacion XPlore compacta(formada por la expresion respuesta = POST(form);) es mas simple y menossujeta a posibles errores de escritura que la correspondiente notacion textualdel MSC.

Figura 6.1: Representacion de transaccion HTTP

6.1.2. Combinadores de servicios

El acceso a los datos en el Web es mas propenso a fallos que el acceso adatos en la memoria local de un ordenador. Cualquier sobrecarga en los ser-vidores o cualquier perdida de conectividad puede facilmente impedir que lastransacciones HTTP funcionen adecuadamente como debieran, evitando quelas invocaciones de las llamadas GET y POST devuelvan la pagina deseada.

182

Para evitar estos fallos de ejecucion y ası conseguir que las aplicaciones queautomatizan tareas en el Web sean lo mas robustas posible, es convenien-te usar mecanismos que detecten cuando una transaccion HTTP falla porperdida de conectividad de forma que se puedan tomar las medidas oportu-nas, como por ejemplo, programar reintentos, acceder a una URL alternativacapaz de acceder a las paginas deseadas por otra ruta, o limitar en el tiempola ejecucion de la transaccion con un temporizador para parar aquellas tran-sacciones que estan tardando demasiado en ser respondidas. Luca Cardelli,propone en [40] el uso de unos operadores denominados Service Combinatorscon el fin de, facilmente, con unos pocos y simples constructores facilmentecombinables entre sı, solucionar estos problemas de una forma elegante parael programador. A continuacion se detallan los Combinadores de servicioscontemplados en XPlore.

Ejecucion temporizada: TIMEOUT(t,exp)

Si la expresion exp tarda en evaluarse menos de t milisegundos, todo haido correcto y ese es el resultado que se devuelve. Si se cumple ese plazo sinque la evaluacion de la expresion haya podido ser completada, se suspendela evaluacion y se produce una excepcion. En la figura 6.2, se almacena enla variable P1 la pagina de la portada del buscador Google [9], estableciendoun tiempo maximo de 100000 milisegundos para ello. En el caso en el que setarde mas de ese tiempo, se produce una excepcion.

P1 = TIMEOUT(100000,GET("http://www.google.com", nil));

Figura 6.2: Ejemplo de ejecucion temporizada

Ejecucion reiterada: RETRY(exp)

Se evalua la expresion exp tantas veces como sea necesario hasta que noproduzca ninguna excepcion. La figura 6.3 muestra el reintento continuado depeticiones a la pagina principal de Google, con un lımite para cada peticionde 100 segundos. Si se sobrepasa ese lımite, se reintenta (indefinidamente)una nueva peticion. Cuando se consigue esa pagina, se guarda en la variableP1.

183

P1 = RETRY(TIMEOUT(100000,GET("http://www.google.com", nil)));

Figura 6.3: Ejemplo de ejecucion reiterada

Ejecucion secuencial: SEQ(a,b)

Primeramente, se evalua la expresion a. Si no produce excepcion y de-vuelve un resultado correcto, ese debe ser el resultado de la expresion. Siproduce excepcion, se abandona su evaluacion y se evalua la expresion b. Elresultado de la ejecucion secuencial sera de excepcion, solo si ambas expre-siones producen excepcion. En caso contrario, el resultado es el de la primeraexpresion que no produzca excepcion. La figura 6.4 muestra el intento deguardar en P1 la pagina principal de Hotmail [13]. En el caso en el que esapeticion no se consiga llevar a cabo, se intentara con la de Yahoo! [22]. Solosi ambas paginas fallan, se devuelve como excepcion la de la ultima de lasexpresiones.

P1 = SEQ(GET("http://www.hotmail.com", nil), GET("http://www.yahoo.com", nil));

Figura 6.4: Ejemplo de ejecucion secuencial

Ejecucion concurrente: PAR(a,b)

Primeramente, se evaluan las expresiones a y b concurrentemente. Cuan-do la primera de ellas en terminar acaba satisfactoriamente, se suspende laevaluacion de la otra expresion y se retorna el resultado calculado por laexpresion que sı termino. Cuando la primera de ellas en terminar acaba in-satisfactoriamente, el resultado es delegado al de la otra expresion que siguesu curso. Si ambas terminan insatisfactoriamente, trasciende la excepcion dela segunda expresion en terminar. El resultado de la ejecucion concurrentesera de excepcion solo si ambas expresiones producen excepcion. En caso con-trario, el resultado es el de la primera expresion que termine correctamentey que no produzca excepcion. La figura 6.5 muestra el intento de guardar enP1 la primera pagina principal que consiga completar su descarga de los ser-vidores de Hotmail y del de Yahoo! Solo si ambas paginas fallan, se devuelvecomo excepcion la de la ultima de las expresiones.

A modo de ejemplo, la expresion 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 ejecucion 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 combinacion de servicios

6.2. Componentes de XPlore orientados al

procesamiento

6.2.1. Procesos

Un proceso es una entidad en ejecucion automatizada que interactua conotras entidades, locales o remotas por intercambio de peticiones y respuestas,tıpicamente transacciones HTTP. Las entidades que intervienen en una tareaWeb (servidores, portales agregadores, usuarios con un browser, ...) se corres-ponden con las instancias de los MSC mencionadas en el apartado 4.1.1. Sinembargo, desde el punto de vista orientado a la automatizacion de XPlore,se consideran procesos XPlore solo a aquellos que deben tener un comporta-miento automatizado y aun no lo estan. Ni los usuarios, ni las instancias yaautomatizadas son procesos desde el punto de vista del lenguaje XPlore. Unservidor Web o un usuario que sea irreemplazable detras de un browser, pesea que tambien pueden ser representados en un MSC por entidades, no sonconsiderados por XPlore mas que entidades externas con las que el procesoXPlore 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 ejecucion. Esto tıpicamentese traduce en que los procesos pueden ser programas completos o hilos deejecucion (threads) de un mismo proceso. Normalmente, un programa XPlo-re se traduce en un proceso pesado que puede a su vez lanzar varios hilos deejecucion.

185

6.2.2. Sentencias de control de flujo

Como cualquier lenguaje de programacion imperativa, XPlore contemplala definicion de sentencias condicionales y de bucles. Para ello, XPlore defineuna construccion IF-THEN-ELSIF-ELSE-END para sentencias condicionales(donde las ramas alternativas a la primera condicion, es decir los ELSIF yel 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, elbucle WHILE-DO-END (que termina cuando se deja de cumplir una condi-cion de guarda) y el bucle FOREACH-IN-DO-END (que sirve para recorrerlos 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 estan a su vezbasadas en las expresiones inline de los MSC (ver tabla 4.1). Al igual que esetipo de expresiones, estas sentencias de programacion estructurada puedenanidarse entre sı. Como puede apreciarse en la figura 6.7, la representacionen la notacion compacta de XPlore tiene algunas diferencias respecto de larepresentacion MSC de XPlore. Destaca el uso de palabras clave especıfi-cas similares a las de un lenguaje de programacion imperativo convencional(ELSE, ELSIF, IN, DO ...), en lugar de usar como separadores de las partes deestas sentencias la opcion definida en la gramatica textual de los MSC, con-sistente en el nombre del tipo de expresion inline seguida de punto y coma.De esta forma, los programas escritos en XPlore compacto quedan menosverbosos y con menos propension a albergar fallos.

En la figura 6.8 puede verse el codigo XPlore en notacion compacta delque aparece en notacion MSC en la figura 6.7.

Entre las sentencias condicionales y de bucle definidas en el lenguajeXPlore 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 solo existe una sentencia inline (llamada loop) para cualquier tipode bucle, deba este ser terminado por una condicion booleana (tipo WHILE)o por el recorrido de los elementos de una secuencia (tipo FOREACH). Lasentencia inline opt es completamente redefinible como una sentencia alt en

186

Figura 6.7: Representacion de un bucle y una sentencia condicional anidadosen XPlore notacion 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 notacion compacta de XPlore

187

la que no existen ramas alternativas a la primera condicion. La sentenciainline par esta contemplada en XPlore por el operador de concurrencia delapartado 6.2.9. En cuanto a la sentencia inline de tratamiento de excepcionesexc puede ser tratada con los combinadores de servicios del apartado 6.1.2.

Expresion 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: Relacion de expresiones inline con sentencias de control de flujo

6.2.3. Entrada/salida

Con XPlore se tiene acceso a las primitivas mas habituales para leer oescribir, tanto de fichero, como de teclado y pantalla. En la tabla 6.2 semuestran algunas de esas primitivas.

Primitiva Accion

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 ejecucion

XPlore define dos primitivas para cambiar el estado de ejecucion del hiloactual desde en ejecucion a suspendido. La descripcion de ambas aparece enla tabla 6.3.

Primitiva Accion

SLEEP(n) Suspender la ejecucion n milisegundos

STALL() Suspender la ejecucion indefinidamente

Cuadro 6.3: Primitivas de cambio de estado de ejecucion

6.2.5. Errores en la ejecucion

XPlore define dos primitivas para interrumpir la ejecucion del programa,tal y como puede apreciarse en la tabla 6.4. STOP interrumpe la ejecucionde forma incondicionada, permitiendo que el proceso muera (con una lla-mada exit al sistema operativo). ASSERT puede usarse para interrumpir laejecucion si no se cumplen ciertos requisitos necesarios segun el programador.

Primitiva Accion

STOP(valor) Terminar la ejecucion del programa con un valor de retorno

ASSERT(expresion) Terminar la ejecucion del programa si la expresion es falsa

Cuadro 6.4: Primitivas de errores de ejecucion

6.2.6. Funciones

Al igual que en practicamente cualquier lenguaje de programacion, unconjunto de sentencias XPlore puede encapsularse en una funcion para poderser reutilizado posteriormente mediante llamadas a esa funcion. Medianteel uso de funciones, los programas escritos en lenguajes imperativos puedenmodularizarse y simplificar de manera notable su mantenimiento. En la figura6.9 las funciones A, B y C son ejecutadas por un unico proceso (el procesoCliente o el proceso Servidor, segun corresponda), mientras que Identif es

189

otra funcion igualmente, salvo por el hecho de que tiene una representacionsomeramente distinta ya que esta involucrada en la ejecucion de mas de unproceso (el Cliente y el Servidor).

Figura 6.9: Representacion de llamadas a funciones en XPlore notacion MSC

Desde el punto de vista de los MSC a ambos casos se les considera comouna descomposicion modular (ver apartado 4.1.9) que debe ser detalladaen otro MSC. Siguiendo la sintaxis que XTendedPath pone a disposicion deXPlore, la figura 6.10 contiene la definicion de la funcion Identif en XPlore.En ella se declara a Identif como una funcion que recibe dos argumentos (unaURL y una funcion de rellenado de formularios), de forma que esa funcionsirve luego para rellenar el formulario de busqueda para buscar la palabraJava, por ejemplo en Google.

Por su lado, el codigo XPlore en notacion compacta de la instancia Clientede 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 yque este 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 definicion de funcion Identif en XPlore notacioncompacta

A();

Identif();

B();

Figura 6.11: Ejemplo de llamada de funcion en XPlore

programa traducido, XPlore incorpora dos nuevos constructores que permitenla llamada a funciones de usuario que, pudiendo no estar escritas en XPlore,sin embargo sı pueden estar escritas en lenguaje Java. Gracias a la conversionautomatica entre tipos de datos Java y tipos de datos WebL, los metodosy constructores de las clases Java pueden ser llamados con total facilidad.Estas funciones aparecen detalladas a continuacion. Notese que devuelvenun nuevo tipo de datos, (un java object), lo cual es solo posible cuando ellenguaje 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 metodos de los objetos Java devueltos por los anterioresconstructores pueden ser invocados facilmente, de la misma forma en la quelo serıan en lenguaje Java. La figura 6.12 muestra un ejemplo. Notese quetoString() y getMonth() son metodos de la clase java.util.Date del lenguajeJava.

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 notacion 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 unica forma dereutilizar software que permite el lenguaje XPlore. Las aplicaciones escritasen XPlore pueden invocar a programas externos accesibles desde el interpretede comandos del sistema operativo, aprovechando ası al maximo los recursosdisponibles de su entorno de ejecucion. Para ello, XPlore define la primitivaCALL 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 almacenanlos resultados de la ejecucion que dicho comando ha volcado en su salidaestandar, almacenado en la forma de string.

Figura 6.13: Representacion de llamada a programa externo

6.2.9. Operador de concurrencia

Obtener varios hilos de ejecucion concurrente tambien es facil en XPlo-re. Dado que las transacciones HTTP o las llamadas a programas externos

192

pueden demorarse un tiempo significativo hasta que son completadas, puederesultar deseable para el programador simultanear esas esperas con la eje-cucion de otras tareas, para lo cual puede querer crear hilos de ejecucionconcurrentes. Para ello se ha definido un sencillo operador de concurrencia,que permite crear varios hilos de ejecucion con el fin de repartir entre ellos lacarga de un conjunto de subtareas. Cada hilo evoluciona concurrentementerespecto de los demas, de forma que el proceso que los creo queda esperan-do la terminacion de todos los hilos lanzados. El operador de concurrenciase 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 deejecucion y separadas por la palabra clave CONC. El constructor funcionade forma similar a un cobegin/coend tıpico de programacion concurrente.

BEGINCONCURRENT tarea1 CONC tarea2 CONC ... tarean

ENDCONCURRENT

BEGINCONCURRENT fun1() CONC fun2() ENDCONCURRENT

Para representar un operador de concurrencia en un MSC, se define, enel lado del programa que ejecuta ese operador, una corregion (ver apartado4.1), para indicar que el orden de los eventos que van a ejecutarse en esainstancia no es determinable a priori, sino que depende de la evolucion dela ejecucion de cada uno de los hilos creados. Una vez que el proceso padrecrea sus hijos, se queda bloqueado a la espera de que todos ellos terminensu correspondiente subtarea. Solo cuando el ultimo de estos hilos muere, elpadre se desbloquea de su estado de espera y continua su ejecucion, sabiendoque las tareas de los hijos lanzados han concluido. Dentro de la corregion, serepresentan los correspondientes comandos create para cada hilo, seguidospor el correspondiente numero de llamadas wait para esperar por la ter-minacion de cada uno de los hilos creados. Ninguna otra accion se permiteejecutar dentro de la corregion del programa principal que crea a los hilos.Cada hilo creado, puede, sin embargo, crear a su vez mas hilos de ejecucionmediante su propia corregion. En la figura 6.14 se representa un operador deconcurrencia con dos hilos de ejecucion que ejecutan las subtareas fun1() yfun2().

193

Figura 6.14: Representacion de operador de concurrencia

194

Capıtulo 7

Ejemplos desarrollados con loslenguajes propuestos

En este capıtulo se presentan tres ejemplos de aplicaciones desarrolladascon las tecnologıas presentadas en esta tesis. Los tres ejemplos plantean laresolucion de problemas comunes habitualmente planteados en el Web paralos que XTendedPath y XPlore consiguen una automatizacion completa deforma sencilla y compacta. Los ejemplos que se presentan en este capıtuloson variados e intentan hacer uso del acceso a servidores Web conocidospor mucha gente, presentandose con diversas representaciones en un ordencreciente de detalle.

El primero de ellos, accede a las paginas del Nasdaq [14] y extrae en for-mato XML las cotizaciones (con quince minutos de retraso respecto al tiemporeal) de unas acciones que cotizan en ese mercado. Con esas cotizaciones, elprograma calcula el valor de una cartera de acciones definida por el usuarioformada por esos tıtulos. Como ejemplo de programa de integracion de da-tos en el Web de varias fuentes heterogeneas, el mismo programa se conectaademas al Web del Banco Central Europeo [7] para extraer, de una paginaHTML, la cotizacion del dolar estadounidense (USD) respecto del Euro, ycalcula en euros el valor de la cartera de acciones denominadas en dolares.

El segundo de ellos, accede a las paginas de Aucland [1], un servidorde subastas online y se dedica a publicar el catalogo de una tienda, alma-cenado en un fichero de usuario, rellenando con cada uno de sus artıculosun complejo formulario de publicacion de nuevas subastas en el servidor. Elprograma comprueba, antes de seguir cada enlace, que el servidor respon-de adecuadamente con los mensajes esperados de bienvenida, indicacion desaldo y confirmacion de puesta en marcha de la subasta. Se trata de un pro-

195

grama muy util para publicar un catalogo de muchos artıculos. El programase encuentra totalmente adaptado a la estructura del formulario de envıo enHTML, especificando todos los aspectos necesarios para la publicacion de losartıculos, como precio, cantidad, foto, opciones de pago, formas de envıo ytodo aquello que el servidor solicite al usuario. Todas las paginas accedidasestan en formato HTML, y algunos comportamientos JavaScript han sidoimitados desde el programa.

El tercero de ellos, accede a las paginas del correo gratuito de Yahoo! [22]y extrae un listado de los mensajes que hay en la bandeja de entrada paraun determinado usuario que se identifique con un password. Dicho progra-ma, ademas, permite el borrado de aquellos mensajes que el usuario declarecomo spam, marcando en el formulario de correo de Yahoo! esos mensajesy pulsando despues en el correspondiente boton de borrado del formulario.El programa es capaz de seguir todos los enlaces necesarios para acceder alos contenidos que le interesan, incluyendo ademas las paginaciones de losresultados que Yahoo! muestra a sus usuarios. Tambien en este ejemplo seaccede a paginas HTML de un servidor Web legado y se han implementadoalgunos comportamientos JavaScript.

A continuacion se muestran en detalle estos programas:

7.1. Valoracion de una cartera de acciones del

Nasdaq en euros

El ındice Nasdaq [14] es el principal ındice bursatil de valores tecnologi-cos en todo el mundo. En el, inversores de todo el mundo compran y vendenacciones de empresas que forman parte de la cartera de muchos inverso-res particulares, empresas y fondos de inversion. Su servidor Web ofrece unservicio gratuito que indica la cotizacion en dolares USD de las empresasque componen el ındice con un retraso de unos quince minutos. El servi-cio esta disponible para ser accedido en formato HTML por browsers, perotambien es accesible en formato XML para cualquier programa en general.Un mismo documento XML devuelto por este servidor bajo peticion puedecontener las cotizaciones de varias acciones. La tabla 7.1 refleja una parte dela estructura logica 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

Ultimo (USD) 5.5 3.41 78.35

Variacion 0.18% 0.29% 2.03 %

Previo (USD) 5.49 3.4 76.79

Direccion 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-cion en euros de las principales divisas mundiales. Al igual que el servidordel Nasdaq, el Banco Central Europeo es capaz de proporcionar esos datosen multiples formatos (HTML, WML, PDF, CSV, ...) ası como en su propiolenguaje definido sobre XML. Para demostrar la capacidad de integracion dedatos heterogeneos, para este caso se ha escogido la representacion HTML.La figura 7.1 contiene una representacion de esa pagina tal y como la presentaun navegador.

Figura 7.1: Cambio de divisas del BCE

El problema que se plantea consiste en realizar un programa que auto-matice la valoracion 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 cotizacion indicada por el Banco Central Europeo. La cartera deacciones 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 SunMicrosystems [19] y 500 acciones de la companıa eBay [6]. El programa debeconectarse al servidor del Nasdaq y formular su peticion para obtener lascotizaciones de esas empresas en un unico documento XML, que tiene unaestructura similar a la de la tabla 7.1. Concurrentemente, debe obtenersedel Banco Central Europeo la cotizacion del dolar USD en euros, la cualviene 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 deellos la informacion necesaria. Del documento XML del Nasdaq se extraeranlas cotizaciones de las empresas, que vienen denominadas en dolares USD.Del documento del Banco Central Europeo, una pagina HTML con formatode tabla en el que cada celda expresa la cotizacion en euros de una divi-sa diferente, se extraera exclusivamente un numero (la cotizacion del dolarUSD). El programa finalmente calculara el valor de la cartera de accionesmultiplicando el precio de cada accion por el numero de acciones que formanla cartera y sumando los resultados de esos productos. Esa suma expresael valor de la cartera en dolares USD. Dividiendo ese valor por el factor deconversion a euros, se obtendra el resultado buscado. La figura 7.2 refleja elMSC que explica el algoritmo. Notese que las peticiones a los servidores Webse hace lanzando threads concurrentes para minimizar el tiempo de respuestadel programa, paralelizando las peticiones a los servidores accedidos.

Figura 7.2: MSC grafico del programa Nasdaq

En la figura 7.3 aparece el correspondiente programa XPlore en notacionMSC. Notese que ambas son equivalentes tal y como esta definido en elestandar [76] y que la conversion 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 notacion MSC

199

Finalmente, la figura 7.4 contiene el codigo XPlore en notacion compac-ta. En el se define una variable shares con la secuencia que indica el numerode acciones de cada tıtulo. Mas adelante, se utiliza el operador BEGIN-CONCURRENT ... ENDCONCURRENT para lanzar las peticiones a ambosservidores Web de forma concurrente. La pagina XML del Nasdaq es alma-cenada en P1 y la pagina HTML es almacenada en P2. De P1 se extraen lascuatro cotizaciones, obtenibles mediante la expresion XPath $P1//equity-node//last-sale-prices, que proporciona una secuencia de cuatro nodos deldocumento. De P2 se extrae la cotizacion del dolar USD en euros, obteniblecon la expresion XPath $P2//td[text() = “USD”]/following-sibling::td[2]. Elresultado consiste en calcular el producto escalar entre el numero de accio-nes shares y la cotizacion de cada accion (los valores de texto de quotes) ydividirlo todo por la cotizacion del dolar 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 notacion compacta

200

7.2. Publicacion de un catalogo de artıculos

en un Web de subastas

Numerosos sitios Web [1, 22, 6, 11, 18] se han dedicado en los ultimostiempos a ofrecer subastas online. En ellos es posible realizar multiples ac-ciones relacionadas con el comercio electronico entre usuarios. Entre esasacciones se encuentran las de pujar por artıculos, realizar votaciones entreusuarios o publicar artıculos para lanzar nuevas subastas. Aunque cada vezexiste un mayor numero de herramientas disponibles para publicar grandesconjuntos de artıculos, lo cierto es que suelen estar reservadas a un conjuntoprivilegiado de usuarios y suelen requerir determinadas configuraciones hard-ware y software que no siempre son disponibles, por lo que la manera quemuchos usuarios tienen para publicar artıculos es la de rellenar uno a unouna serie de formularios online en varios pasos.

El problema que se plantea es el de la automatizacion de la publicacionde un catalogo de artıculos en el servidor de subastas de Aucland [1]. Elprograma debera acceder al servidor Web de Aucland identificandose con unusuario y password previamente registrados en ese servidor, de forma quese rellenaran los formularios de publicacion con cada uno de los artıculosque aparecen en catalogo almacenado en un fichero de usuario. Ese catalogose encuentra en un fichero de usuario que contiene un artıculo por cadalınea y que esta estructurado por columnas separadas por el caracter depunto y coma ’;’. Las columnas del fichero se corresponden con varios de loscampos del formulario que debe ser rellenado. Para cada artıculo del catalogodebera rellenarse el formulario y deberan seguirse los enlaces necesarios, deforma que, uno tras otro, el catalogo completo sea finalmente publicado. Lafigura 7.5 refleja el MSC que explica el algoritmo.

En la figura 7.6 aparece el correspondiente programa XPlore en notacionMSC. Ambas son equivalentes y su conversion de uno a otro formato esautomatizable.

Finalmente, la figura 7.8 contiene el correspondiente codigo XPlore ennotacion compacta. En el puede verse como las variables P1, P2, P3, P4, P5y P6 se corresponden con cada una de las paginas que forman la secuenciade publicacion, siendo P1 la portada y P6 la pagina que confirma que lasubasta ha sido puesta en marcha. Para seguir los enlaces que llevan a lasiguiente pagina, se aplican expresiones XTendedPath (comentadas con sucorrespondiente expresion XPath equivalente) que extraen de la pagina actualla URL que indica donde esta la siguiente pagina. Los formularios son tambienextraıdos y rellenados con sus correspondientes expresiones XTendedPath.

201

Figura 7.5: MSC grafico 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 notacion MSC

203

El programa comienza almacenando en P1 la portada de Aucland y enP2 la pagina de identificacion de usuarios. Rellenado y enviado el correspon-diente formulario de identificacion, en P3 se almacena la pagina HTML quecontiene el panel de control del usuario una vez conectado. Siguiendo unospocos enlaces mas, se accede al formulario de publicacion de nuevas subas-tas, del que aparece una parte en la figura 7.7 tal y como se visualiza en unbrowser. Dicha pagina se almacena en P5 y es reutilizada de ahı en adelantepara publicar todos los artıculos del catalogo.

Figura 7.7: Campos del formulario de publicacion de Aucland

Obtenido P5 y su correspondiente formulario se procesa un bucle que leelınea a lınea el fichero del catalogo del usuario. Con los datos estructuradosen columnas de cada una de esas lıneas el programa rellena el formulario depublicacion, comprueba que el saldo de la cuenta es correcto, sigue el enlacepara confirmar que desea publicar la subasta y comprueba el mensaje de quela subasta ha sido publicada. Con el fin de mantener una polıtica respetuosade uso con el servidor y de no sobrecargarlo con peticiones, se estableceun periodo de tiempo de ocho segundos entre un artıculo y el siguiente. Elprograma se encuentra representado por las figuras 7.8, 7.9 y 7.10. La figura7.8 contiene el codigo de la funcion que obtiene el formulario de publicaciony la funcion para insertar una foto en el formulario. La figura 7.9 contienela funcion que se dedica a rellenar con expresiones XTendedPath todos ycada uno de los campos del formulario de publicacion y del que aparecerepresentada una parte en la figura 7.7. Finalmente, la figura 7.10 contieneel codigo 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 notacion 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 notacion 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 notacion compacta (3)

207

Se ha escogido Aucland para ilustrar este ejemplo por ser uno de losmas conocido dentro de aquellos que no cobran gastos por la publicacion deartıculos en sus Web. Para otros servidores como[6, 11, 18] se ha desarrolladoel mismo programa con lenguaje XPlore igualmente, siendo regularmenteprobados de forma satisfactoria en esos servidores durante un periodo devarios 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 recepcionde correo electronico accesible desde las paginas Web mediante un navegador.Gestionar pequenas cantidades de correo ocasionalmente con estos servidorespuede ser una tarea amigable para muchos usuarios. Sin embargo, cuando elvolumen de mensajes es considerable, gestionar este tipo de cuentas puede seruna tarea bastante laboriosa, especialmente si se manejan grandes volumenesde mensajes y se carece de filtros personalizables que eviten el spam.

El problema que se plantea es el de la obtencion de un listado de loscorreos nuevos almacenados en el servidor de correo electronico gratuito deYahoo! Espana [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 paralos usuarios que lo visualizan desde un browser como en la figura 7.11, sinode forma estructurada, de forma que pueda ser procesado por un programaintegrador de correo que quiera aglutinar en un mismo interfaz los correos deeste y otros servidores. Por otro lado, el programa tambien debe aprovecharel establecimiento de una sesion con el servidor de Yahoo! para borrar todosaquellos mensajes considerables por el usuario como spam. Si hay mensajesdetectados como spam por los criterios especificables por los usuarios, sedeben borrar todos los que coincidan con ese criterio, teniendo en cuentaque Yahoo! puede mostrar sus resultados de forma paginada. La figura 7.12refleja el MSC que explica el algoritmo.

La figura 7.13 refleja el MSC que explica la funcion de listado y borradode correos.

En la figuras 7.14 y 7.15 aparece la correspondiente representacion textualdel MSC representado en las figuras 7.12 y 7.13.

Finalmente, la figura 7.16 contiene el codigo XPlore que realiza la imple-mentacion final. En P1 se almacena la portada. En P2 se almacena la paginade identificacion, donde esta el formulario que debe rellenarse para accedera la cuenta de correo. El resultado del envıo, la pagina P3, ofrece distintasvariantes no controladas por el programador, por lo cual resulta muy utilel uso del operador de evaluacion alternativa EVALALT mencionado en elapartado 5.5.1. Ello es debido a que, en unas ocasiones, P3 es una paginabasada en frames, razon por la cual debe seguirse un enlace adicional hastallegar hasta la pagina de bienvenida. En otras ocasiones, P3 es una pagi-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 accedera la pagina de bienvenida. Yahoo! suele cambiar sin aviso detalles de estetipo, introduciendo modificaciones que, aunque son transparentes al usuario,modifican sustancialmente la forma en la que los programas deben accedera las siguientes paginas. Por esa razon, en lugar de una polıtica destinada air cambiando la forma de acceso a la siguiente pagina cada vez que Yahoo!decide hacer alguna modificacion, se ha optado por el uso de un combinadorde expresiones que prueba una alternativa u otra, dotando al programa deuna mayor robustez para el seguimiento de este enlace.

La pagina P5 que contiene la bandeja de entrada donde estan los nuevosmensajes, hace un uso intensivo de las tablas para representar sus resultados.De ella, los datos relevantes para la aplicacion son los que aparecen organiza-dos en la tabla mas interna (las mas externas son usadas para posicionar loselementos en la pantalla), y que ademas contiene alguna palabra clave, como

209

Figura 7.12: MSC grafico del programa YahooMail

210

Figura 7.13: MSC grafico 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 notacion 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 notacion MSC (2)

“Remitente”. De esa tabla, interesan todas sus filas menos la primera (usadapara las cabeceras explicativas de la tabla) y la ultima (usada para albergarlos botones que realizan acciones sobre los mensajes marcados). En el codigoque aparece en la figura 7.17, esas filas se almacenan mediante una expre-sion XTendedPath en la variable tr5. Seguidamente se imprime el contenidotextual de esas filas de la pagina y se comprueba si existe coincidencia entrelas columnas del Asunto del mensaje y el Remitente del mismo, para decidirsi esos mensajes se deben marcar como spam. En el caso en el que algunode esos mensajes haya sido detectado como spam, se procede a pulsar en elboton de borrado para eliminar los mensajes borrados con el correspondienteformulario y se sigue de la misma manera con las siguientes paginas.

7.4. Recomendaciones de desarrollo

De la experiencia derivada del desarrollo de aplicaciones de integracionde informacion 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 seleccionadolos 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 notacion 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 notacion compacta (2)

215

diferencias y similitudes de servicios que, siendo funcionalmente similares,son estructuralmente muy hererogeneos.

Mas 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 navegacion automatizada, sı sehan formulado una serie de consejos que pueden ayudar notablemente a estedesarrollo. Dichos consejos aparecen formulados a continuacion. Su enume-racion no implica que deban seguirse estrictamente en ese orden o que todossean necesarios, pero sı se exponen como una guıa para desarrolladores quenecesiten una base sobre la cual comenzar a crear este tipo de aplicaciones.

1. Identificar clientes y servidores con entidades en un MSC:Mediante la asimilacion de clientes y servidores Web del sistema conentidades de un MSC se obtiene una escenificacion estatica de los com-ponentes que forman parte del sistema a lo largo de su funcionamiento.Muchas veces, para la especificacion de un asistente de navegacion quesolo desea navegar en un unico servidor Web, el numero de entidadesdel sistema se reduce a dos: el servidor Web al que se desea acceder yun cliente automatizado o codigo envoltorio que se desea desarrollar.Este es, sin duda el caso mas sencillo, y del que los apartados 7.2 y7.3 son algunos ejemplos. No obstante, para aplicaciones de agregacionde datos semiestructurados de diversas fuentes, como el que apareceen el apartado 7.1, el numero de componentes puede ser significativa-mente mas elevado. Por ejemplo, un portal integrador de contenidos yservicios puede facilmente acceder a muchos servidores completamenteheterogeneos, cada uno de ellos correspondiendose 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 puedaestablecerse entre ellos un dialogo correcto. Teniendo en cuenta queel protocolo HTTP esta formado por peticiones a las que les corres-ponden respuestas unicas, no resulta especialmente dificultoso el poderrepresentar mediante los mensajes de un MSC esos intercambios entreclientes 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 continuacion, pueden empezar a describirse las acciones (recuadrosde los MSC) que se deben ejecutar en cada entidad. No es necesarioentrar en demasiados detalles si no se desea. Basta con dejar reflejadoque acciones de alto nivel se desea ejecutar en esos puntos. Las accionesque se realizan en una entidad preexistente que no se esta implementan-do pueden dejarse entre comentarios, pues su implementacion es ajenaa los objetivos de este desarrollo.

5. Simplificar la estructura descomponiendo en referencias aotros MSC:Cuando la estructura obtenida de los pasos anteriores da lugar construc-ciones con una elevada complejidad ciclomatica (numero de caminosposibles por las bifurcaciones de salto) o bien se desea poder reutilizarfragmentos de MSC en varios sitios con una simple referencia, se puedefragmentar el programa en varios MSC mas simples a los cuales hacerreferencia. Ello equivaldra a descomponer el programa en funciones oprocedimientos reutilizables.

6. Usar la creacion y destruccion de componentes para represen-tar la invocacion de programas envoltorio:El lanzamiento y creacion de hilos concurrentes que se encarguen deejecutar subtareas en paralelo puede ser el siguiente paso. Para ello,debera representarse en el MSC la creacion de una entidad por cadathread que se desea lanzar. De la misma forma, la recepcion de los datosde cada subtarea encargada a cada thread se especificara dentro de unacorregion, puesto que normalmente no es conocible a priori el orden dela obtencion de resultados de cada uno de los threads lanzados, queterminaran segun su ejecucion evolucione mas o menos deprisa que lade los demas threads.

7. Detallar el contenido de las acciones de los MSC:Una vez construido el esqueleto basico del programa conforme a lospasos anteriores, se puede empezar a detallar el contenido de las ac-ciones de un MSC. Estas acciones suelen consistir en almacenar o leerde algun repositorio unos datos, realizar unos calculos con ellos y al-macenarlos en un nuevo repositorio. Por ejemplo, puede leerse de unapagina Web un dato extraıdo con una expresion XTendedPath y alma-cenar el resultado de esa evaluacion en una variable o en algun fichero.Tambien puede modificarse la estructura de una pagina preexistente,

217

como por ejemplo, cuando se rellena un formulario. Tambien puedenusarse temporizadores, combinadores de servicio, primitivas que modifi-can el estado de ejecucion del programa, operaciones de entrada-salidao llamadas a procesos externos (ver capıtulo 6 para una descripciondetallada).

8. Detallar el contenido de las condiciones de los MSC:Conforme a las variables del programa y con su valor asignado por lasexpresiones de calculo realizadas en las acciones de los MSC, se puedendefinir las condiciones que evaluan cuando la ejecucion debe bifurcarsehacia una u otra parte del codigo 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 detraduccion y ejecucion. Por ejemplo, puede reforzarse la adaptabilidadante cambios con un uso intensivo de combinadores de servicio, refinarla distribucion del codigo en funciones de usuario para que sea reflejode un buen diseno, insertar codigo que haga comprobaciones sobre laspaginas visitadas o mostrar en algun lugar accesible para el usuario losresultados que se van consiguiendo a lo largo del proceso de navegacion.

10. Convertir el MSC grafico a MSC textual (lenguaje XPlore ennotacion MSC):Ello puede hacerse facilmente al ser ambas representaciones equivalen-tes segun lo definido en el estandar [76].

11. Convertir el programa XPlore en notacion MSC a lenguajeXPlore en notacion compacta:Ello tambien puede hacerse facilmente 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, solo basta invocarlo (trans-formandolo a lenguaje de programacion y generando el prototipo eje-cutable a partir de este) desde la plataforma de ejecucion y comprobarque devuelve los resultados esperados. Si no los devuelve, deben ana-lizarse los documentos visitados en detalle para averiguar la causa delfallo de esa extraccion de datos.

13. Repetir todos los pasos anteriores para construir prototiposincrementales:Construir un programa que navegue en la Web requiere poder analizar

218

cada uno de las paginas o documentos que van siendo obtenidos delos servidores. Lo habitual para escribir estos programas es empezarescribiendo un programa que acceda a la pagina principal del servicioal que sea acceder, de forma que los siguientes prototipos vayan incor-porando uno a uno, el seguimiento de cada uno de los enlaces que sedesea atravesar. De esta forma, se deberan desarrollar al menos tan-tos prototipos como enlaces se desee atravesar, pero ese numero no esdemasiado elevado si se tiene en cuenta que suele haber caminos porpaginas repetibles que suelen poder especificarse dentro de bucles uotros MSC externos reutilizables.

14. Revisar el funcionamiento de las aplicaciones y realizar unalabor de mantenimiento:Dado el amplısimo espectro de causas que pueden invalidar alguna ex-presion de extraccion de datos del codigo o, menos frecuentemente,cambios que afecten a la navegacion, es necesario realizar una labor demantenimiento de este tipo de programas y, en la medida de lo posible,reforzarlos en aquellos puntos mas vulnerables a esas modificacionescon expresiones que mejoren su robustez y adaptabilidad, usando com-binadores de servicios, sinonimos, y explorando variantes en generalque puedan preveerse en la medida de lo posible.

219

Capıtulo 8

Conclusiones y trabajos futuros

El presente capıtulo enumera una serie de conclusiones y unas lıneas detrabajo futuro.

8.1. Principales contribuciones

Las principales contribuciones de esta tesis son las siguientes.

Se ha realizado un analisis de las tareas en el Web para estructurarlassegun sus componentes elementales comunes, a los que se ha denomina-do acciones basicas. Dicho analisis, que aparece en el capıtulo 2 clasificalas acciones que forman parte de toda tarea en el Web en dos grandesgrupos: acciones basicas implıcitas y acciones basicas explıcitas. Paracada 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 navegacion automati-ca particularizada mencionados en el apartado 1.3, como la dificultadque implican al usuario que usa browsers en una navegacion manual.

Se ha realizado un estudio del estado del arte que analiza las principalescaracterısticas de las tecnologıas usadas hasta el momento en el ambitode la automatizacion del tratamiento de los datos obtenidos del Web.Dicho estudio, plasmado en el capıtulo 3, alberga tanto los lenguajesde programacion desarrollados a este proposito como los marcos con-ceptuales en donde se estan encuadrando las ultimas tendencias (WebSemantico), intentando reflejar para cada uno de ellos sus principalesaportaciones y limitaciones.

221

Se han seleccionando las tecnologıas mas adecuadas para mejorar lacalidad de los productos obtenibles, teniendo en cuenta el inherenteaspecto de cambio, semiestructuracion y propension a fallos de la Web yse han resumido sus funcionalidades en el capıtulo 4. Dichas tecnologıashan resultado ser un estandar de la ITU (los MSC), cuatro lenguajesdefinidos por el W3C (XPath, XPointer, XQuery y XSLT) y dos APIde programacion (SAX y DOM).

Se ha realizado una propuesta de creacion de programas de navegacionautomatizada a bajo coste que esta basada en un metodo formal, los de-nominados MSC (Message Sequence Charts [76]) estandarizados por laITU. Hasta el momento no se conoce aplicacion practica de este meto-do formal en la especificacion de programas de navegacion en el Web,mencionados en el apartado 1.3. En este trabajo, se demuestra que losMSC son un mecanismo adecuado para la especificacion de aplicacio-nes que realizan tareas en el Web y que modela adecuadamente tantoescenarios sencillos como complejos, especialmente aquellos en los quese deba interactuar con varios servidores o en el que las transaccionessean complejas o numerosas. Cada MSC puede facilmente especificarel comportamiento que un cliente puede realizar con un servidor Weba lo largo de una sesion o de un fragmento de la misma. Los MSC sonadecuadamente utiles para especificar las acciones que conforman se-siones o fragmentos de sesiones en el Web mediante una representaciontanto textual como grafica. Esta representacion es capaz de ofrecer asimple vista una vision general del algoritmo, pero permite a su vez laespecificacion de detalles tecnicos de bajo nivel. Los MSC son comple-mentados con otros estandares para realizar manipulaciones sobre losdocumentos.

Para la facil creacion de programas y la demostracion de aplicabilidaden entornos reales existentes en el Web legado, se ha disenado un len-guaje de programacion, denominado XPlore y descrito en el apartado6, basado en los MSC y susceptible de ser utilizado como formato de es-pecificacion de requisitos de aplicaciones de navegacion automatizada,tanto directamente, como con una posible herramienta CASE, comose sugiere en el apartado 8.3.1. De este lenguaje se proporcionan enel capıtulo 7 algunos ejemplos que demuestran como la realizacion dealgunas tareas en el Web puede ser especificada con programas don-de, con un conjunto simple y flexible de constructores del lenguaje, esposible la realizacion de tareas en servidores del Web legado.

Partiendo de una supuesta version de XPointer que estuviera basada

222

en XPath 2.0 (en lugar de en la version 1.0 actual), se ha disenadoun lenguaje XTendedPath para la consulta y manipulacion de docu-mentos semiestructurados basados en XML, que auna la funcionalidadde XPath 2.0 para el direccionamiento de datos en documentos, la fle-xibilidad de XPointer para extraer fragmentos no asociables a partespredefinidas de arboles, la capacidad de modificacion de XUpdate y laflexibilidad de DOM a un coste inferior a este. Entre otras extensio-nes, que aparecen descritas en el apartado 5.3, se permite ademas alusuario la posibilidad de reutilizar codigo mediante la definicion de suspropias funciones de usuario, algo que tampoco estaba presente entrelas posibilidades del actual borrador ni de XPath ni de XPointer.

Se ha proporcionado una plataforma de ejecucion para programas escri-tos en XPlore y XTendedPath de forma que los programas expresadosen esos lenguajes tengan durante su ejecucion el conveniente soporte delas acciones basicas implıcitas mencionadas en el apartado 2.1. Dichaplataforma esta formada por la combinacion de un programa compi-lador que traduce esos lenguajes a un lenguaje de programacion con-vencional de alto nivel y tambien un conjunto de funciones de soporteembebidas en bibliotecas, de forma que son convenientemente enlaza-das con los programas traducidos de las especificaciones en XPlore yXTendedPath para formar ası un programa ejecutable final.

8.2. Conclusiones

A continuacion se evalua el grado de consecucion de los objetivos delapartado 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 abstraccion se han concretado en el usocombinado de dos estandares que son MSC y XPath, en el lenguajede programacion XPlore y en la plataforma de traduccion de XPlorea lenguaje de programacion convencional (WebL). Asimismo, la formade utilizar estos mecanismos se ha expuesto en unas guıas que pue-den servir de consejo para desarrollar aplicaciones y que aparecen en elapartado 7.4.

2. La plataforma con buen soporte para las acciones implıcitas tambiense ha conseguido. Para ello se ha partido de la mejora de una existente

223

a la que se ha anadido soporte a varios detalles tecnicos importantescomo el correcto manejo de los formularios a un adecuado nivel deabstraccion, la incorporacion de un corrector externo de errores en laconstruccion de paginas y el control de protocolos seguros (HTTPS).

3. Las acciones sencillas son facilmente realizables sin necesidad de recu-rrir a soluciones costosas como la continua programacion de funcionesde usuario o la delegacion de todo tratamiento de los documentos ahojas XSLT, cuya capacidad de procesamiento es bastante limitada.

4. Las acciones mas complejas, sin embargo, sı son facilmente resolublespor el usuario en codigo definible por el de varias formas. Puede usartanto sus propias funciones de biblioteca programadas en XPlore, comorutinas programadas en una biblioteca de usuario en Java, como llamara programas externos.

5. Con los combinadores de servicio se proporciona al usuario mecanismosadecuados para reducir los costes de ejecucion fallida. El usuario eslibre de usarlos como mas le plazca. Tambien puede insertar codigopara comprobar que las paginas visitadas cumplen las condiciones quese espera de ellas.

6. El coste de mantenimiento queda convenientemente reducido por elhecho de que cada accion basica explıcita de las mencionadas en elapartado 2.2 queda reflejado en una unica lınea de codigo, lo cual im-plica que cualquier cambio que se desee realizar en el programa debidoa una modificacion de la estructura de paginas del servidor suele afec-tar la gran mayorıa de las veces a una unica lınea de codigo. Por otrolado, en el caso de producirse el error, el sistema proporciona un men-saje detallando la lınea de codigo que produjo el error e informacioncontextual acerca del momento en el que se produjo el fallo.

7. Los programas desarrollables con XPlore son aplicables al Web legadosiempre y cuando sus paginas HTML sean manipulables o corregiblespor herramientas especializadas como Tidy. Los principales problemaso restricciones de aplicabilidad del Web legado vienen dados por lanavegacion basada en JavaScript y por los elementos multimedia querestan accesibilidad a la pagina.

8. Finalmente, XPlore es una solucion aplicable al Web basado en XMLporque el mecanismo de extraccion de datos sobre el que se basa esXPath, razon por la cual la aplicacion al Web legado es simplemente

224

un caso particularizado de la aplicacion a documentos definibles con ellenguaje 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 ejecucion puede ser mejorada y ampliada con multiples mejorasrelacionadas con las acciones basicas implıcitas como las mencionadas en elapartado 2.1. La sintaxis del lenguaje XTendedPath sin duda es mejorable.Por otro lado, serıa deseable contrastar la utilizacion de XPlore en un mayornumero de aplicaciones de integracion. Sin embargo, en este apartado se des-tacaran solo dos lıneas de trabajo que se considera especialmente relevantes.Por un lado, la mejora de la amigabilidad de XPlore por personas que notengan especiales habilidades para la programacion. Por otro lado la mejorade la aplicabilidad de estos programas a un mayor numero de servidores delWeb legado.

8.3.1. Herramienta CASE

Si bien XPlore ha resultado en los ejemplos desarrollados hasta el mo-mento una aportacion a la simplificacion del desarrollo y reduccion del costede mantenimiento, sin perder flexibilidad ni expresividad para la extraccion,navegacion o manipulacion de datos obtenidos del Web, el hecho de que seaun lenguaje de programacion no deja de implicar que solo sea utilizable porprogramadores. Por esa razon, especialmente en las fases iniciales de desa-rrollo, hubiera sido muy de agradecer por las personas que lo han utilizadopara desarrollar trabajos con el [38, 103], ası como el autor de esta tesis enlos ejemplos que ha desarrollado por su cuenta [42, 44, 41, 43], la utilizacionde una herramienta CASE capaz de asistir al usuario en el desarrollo de estetipo de programas.

Una herramienta capaz de guiar al usuario en su definicion de algoritmosde navegacion, abstrayendole de los aspectos de bajo nivel para que se puedaconcentrar en la logica del problema que esta automatizando, podrıa supo-nerle sin duda una importante ayuda. Si bien la construccion de este tipo deherramientas no forma parte de los objetivos directos de este trabajo, unaherramienta CASE que ayude a la creacion facil de asistentes de navegaciony que utilice los mecanismos descritos en su apartado 8.1 y 7.4 no deberıaser difıcilmente realizable y sin embargo sı podrıa resultar muy util para

225

desarrollar programas en lenguaje XPlore.

8.3.2. Accesibilidad a sitios Web orientados a la visua-lizacion

El Web basado en documentos HTML bien construidos desde el pun-to de vista de la accesibilidad es bastante navegable, pese a la orientaciona la visualizacion de muchas de las etiquetas y atributos de ese lenguaje.Sin embargo, la utilizacion masiva de elementos multimedia como imagenes,animaciones Flash, applets, plugins y rutinas JavaScript, tal y como se men-cionaba en el apartado 1.4.3, puede dificultar muy seriamente la capacidadde operacion de los programas de navegacion automatizada. Ello debe ser,sin duda, un factor a tener en cuenta en los trabajos relacionados por estastecnologıas de automatizacion de tareas en el Web.

Desde el punto de vista de los servidores

Los desarrolladores de servidores pueden tener en mente objetivos muydiversos dependiendo de cual sea la polıtica de accesos que quieran establecer.

Si se desea favorecer el acceso al servidor Web por el mayor espectro deposibles clientes (browsers, robots, agentes, asistentes, ...), una de las mejoresopciones 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 solo unosdeterminados tipos de clientes (tıpicamente los usuarios con browsers) ten-gan acceso completo a los contenidos mientras que otro tipo de clientes denavegacion automatizada no sean capaces de navegar adecuadamente por elservidor, una de las mejores opciones suele ser optar por la opcion contraria,es decir, aplicar de forma contraria las recomendaciones de accesibilidad defi-nidas en [128, 137, 136], especialmente aquellas que contengan contenidos detipo multimedia, que, como se describe en [2], suelen dar un buen resultadocomo medida de filtro para seleccionar a los usuarios que acceden. Establecereste tipo de restricciones de acceso puede estar motivado normalmente porpolıticas relacionadas normalmente con aspectos economicos y sociales comola publicidad o los derechos de autor, o bien con aspectos tecnicos (evitar queun robot pueda sobrecargar un servidor) y, en cualquier caso, es un derechoque tienen los responsables de los contenidos que se publican en un servidorWeb y que debe ser respetado.

226

Desde el punto de vista de los clientes

Los desarrolladores de clientes deben tener en cuenta cuales son las polıti-cas de restricciones establecidas por los servidores Web y ser respetuosos conesos servidores, cumpliendo unas mınimas normas de cortesıa que eviten quesu interaccion con el servidor pueda ser usada con efectos perniciosos para elservidor o para otros usuarios.

Sin embargo, en muchas ocasiones, la falta de accesibilidad de un sitioWeb suele estar mas motivada por su despreocupacion por las recomenda-ciones de accesibilidad del W3C que por el temor a ser accedidos por robots.Los clientes enfocados a la automatizacion de tareas en estos servidores Webdeben enfrentarse a multiples problemas derivados de la falta de mecanismospara acceder adecuadamente a los datos involucrados en una tarea. Actual-mente, las principales restricciones de XPlore vienen dadas por dos problemasno 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 siguientesaspectos.

JavaScript Las animaciones JavaScript exigen la interpretacion de codigode programa vinculado a las paginas en la plataforma del cliente. Laplataforma de ejecucion que da soporte a XPlore no dispone de ninguninterprete de JavaScript, por lo que todas las acciones JavaScript rele-vantes para la navegacion deben ser emuladas con codigo XPlore pro-gramado ad hoc. Incorporar a la plataforma de ejecucion el motor deinterpretacion de JavaScript de un browser (como por ejemplo se pro-gramo en [31]), podrıa ser una solucion a este problema. )

Contenidos multimedia Los contenidos multimedia que pueden estar in-volucrados en la navegacion, como imagenes, applets, plugins o anima-ciones Flash no siempre vienen acompanados de descripciones textualesque ayuden a su entendimiento para una buena navegacion. Es posi-ble usar los atributos alt o title en muchas etiquetas HTML parabasar en esas descripciones la navegacion, pero si esas descripcionesfaltan, es muy probable que la herramienta que se pretende desarrollarno pueda ser completamente automatica y que requiera la intervencionmanual de un operador que reconozca visualmente el elemento multi-media y actue en consecuencia. Asimismo, otros formatos ajenos a losestandares del W3C, como los formatos PDF, PS, DOC, RTF, ... sondifıcilmente analizables si no se dispone de una biblioteca que permitaacceder a la estructura de esos documentos de forma adecuada. XPloreno tiene incorporada ninguna biblioteca de acceso a estos formatos pro-

227

pietarios ni tampoco puede seleccionar enlaces que no esten descritospor una descripcion textual, con lo que los enlaces basados en imagenessuelen acabar presentando algunos problemas que deben ser resueltosde formas poco ortodoxas y que confieren puntos de poca estabilidad enel codigo fuente. Cualquier iniciativa que permita mejorar estos aspec-tos permitiendo un reconocimiento visual automatizado del elementomultimedia puede suponer una mejora importante en XPlore y en lastecnicas de desarrollo de programas de navegacion automatizada engeneral.

8.3.3. Desarrollo de agentes inteligentes no particula-rizados

Si bien XPlore se centra en el desarrollo de aplicaciones potentes de auto-matizacion de tareas en el Web, los programas desarrollados con este lenguajeestan particularizados a cada tarea. Sin duda, serıa mucho mas deseable notener que programar una aplicacion de este tipo para cada tarea, sino dispo-ner de un agente de proposito general capaz de analizar las paginas Web deun determinado dominio y decidir, conforme a los objetivos definidos por unusuario, los enlaces que deben seguirse y la forma en la que deben rellenar-se los formularios, decidiendo todo en tiempo de navegacion y no teniendopreprogramadas esas decisiones en aplicaciones que tıpicamente suelen fallarcuando algun elemento esperable en el camino de esa navegacion se presentade forma distinta a la esperada. Tal y como se vio en el apartado 1.3, estetipo de programas se corresponde con el Web Semantico [32], en el cual estanpuestas las expectativas en este sentido.

228

Apendices

8.4. Gramatica 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 telefonicas. www.teltarifas.com.[4] Consors espana. 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 ofSemistructured Data, 1997.

[26] A. S. F. Azavant. Building light-weight wrappers for legacy web data-sourcesusing w4f. International Conference on Very Large Databases (VLDB), 1999.

[27] J. Baeten, H. van Beek, and S. Mauw. An MSC based representation ofDiCons. 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 testingdynamic web sites. En WWW 11th conference, 2002.

[31] C. A. P. Bermudez. Un sistema mediador para la integracion de datosestructurados y semiestructurados. En Tesis Doctoral, Departamento deTecnoloxıas de Informacion e as Comunicacions - Universidade Da Coruna,2002.

[32] T. Berners-Lee, J. Hendler, and O. Lassila. The semantic web. En ScientificAmerican, May 2001.

[33] T. Bolognesi and E. Brinksma. Introduction to the iso specification languagelotos. En The Formal Description Technique LOTOS P. H. J. van Eijk,C. A. Vissers, and M. Diaz, Eds, pags 23–73, Elsevier Science PublishersNorth-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 ofdatabase systems. pags 117–121, 1997.

[37] D. Buttler, L. Liu, and C. Pu. A fully automated extraction system for theworld wide web. IEEE ICDCS-21, April 16-19 2001.

[38] M. E. G. Cabellos. Desarrollo de un portal web integrador de informacionbasada en subastas online. En Proyecto Fin De Carrera, Escuela PolitecnicaSuperior, Ingenierıa de Telecomunicacion - 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. SoftwareEngineering, 25(3):309–316, 1999.

[41] V. L. Centeno, P. T. Breuer, L. S. Fernandez, C. D. Kloos, and J. A. H.Perez. Msc-based language for specifying automated web clients. En TheEighth IEEE Symposium on Computers and Communications, Kemer, An-talya, Turkey, June 30 - July 3 2003.

[42] V. L. Centeno, L. S. Fernandez, 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. Fernandez, C. D. Kloos, P. T. Breuer, and F. P. Martın.Building wrapper agents for the deep web. En International Conference onWeb Engineering, Oviedo, Spain, July 2003.

232

[44] V. L. Centeno, C. D. Kloos, P. T. Breuer, L. S. Fernandez, M. E. G. Ca-bellos, and J. A. H. Perez. Automation of the deep web with user definedbehaviours. En First International Atlantic Web Intelligence Conference,AWIC 2003, Lecture Notes in Artificial Intelligence LNAI 2663 (Subseriesof 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. Lopez, and C. G. Ru-bio. Personalizing your electronic newspaper. En EUROMEDIA 99: FourthAnnual 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. Lopez, and C. G.Rubio. Diseno de un periodico electronico personalizado. En IV Jornadasde Informatica, pags 251–260, Las Palmas de Gran Canaria, Espana, Julio1998.

[47] V. L. Centeno, M. C. F. Panadero, C. D. Kloos, A. M. Lopez, and C. G.Rubio. Concepcion y desarrollo de un periodico electronico personalizado.En Jornadas Tecnicas RedIRIS, pags 24–31, Barcelona, Espana, Noviembre1998.

[48] V. L. Centeno, M. C. F. Panadero, D. R. Mateos, C. D. Kloos, A. R. de lasHeras, A. M. Lopez, C. G. Rubio, T.N. Flores, and T. H. Perez. Mass-customizing electronic journals. En XML EUROPE’99 Conference, pags233–240, Granada, Spain, Abril 1999.

[49] V. L. Centeno, M. C. F. Panadero, D. R. Mateos, C. D. Kloos, A. R. de lasHeras, A. M. Lopez, C. G. Rubio, T.N. Flores, and T. H. Perez. El periotroni-co: Xml en un periodico electronico a la carta. resultados y perspectivas. EnI Seminario del Programa Nacional de Aplicaciones y Servicios Telematicos(SPAST-I), pags 167–174, Pamplona, Espana, 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: Integrationof heterogeneous information sources. En 16th Meeting of the InformationProcessing 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 servicesdescription language (wsdl) 1.1. En W3C Note, 2001.

[54] F. Cohen. An xml-based scripting language that calls on java objects canprove 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 automaticdata 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 querylanguage for xml. www.research.att.com/ mff/files/final.html.

[57] M. C. Fernandez, V. L. Centeno, C. D. Kloos, A. M. Lopez, and C. G. Rubio.Diseno de un periodico electronico con xml. En II Congreso Nacional deIngenierıa de Telecomunicacion, pags 339–343, Madrid, Espana, Junio 1998.

[58] J. A. Fisteus. Diseno e implementacion de un conversor de html a xhtml.En Proyecto Fin De Carrera, E.T.S.E. Telecomunicacion - Universidade deVigo, 2001.

[59] D. Florescu, A. Grunhagen, and D. Kossmann. Xl: An xml programminglanguage for web service specification and composition. En WWW 11thconference, 2002.

[60] D. Florescu, A. Y. Levy, and A. O. Mendelzon. Database techniques for theworld-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 theWeb and Databases (WebDB ’99), pags 25–30, 1999.

[67] J.-R. Gruser, L. Raschid, M. E. Vidal, and L. Bright. Wrapper generationfor web accessible data sources. En Conference on Cooperative InformationSystems, pags 14–23, 1998.

[68] H. Gupta. Selection of views to materialize in a data warehouse. En ICDTciteseer.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.Nestorov, 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 ofComputer 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 Formaldescription 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 scienceand 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, pags259–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. Sanchez. Higher order ap-plicative xml documents. En Monterey Workshop 2002: Radical Innovationsof Software and Systems Engineering in the Future, Venice, Italy, October2002.

[83] N. Kushmerick, D. S. Weld, and R. B. Doorenbos. Wrapper induction forinformation extraction. En Intl. Joint Conference on Artificial Intelligence(IJCAI), pags 729–737, 1997.

[84] D. Libes. expect: Scripts for controlling interactive processes. ComputingSystems, 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 lasHeras, A. M. Lopez, C. G. Rubio, L. S. Fernandez, J. T.N. Flores, andA. H. Perez. Prensa en xml: el negocio de la personalizacion y la conquistade nuevos medios. En Jornadas Telecom I+D, Madrid, Espana, 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 lambdacalculus. 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 Proceedingsof 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. Lopez, T. Hernandez,C. G. Rubio, and L. S. Fernandez. 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 lasHeras, A. M. Lopez, C. G. Rubio, T.N. Flores, and T. H. Perez. Un periodicoa la carta: informacion personalizada mediante el uso de xml. En Jornadasde Publicacion electronica, pags 135–147, Leganes, Madrid, Julio 1999.

[100] M. C. F. Panadero, V. L. Centeno, D. R. Mateos, C. D. Kloos, A. R. de lasHeras, A. M. Lopez, C. G. Rubio, T.N. Flores, and T. H. Perez. Periodismoelectronico a la carta: noticias personalizadas con xml. En Novatica: Re-vista de la Asociacion de Tecnicos de Informatica, Num; 142, pags 16–19,Noviembre - Diciembre 1999.

[101] Y. Papakonstantinou, S. Abiteboul, and H. Garcia-Molina. Object fusionin mediator systems. En Proceedings of the Twenty-second InternationalConference on Very Large Databases, pags 413–424, 1996.

[102] T. Payne, R. Singh, and K. Sycara. Rcal: A case study on semantic webagents, proc. 1st int’l conf. autonomous agents and multiagent systems (aa-mas 02), acm press, newyork, 2002., 2002.

[103] J. A. H. Perez. Desarrollo de un portal web integrador de servidores decorreo electronico basado en tecnologa xml. En Proyecto Fin De Carrera,Escuela Politecnica Superior, Ingenierıa Informatica - Universidad CarlosIII 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 newservice and information technologies for older australians and people with adisabilities. 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 harmonizationof UML-Sequence Diagrams and MSC. En R. Dsoulli, G. von Bochmann,and Y. Lahav, editors, SDL’99: The Next Millennium, Proceedings of the9th SDL Forum, Montreal, Canada, June 1999. Elsevier Science Publishers.

[109] M. d. T. y. A. S. Secretarıa General de Asuntos Sociales. Test de accesibilidadweb. 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 extractionusing 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 ofthe 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 toEstelle, 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-

cacion de HTML 4.01, www.w3.org/TR/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. [email protected] 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. [email protected] 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 16November 1999, 1999.

[130] W3C. Xsl transformations (xslt) version 1.0. W3C Recommendation 16November 1999, 1999.

[131] W3C. Document object model (dom) level 2. W3C Recommendation 13November, 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, June1997, 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 programmaticcontrol of interactive applications. En CHI, pags 199–206, 1999.

238

automatizacion de tareas en el web

Documents