Automatizacion de Tareas en El Web

UNIVERSIDAD CARLOS III DE MADRID

Departamento de Ingenier´ıa Telem´atica Doctorado en Tecnolog´ıas de las Comunicaciones

TESIS DOCTORAL

´ DE TAREAS AUTOMATIZACION EN EL WEB: UNA PROPUESTA BASADA EN ´ ESTANDARES

Autor: Vicente Luque Centeno Licenciado en Inform´atica

Directores: Carlos Delgado Kloos y Luis S´ anchez Fern´ andez Doctores Ingenieros de Telecomunicaci´on

Tribunal nombrado por el Mgfco. y Excmo. Sr. Rector de la Universidad Carlos III de Madrid, el d´ıa de de .

Presidente D. Vocal D. Vocal D. Vocal D. Secretario D.

Realizado el acto de defensa y lectura de la Tesis el d´ıa de en .

de

Calificaci´on:

EL PRESIDENTE

EL SECRETARIO

LOS VOCALES

´Indice general

1. Planteamiento y objetivos

7

1.1. Diferencias entre navegaci´on manual y autom´atica . . . . . . .

9

1.1.1. Esfuerzo . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.1.2. Propensi´on a errores . . . . . . . . . . . . . . . . . . . 11 1.1.3. Tiempo de respuesta . . . . . . . . . . . . . . . . . . . 11 1.1.4. Requisitos hardware y software . . . . . . . . . . . . . 11 1.1.5. Adecuaci´on de repositorios . . . . . . . . . . . . . . . . 12 1.1.6. Procesamiento . . . . . . . . . . . . . . . . . . . . . . . 12 1.1.7. Coste de implantaci´on y adaptabilidad . . . . . . . . . 13 1.2. Ejemplos de tareas costosas para la navegaci´on manual . . . . 13 1.3. Tipos de programas de navegaci´on automatizada . . . . . . . . 16 1.3.1. Programas de navegaci´on gen´erica no adaptada . . . . 16 1.3.2. Programas de navegaci´on gen´erica adaptada . . . . . . 17 1.3.3. Programas de navegaci´on particularizada . . . . . . . . 17 1.3.4. Modos de integraci´on de aplicaciones Web . . . . . . . 20 1.3.5. Sistemas mediadores . . . . . . . . . . . . . . . . . . . 22 1.3.6. Asistentes de navegaci´on 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. Orientaci´on a los visualizaci´on . . . . . . . . . . . . . . 26 i

1.4.4. Relevancia dependiente de la tarea . . . . . . . . . . . 29 1.4.5. Regularidad estructural

. . . . . . . . . . . . . . . . . 30

1.4.6. Ausencia de sem´antica en el marcado . . . . . . . . . . 32 1.4.7. Niveles de estructuraci´on . . . . . . . . . . . . . . . . . 32 1.4.8. Distribuci´on de la informaci´on . . . . . . . . . . . . . . 35 1.4.9. Dif´ıcil modificabilidad . . . . . . . . . . . . . . . . . . 36 1.4.10. Aportaciones de XML . . . . . . . . . . . . . . . . . . 36 1.5. Coste de la navegaci´on automatizada . . . . . . . . . . . . . . 39 1.5.1. Coste de desarrollo . . . . . . . . . . . . . . . . . . . . 41 1.5.2. Coste de ejecuci´on 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. An´ alisis de tareas Web

53

2.1. Acciones b´asicas impl´ıcitas . . . . . . . . . . . . . . . . . . . . 57 2.1.1. Gesti´on de cabeceras HTTP . . . . . . . . . . . . . . . 57 2.1.2. Gesti´on de errores en la comunicaci´on con el servidor . 58 2.1.3. Reparaci´on interna de p´aginas mal construidas . . . . . 58 2.1.4. Seguimiento impl´ıcito de enlaces . . . . . . . . . . . . . 59 2.1.5. Ejecuci´on de comportamientos embebidos en las p´aginas 60 2.1.6. Soporte para otros protocolos . . . . . . . . . . . . . . 61 2.1.7. Tratamiento adecuado de cada campo de formularios seg´ un su forma de rellenado . . . . . . . . . . . . . . . 61 2.1.8. Creaci´on de query-string a partir de un formulario relleno 62 2.2. Acciones b´asicas expl´ıcitas . . . . . . . . . . . . . . . . . . . . 63 2.2.1. Extracci´on de datos relevantes . . . . . . . . . . . . . . 63 2.2.2. Estructuraci´on 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. Subsanaci´on de las faltas de soporte de la plataforma de navegaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3. Estado de la cuesti´ on

71

3.1. Consideraciones previas . . . . . . . . . . . . . . . . . . . . . . 71 3.2. Automatizaci´on de aplicaciones interactivas . . . . . . . . . . 72 3.2.1. Lenguaje Expect . . . . . . . . . . . . . . . . . . . . . 73 3.3. Web Sem´antico . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.4. Mecanismos de construcci´on de programas de navegaci´on automatizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 3.4.1. Uso de APIs est´andares . . . . . . . . . . . . . . . . . 83 3.5. Conclusiones del estado de la cuesti´on . . . . . . . . . . . . . . 87 3.6. Limitaciones de las tecnolog´ıas actuales . . . . . . . . . . . . . 90 4. Selecci´ on de tecnolog´ıas para la automatizaci´ on de tareas en el Web 95 4.1. MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.1.1. Entidades . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.1.2. Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.1.3. Acciones . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.1.4. Temporizadores . . . . . . . . . . . . . . . . . . . . . . 99 4.1.5. Corregiones . . . . . . . . . . . . . . . . . . . . . . . . 100 4.1.6. Condiciones . . . . . . . . . . . . . . . . . . . . . . . . 101 4.1.7. Creaci´on y destrucci´on din´amica de entidades . . . . . 101 4.1.8. Expresiones inline . . . . . . . . . . . . . . . . . . . . . 103 4.1.9. Descomposici´on modular . . . . . . . . . . . . . . . . . 103 4.2. XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.2.1. Secuencias . . . . . . . . . . . . . . . . . . . . . . . . . 108 iii

4.2.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 110 4.2.3. Operadores aritm´etico-l´ogicos y de comparaci´on . . . . 110 4.2.4. Ejes de navegaci´on . . . . . . . . . . . . . . . . . . . . 110 4.2.5. Predicados . . . . . . . . . . . . . . . . . . . . . . . . . 111 4.2.6. Llamadas a funciones . . . . . . . . . . . . . . . . . . . 112 4.2.7. Constructores de datos secundarios . . . . . . . . . . . 112 4.2.8. Modificaciones introducidas en XPath 2.0 respecto de XPath 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . 112 4.2.9. Aportaciones de XPath . . . . . . . . . . . . . . . . . . 114 4.3. XPointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.3.1. Puntos . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.3.2. Rangos . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.3.3. Patrones de texto . . . . . . . . . . . . . . . . . . . . . 116 4.3.4. Aportaciones de XPointer . . . . . . . . . . . . . . . . 117 4.4. XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4.4.1. Aportaciones de XSLT . . . . . . . . . . . . . . . . . . 119 4.5. XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.5.1. Aportaciones de XQuery . . . . . . . . . . . . . . . . . 121 4.6. DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 4.6.1. Aportaciones de DOM . . . . . . . . . . . . . . . . . . 122 4.7. SAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.7.1. Aportaciones de SAX . . . . . . . . . . . . . . . . . . . 124 5. XTendedPath: Lenguaje para la consulta y modificaci´ on de documentos XML 125 5.1. Problemas de XPath 2.0 . . . . . . . . . . . . . . . . . . . . . 126 5.1.1. Procesamiento incremental . . . . . . . . . . . . . . . . 126 5.1.2. Dificultad para calcular valores agregados

. . . . . . . 129

5.1.3. Combinar dos o m´as 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: extensi´on 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 sem´anticas . . . . . . . . . . . . . . . 141 5.4.3. Funciones de comparaci´on . . . . . . . . . . . . . . . . 143 5.4.4. Funciones l´ogicas . . . . . . . . . . . . . . . . . . . . . 144 5.4.5. Funci´on TO: (generador de secuencias num´ericas) . . . 144 5.4.6. Funciones EVERY y SOME: (expresiones cuantificadas) 145 5.4.7. Funciones eje . . . . . . . . . . . . . . . . . . . . . . . 145 5.4.8. Funci´on 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. Modificaci´on de documentos . . . . . . . . . . . . . . . 170 6. XPlore: Lenguaje para la navegaci´ on y procesamiento de datos en el Web 175 6.1. Componentes de XPlore orientados a la navegaci´on . . . . . . 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 ejecuci´on . . . . . . . . . . . . . . . . . . . . 189 6.2.5. Errores en la ejecuci´on . . . . . . . . . . . . . . . . . . 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. Valoraci´on de una cartera de acciones del Nasdaq en euros . . 196 7.2. Publicaci´on de un cat´alogo de art´ıculos en un Web de subastas 201 7.3. Listado de correos nuevos en un Web de correo gratuito y borrado de spam . . . . . . . . . . . . . . . . . . . . . . . . . 208 7.4. Recomendaciones de desarrollo . . . . . . . . . . . . . . . . . . 213 8. Conclusiones y trabajos futuros

221

8.1. Principales contribuciones . . . . . . . . . . . . . . . . . . . . 221 8.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 8.3. L´ıneas de trabajos futuros . . . . . . . . . . . . . . . . . . . . 225 8.3.1. Herramienta CASE . . . . . . . . . . . . . . . . . . . . 225 8.3.2. Accesibilidad a sitios Web orientados a la visualizaci´on 226 8.3.3. Desarrollo de agentes inteligentes no particularizados . 228 8.4. Gram´atica EBNF del lenguaje XPlore

vi

. . . . . . . . . . . . . 229

´Indice de cuadros 1.1. Diferencias entre la navegaci´on manual y la navegaci´on autom´atica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.2. Clasificaci´on de programas que navegan por el Web seg´ un su adaptaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3. Comparaciones aclarativas de alternativas de navegaci´on seg´ un coste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.4. Principales diferencias entre las u ´ltimas versiones de HTML . 29 1.5. Diferencias entre caracter´ısticas de los datos seg´ un su nivel de estructuraci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 1.6. Resumen de aportaciones de XML . . . . . . . . . . . . . . . . 38 1.7. Resumen de tipos de coste de la navegaci´on automatizada . . 40 1.8. Resumen de medidas de robustez seg´ un origen del fallo . . . . 45 2.1. Diferencias entre acciones b´asicas expl´ıcitas e impl´ıcitas . . . . 57 2.2. Principales cabeceras gestionadas por los clientes del protocolo HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.3. Tipo de seguimiento de enlaces HTML dependiendo del browser 60 2.4. Tipo de rellenado de campos de formularios HTML . . . . . . 62 2.5. Acciones b´asicas 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 comparaci´on en XTendedPath . . . . . . . . . . 143 5.4. Operadores l´ogicos en XTendedPath

. . . . . . . . . . . . . . 144

5.5. Generador de secuencias num´ericas en XTendedPath . . . . . 144 5.6. Expresiones cuantificadas en XTendedPath . . . . . . . . . . . 145 5.7. Sem´antica de la funci´on C . . . . . . . . . . . . . . . . . . . . 146 5.8. Ejemplo de la aplicaci´on de la currificaci´on en la funci´on C . . 146 5.9. Sem´antica de la funci´on D . . . . . . . . . . . . . . . . . . . . 147 5.10. Sem´antica de la funci´on DORSELF . . . . . . . . . . . . . . . 147 5.11. Sem´antica de la funci´on P . . . . . . . . . . . . . . . . . . . . 148 5.12. Sem´antica de la funci´on A . . . . . . . . . . . . . . . . . . . . 148 5.13. Sem´antica de la funci´on AORSELF . . . . . . . . . . . . . . . 149 5.14. Sem´antica de la funci´on PS . . . . . . . . . . . . . . . . . . . 149 5.15. Sem´antica de la funci´on FS

. . . . . . . . . . . . . . . . . . . 150

5.16. Sem´antica de la funci´on PREC . . . . . . . . . . . . . . . . . 150 5.17. Sem´antica de la funci´on FOLL . . . . . . . . . . . . . . . . . . 151 5.18. Sem´antica de la funci´on AT . . . . . . . . . . . . . . . . . . . 151 5.19. Texto de nodos en XTendedPath . . . . . . . . . . . . . . . . 152 5.20. Sem´antica de la funci´on 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 evaluaci´on 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. Sem´antica de la expresi´on INSIDE(a,b) . . . . . . . . . . . . . 164 viii

5.30. Ejemplos de uso del operador jer´arquico INSIDE . . . . . . . . 165 5.31. Sem´antica de la expresi´on CONTAIN(a,b) . . . . . . . . . . . 165 5.32. Funciones de orden superior de XTendedPath . . . . . . . . . 167 5.33. Ejemplos de expresiones XPath y sus equivalentes en XTendedPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 5.34. Operadores b´asicos de modificaci´on de documentos . . . . . . 171 5.35. Ejemplos de uso de la funci´on MASK . . . . . . . . . . . . . . 173 6.1. Relaci´on de expresiones inline con sentencias de control de flujo188 6.2. Primitivas de entrada/salida . . . . . . . . . . . . . . . . . . . 188 6.3. Primitivas de cambio de estado de ejecuci´on . . . . . . . . . . 189 6.4. Primitivas de errores de ejecuci´on . . . . . . . . . . . . . . . . 189 7.1. Estructura del documento XML con las cotizaciones del Nasdaq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

ix

x

´Indice de figuras 1.1. Sistema mediador . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.2. Comparaci´on de navegaci´on manual con autom´atica . . . . . . 25 1.3. Regularidad en el Web . . . . . . . . . . . . . . . . . . . . . . 31 3.1. Script Expect para controlar ejecuci´on interactiva de ftp . . . 74 3.2. Script Expect para controlar ejecuci´on 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. Creaci´on y destrucci´on din´amica 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. Representaci´on de elementos XPointer en un fragmento XML . 116 xi

4.13. Expresi´on XPath reformulada con el operador if . . . . . . . . 120 4.14. Expresi´on XPath reformulada con el operador every . . . . . . 120 5.1. Expresi´on XPath 2.0 que calcula importe de ventas con subtotales parciales . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.2. Pseudoc´odigo basado en variables que calcula subtotales . . . 127 5.3. Pseudoc´odigo basado en funciones que calcula subtotales . . . 128 5.4. Ejemplo de expresi´on 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. Restricci´on que debe cumplir todo rango en XTendedPath . . 160 5.13. Restricci´on de rangos reescrita con operadores jer´arquicos . . . 165 5.14. Algunas funciones de orden superior definidas en XTendedPath 168 5.15. Ejemplo de expresi´on lambda definida en Java . . . . . . . . . 170 5.16. Ejemplo de expresiones de rellenado de formulario . . . . . . . 171 5.17. Expresi´on XPath equivalente a source//address[addressee[text() =name]] . . . . . . . . . . . 173 6.1. Representaci´on de transacci´on HTTP . . . . . . . . . . . . . . 182 6.2. Ejemplo de ejecuci´on temporizada . . . . . . . . . . . . . . . . 183 6.3. Ejemplo de ejecuci´on reiterada . . . . . . . . . . . . . . . . . . 184 6.4. Ejemplo de ejecuci´on secuencial . . . . . . . . . . . . . . . . . 184 6.5. Ejemplo de ejecuci´on concurrente . . . . . . . . . . . . . . . . 185 6.6. Ejemplo de combinaci´on de servicios . . . . . . . . . . . . . . 185 6.7. Representaci´on de un bucle y una sentencia condicional anidados en XPlore notaci´on MSC . . . . . . . . . . . . . . . . . 187 xii

6.8. Ejemplo de sentencias anidadas en notaci´on compacta de XPlore187 6.9. Representaci´on de llamadas a funciones en XPlore notaci´on MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 6.10. Ejemplo de definici´on de funci´on Identif en XPlore notaci´on compacta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 6.11. Ejemplo de llamada de funci´on en XPlore

. . . . . . . . . . . 191

6.12. Ejemplo de llamada a clases Java desde XPlore notaci´on compacta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 6.13. Representaci´on de llamada a programa externo . . . . . . . . . 192 6.14. Representaci´on de operador de concurrencia . . . . . . . . . . 194 7.1. Cambio de divisas del BCE . . . . . . . . . . . . . . . . . . . 197 7.2. MSC gr´afico del programa Nasdaq . . . . . . . . . . . . . . . . 198 7.3. Programa Nasdaq en XPlore notaci´on MSC . . . . . . . . . . 199 7.4. Programa Nasdaq en XPlore notaci´on compacta . . . . . . . . 200 7.5. MSC gr´afico del programa Aucland . . . . . . . . . . . . . . . 202 7.6. Programa Aucland en XPlore notaci´on MSC . . . . . . . . . . 203 7.7. Campos del formulario de publicaci´on de Aucland . . . . . . . 204 7.8. Programa Aucland en XPlore notaci´on compacta . . . . . . . 205 7.9. Programa Aucland en XPlore notaci´on compacta (2) . . . . . 206 7.10. Programa Aucland en XPlore notaci´on compacta (3) . . . . . 207 7.11. Bandeja de entrada del correo de Yahoo! . . . . . . . . . . . . 208 7.12. MSC gr´afico del programa YahooMail . . . . . . . . . . . . . . 210 7.13. MSC gr´afico del programa YahooMail (2) . . . . . . . . . . . . 211 7.14. Programa YahooMail en XPlore notaci´on MSC . . . . . . . . . 212 7.15. Programa YahooMail en XPlore notaci´on MSC (2) . . . . . . 213 7.16. Programa YahooMail en XPlore notaci´on compacta . . . . . . 214 7.17. Programa YahooMail en XPlore notaci´on compacta (2) . . . . 215

xiii

xiv

Agradecimientos Quiero agradecer a todas aquellas personas que, de una un otra forma, han hecho posible este trabajo. Agradezco a mis padres el haber depositado su confianza en m´ı y haberme permitido seguir adelante y haberme apoyado en todo momento. A mis directores de tesis, quiero agradecerles los buenos y consejos y las sabias preguntas que me hicieron buscar las respuestas para elaborar este trabajo. A mis compa˜ neros del Departamento de Ingenier´ıa Telem´atica, por toda la colaboraci´on recibida y por todo lo que de ellos he aprendido en estos a˜ nos de doctorado. A mis antiguos compa˜ neros de la Facultad de Inform´atica, de donde tant´ısimas cosas aprend´ı. A mis amigos y amigas por haber estado ah´ı todo este tiempo.

1

2

Resumen Actualmente, millones de usuarios en todo el mundo se ven abocados a realizar cada d´ıa tareas en Internet, manejando de forma repetida un conjunto cada vez mayor de remotas aplicaciones que se encuentran accesibles en el Web. Para todas esas labores, la gran mayor´ıa de esas personas apenas cuenta con la u ´nica ayuda de los browsers, lo cual confiere al proceso de navegaci´on una alta necesidad de interacci´on por parte del usuario, en lo que habitualmente se conoce como navegaci´ on manual. Sin embargo, ello a menudo implica un esfuerzo demasiado elevado para muchas personas, especialmente cuando el volumen de datos es grande o la complejidad de su manejo requiere muchas interacciones con el browser. Desarrollar programas que naveguen automatizadamente por el Web, manipulando inteligentemente la informaci´on disponible en Internet es una necesidad cada vez m´as demandada en numerosos entornos. Sin embargo, el desarrollo de este tipo de programas tradicionalmente se ha afrontado con t´ecnicas que implican un alto coste de desarrollo y un elevado coste de mantenimiento, adem´as de tener una vida demasiado corta y ser muy sensibles a peque˜ nas modificaciones en las p´aginas accedidas. En este trabajo se proponen nuevas t´ecnicas basadas en est´andares para reducir el coste de estos desarrollos y mejorar la estabilidad de estos programas.

3

4

Abstract Nowadays, millions of people around the world have to daily perform tasks on Internet, repeatedly managing an increasing amount of Web enabled applications. For many of these tasks, most people use browsers, by manually and mecanically interacting with screens of data retrieved from remote computers. However, this implies too much effort for too many people, specially when the amount of data is big or those data require complex managements with several user interactions. Developing wrapper agents to automate these tasks for the user, by intelligently managing Web’s data is an increasingly demanded need at several enterprises. However these programs have traditionally had a large development and maintenance cost, they have had very short lives and their behaviour when minor changes affect pages is not desirable. This document presents several standards-based new techniques for reducing these costs and making these programs more stable.

5

6

Cap´ıtulo 1 Planteamiento y objetivos Esta tesis doctoral aborda el problema de la automatizaci´on de tareas en el Web. En cualquier automatizaci´on, como por ejemplo cualquiera de las llevadas a cabo en un complejo industrial, se persigue delegar en las m´aquinas la realizaci´on de trabajos, de forma que ´estos sean llevados a cabo con la m´ınima intervenci´on humana y mec´anica posible bajo un coste amortizable. El World Wide Web se ha convertido en poco tiempo en el mayor repositorio de conocimiento de la humanidad. Una multitud creciente de servicios Web, que comprenden, por una parte, a los servidores de informaci´on almacenada en simples p´aginas Web, y por otra, a las aplicaciones remotamente accesibles desde el Web para muy diversos prop´ositos, se puede acceder a trav´es de una gran variedad de p´aginas Web. Gran cantidad de esa informaci´on se encuentra muchas veces almacenada en bases de datos que, siendo accesibles mediante interfaces espec´ıficamente dise˜ nadas para el Web, se encuentran sin embargo a veces sin explorar conforme a las necesidades particulares de muchos usuarios. Mucha informaci´on, ciertamente, pero en especial muchas aplicaciones accesibles remotamente desde el Web, acaban quedando infrautilizadas para muchos usuarios en un mundo donde los browsers se han quedado ciertamente limitados como herramientas de trabajo, ya que carecen de cualquier tipo de prop´osito m´as all´a que el de la mera presentaci´on paginada de datos al usuario y la recogida de datos del usuario mediante formularios. La heterogeneidad del Web actual es inmensa. Por un lado, hay innumerables formas posibles de organizar y estructurar los contenidos dentro de cada p´agina mediante distintas combinaciones de etiquetas de marcado, no s´olo HTML sino tambi´en XML. Por otro lado, existen m´ ultiples variantes para distribuir la informaci´on entre las distintas p´aginas, as´ı como m´ ultiples 7

maneras de dejar ´estas enlazadas entre s´ı. Toda esta heterogeneidad dificulta enormemente la integraci´on de datos obtenidos de distintos servidores para su combinaci´on o gesti´on unificada. La integraci´on de datos de diversas fuentes, bien para la obtenci´on de datos elaborados con valor a˜ nadido (sindicaci´on de contenidos), bien como cadena de suministro (aplicaciones que deban pasarse datos de unas a otras), es un ´area que actualmente est´a demandando un creciente inter´es, habida cuenta de la necesidad de automatizar el manejo de grandes vol´ umenes de datos en el Web. En ocasiones, los usuarios se encuentran con la tarea de tener que rellenar muchas veces un conjunto conocido de formularios o seguir de forma repetitiva un mismo conjunto de enlaces para poder conseguir la informaci´on que desean o para poder manejar intensivamente aplicaciones remotamente por medio del Web. Estos usuarios acaban invirtiendo para ello gran cantidad de tiempo en labores que, dado su automatismo, ser´ıa muchas veces posible que se realizaran aut´ononamente por un ordenador. Es habitual que muchas de estas aplicaciones del Web ofrezcan interfaces para realizar transacciones simples, pero no que dispongan de interfaces para ofrecer m´ ultiples transacciones que puedan ser procesadas por lotes. Sin embargo, los usuarios no disponen hoy en d´ıa de otra herramienta m´as all´a del browser, por lo que acaban debiendo aprobar con un click de rat´on cada enlace que desean seguir una y otra vez, transacci´on a transacci´on, repetidamente cada vez que manejan una de estas aplicaciones accesibles desde el Web. Tradicionalmente, uno de los grandes problemas del Web estriba en la incapacidad de manejar en ´el grandes vol´ umenes de informaci´on de forma efectiva, conforme a los deseos de los usuarios. Los grandes buscadores apenas resuelven una peque˜ na parte del problema de la b´ usqueda de informaci´on. Aunque son capaces de listar los documentos del Web en los que se sabe que aparecen los t´erminos de b´ usqueda, no sin problemas como los apuntados por [28], los buscadores no dejan de devolver como resultados documentos enteros, dejando al usuario la responsabilidad de analizar su estructura, sem´antica o funcionalidad interna con el fin de buscar all´ı los datos que le interesan. Sin duda, las necesidades de los usuarios son mucho m´as complejas que aquellas a las que puede dar respuesta un simple buscador, ya que, una vez delante de la p´agina en la que debe empezar a trabajar, debe ser el usuario quien indique por d´onde navegar, construyendo as´ı el camino que le lleve a conseguir sus objetivos.

8

1.1.

Diferencias entre navegaci´ on manual y autom´ atica

Dentro del mundo industrial en general, la automatizaci´on persigue incrementar la productividad de las personas, minimizando los errores propios de la naturaleza humana y mejorando as´ı la eficiencia en la realizaci´on de trabajos y en la optimizaci´on de los recursos involucrados. Con la automatizaci´on de tareas en el Web se persiguen esos mismos objetivos aplicados en la realizaci´on del cada vez mayor n´ umero de tareas que pueden realizarse a trav´es del Web. Al igual que en cualquier empresa, el objetivo principal de la automatizaci´on de tareas en el Web es ahorrar tiempo y esfuerzo a las personas. En el caso del Web, los beneficios de la automatizaci´on ser´an m´as patentes en aquellas tareas que necesiten procesar grandes vol´ umenes de informaci´on o que deban ser frecuentemente ejecutadas. Trasladando a las m´aquinas las actividades m´as automatizables y rutinarias, se permite ahorrar esfuerzo a las personas. Gracias a ello las personas pueden centrarse en otras actividades, habitualmente m´as productivas, creativas y probablemente m´as adecuadas para sus trabajos y sus preparaciones. Sin duda, la productividad y creatividad humana se ve muchas veces aletargada por las tareas m´as rutinarias de navegaci´on en el Web. El hecho de tener que realizar una y otra vez los mismos pasos d´ıa a d´ıa delante de un browser, siguiendo los mismos enlaces y rellenando una y otra vez los mismos formularios, acaba siendo una tarea que requiere demasiado esfuerzo y dedicaci´on para muchas personas. Ejemplos de tareas que pueden requerir ser realizadas frecuentemente, son las que se pueden llevar a cabo con aplicaciones como las bancarias (comprobaciones de saldo, transferencias, listado de movimientos, operaciones de bolsa, subastas de dep´ositos, fondos de inversi´on ...), de subastas (publicaci´on de art´ıculos para vender, b´ usqueda y comparaci´on de art´ıculos para pujar, inserci´on de pujas, gesti´on de avisos, evaluaci´on de transacciones, ...), de compra-venta (b´ usqueda y comparaci´on de art´ıculos, realizaci´on de pedidos y de pagos, ...), de reserva de billetes de avi´on o de tren, habitaciones de hotel, entradas a espect´aculos, env´ıo de mensajes, as´ı como un largo etc´etera. Estas aplicaciones se encuentran cada vez m´as frecuentemente, tanto en las intranets de las empresas, como accesibles a todo el mundo en un gran n´ umero de servidores. Algunas de las tareas Web, en especial las que deben hacerse de forma repetitiva mediante browsers, suponen demasiado esfuerzo, en tanto en cuanto para llevarlas a cabo, las acciones mec´anicas que debe ejecutar el usuario para indicar sus instrucciones al ordenador, deben ser repetidas muchas veces. 9

Al contrario de lo que ocurre con la navegaci´on manual basada en browsers, gracias a la automatizaci´on de tareas en el Web, grandes vol´ umenes de informaci´on distribuida en m´ ultiples bases de datos accesibles desde el Web pueden ser procesados conforme a los intereses de los usuarios requiriendo de ellos un esfuerzo m´ınimo. Las principales diferencias entre la navegaci´on manual y la autom´atica, resumidas en la tabla 1.1, aparecen detalladas a continuaci´on.

Navegaci´ on manual

Navegaci´ on autom´ atica

Intervenci´ on

Humana

Ordenador

Acci´ on

Mec´ anica

Programada

Esfuerzo

De navegaci´ on

De programaci´ on

Errores

De navegaci´ on

De programaci´ on

Tiempo de respuesta

Significativo

´Infimo

Requisitos

Browser

Conexi´ on

Repositorios

No programables

Programables

Procesamiento

C´ alculo mental

Automatizable

Volumen de datos

Limitado

Enorme

Implantaci´ on

Factible

Costosa

Adaptabilidad ante cambios

Tolerable

Costosa

Cuadro 1.1: Diferencias entre la navegaci´on manual y la navegaci´on autom´atica

1.1.1.

Esfuerzo

El Web actual est´a dise˜ nado para ser navegado de forma interactiva, con el usuario proporcionando mec´anicamente una a una sus instrucciones detr´as de la pantalla del ordenador, haciendo click en cada enlace que desea seguir. Ello supone en muchas ocasiones un serio coste de recursos humanos, esto es, de personas que deben dedicar a menudo una gran cantidad de tiempo, esfuerzo y perseverancia frente al ordenador para realizar tareas sencillas. Frente a esa opci´on, una tarea automatizada por un programa capaz de navegar en lugar del usuario, emulando el comportamiento de la actuaci´on conjunta de ´este y del navegador, puede reducir significativamente ese coste de navegaci´on. 10

1.1.2.

Propensi´ on a errores

La interacci´on mec´anica de las personas en la navegaci´on manual aumenta en gran medida la propensi´on a cometer errores durante la ejecuci´on de la tarea. Este riesgo se hace m´as probable cuando el conjunto de datos que debe ser manipulado es voluminoso. Por el contrario, un programa que navegue autom´aticamente por el Web puede manipular eficiente y adecuadamente grandes vol´ umenes de informaci´on, incluso a pesar de que ´esta se encuentra distribuida en varias fuentes de datos.

1.1.3.

Tiempo de respuesta

Pese a que el rendimiento de una aplicaci´on Web est´a principalmente condicionado por el tiempo de respuesta del servidor y de las conexiones que comunican a ´este con el cliente, lo cierto es que, las personas, cuando navegamos delante de un browser en el que debemos introducir interactivamente nuestras ´ordenes, tenemos unos tiempos de respuesta significativos. Adem´as, y no menos importante, las personas somos f´acilmente distra´ıbles de nuestros cometidos, como puede ocurrir con la aparici´on de enlaces que inesperadamente reclamen nuestra atenci´on por un tema que nos interese y no tenga nada que ver con la tarea que nos estaba ocupando. Incluso en una escena en la que un operador se encuentre altamente concentrado en la realizaci´on de una tarea con un browser, el simple hecho de tener que activar mec´anicamente unos dispositivos de introducci´on de datos, como el teclado y el rat´on, estando a la vez pendiente de varias ventanas abiertas en la pantalla que reclaman simult´aneamente la atenci´on del usuario, supone unos tiempos de retraso que, aunque aceptables para unas pocas transacciones, resultan ciertamente frustrantes cuando el n´ umero de acciones mec´anicas a ejecutar acaba siendo elevado, especialmente debido a la imposibilidad de ordenar trabajos por lotes en el Web.

1.1.4.

Requisitos hardware y software

Sin duda, uno de los grandes problemas de los browsers es que, adem´as de la intervenci´on mec´anica necesaria para poder proceder al seguimiento de enlaces, requieren de hardware y software especializado, de forma que gran parte del Web ahora mismo est´a pensada exclusivamente para ser accesible desde ordenadores personales (PC), con unas resoluciones de pantalla determinadas, y con unos requisitos de software espec´ıficos muy concretos. 11

Sin embargo, la proliferaci´on de un cada vez mayor n´ umero de dispositivos electr´onicos conectados a la red, como algunas cabinas p´ ublicas de acceso a Internet, los dispositivos inal´ambricos, u otros peque˜ nos electrodom´esticos, est´a aumentando el n´ umero de dispositivos con reducidas capacidades de visualizaci´on de datos, que, sin embargo, no dejan de ser capaces de tratar adecuadamente los datos de la Red. Estos dispositivos podr´ıan f´acilmente conectarse a la red para automatizar tareas en el Web, al igual que lo hace cualquier otro ordenador, conforme a lo propuesto en [42], prescindiendo, al tratar autom´aticamente las p´aginas sin necesitar que el usuario las visualice para proporcionar interactivamente sus instrucciones sobre las mismas, de las capacidades de visualizaci´on que s´ı poseen los ordenadores de sobremesa en los que se ejecutan los browsers. Es decir, la navegaci´on manual est´a pr´acticamente limitada a un conjunto muy particular de dispositivos (aquellos que tengan instalado el browser contemplado por el sitio Web), mientras que la navegaci´on autom´atica, al carecer de esas restricciones, puede llevarse a cabo desde un n´ umero mucho mayor de dispositivos de acceso, como neveras, asistentes personales, tel´efonos m´oviles, set-top boxes ...

1.1.5.

Adecuaci´ on de repositorios

Otro de los problemas con los que se encuentran las personas que navegan con browsers es que la forma de recolectar los datos relevantes que van encontrando est´a basada en m´etodos poco automatizables, e inadecuados para grandes vol´ umenes de datos, como la memorizaci´on, el apuntar los datos en un papel, guardar toda la p´agina a fichero, imprimirla para analizarla frente a otras personas en una reuni´on, o, quiz´a en el mejor de los casos, el simple copiar y pegar en la ventana de otra aplicaci´on. Sin embargo, ni el papel, ni la memoria humana, ni una ventana abierta de un editor de texto son repositorios adecuados para almacenar los datos relevantes que se van extrayendo de las p´aginas cuando el volumen de datos empieza a ser considerable. Por el contrario, desde el punto de vista de la automatizaci´on de tareas, es deseable la utilizaci´on de repositorios de datos accesibles desde programas de ordenador, como variables de memoria, ficheros con alg´ un tipo de estructura conocida por el programador o registros en una base de datos.

1.1.6.

Procesamiento

Pese a que muchas veces el procesamiento que se debe realizar sobre los datos del Web es realmente sencillo, (aunque ciertamente es posible que en 12

el futuro estos procesamientos se puedan volver cada vez m´as complejos), lo cierto es que el volumen de datos que muchas veces hay que manejar en el Web es demasiado alto como para ser manejado mentalmente por personas delante de un navegador. Es f´acil encontrar la versi´on m´as barata de un libro en una p´agina que tenga pocos ejemplares, pero ya no lo es tanto cuando se desean comparar un gran n´ umero de listados de tiendas, cada una con sus propios precios, de forma que haya que mezclar los resultados de todas ellas, y calcular el gasto final incluyendo gastos de env´ıo, descuentos especiales o promocionales, o eliminando resultados repetidos. Realizar este tipo de tareas es algo que puede f´acilmente ser automatizado por un programa capaz de acceder a los datos involucrados si ´estos se encuentran convenientemente almacenados en un repositorio adecuado de datos como los mencionados en el punto anterior.

1.1.7.

Coste de implantaci´ on y adaptabilidad

Todas las ventajas de la navegaci´on autom´atica frente a la navegaci´on manual tienen un coste. Desarrollar aplicaciones que automaticen las tareas de navegaci´on en el Web es costoso. Apenas existen t´ecnicas espec´ıficamente orientadas a la reducci´on del coste de implantaci´on de este tipo de programas. Buena parte de ellas puede encontrarse en el cap´ıtulo 3. Sin embargo, cualquier m´ınimo cambio en la estructura de las p´aginas involucradas en una tarea puede acabar requiriendo una ardua labor de mantenimiento. Por el contrario, las p´aginas cuya estructura es frecuentemente actualizada, no plantean excesivos problemas a las personas que las navegan manualmente con browsers, pues el comportamiento humano es f´acilmente adaptable a las nuevas circunstancias, algo que no puede decirse normalmente del comportamiento de los programas de ordenador. En el apartado 1.5 aparecen m´as detallados estos costes.

1.2.

Ejemplos de tareas costosas para la navegaci´ on manual

Seg´ un aumentan las posibilidades de realizar nuevas acciones en un mundo cada vez m´as interconectado, resulta cada vez menos dif´ıcil encontrar tareas capaces de absorber horas de trabajo a sus usuarios o en las que se justifique poco la conveniencia de que ´estos deban estar presentes en todo momento ante la pantalla del ordenador. A continuaci´on 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 personas. Actualmente esa labor se desarrolla rellenando un formulario en un u ´nico paso, pero que debe ser rellenado y enviado una vez para cada persona, introduciendo datos personales y fiscales de la declaraci´on anterior. Publicar en eBay un cat´alogo de una tienda con 500 art´ıculos en subastas. Actualmente cada art´ıculo requiere el rellenado del orden de unos 8 ´o 9 formularios, que aparecen en secuencia y que empiezan por la selecci´on del tipo de subasta y categor´ıa en la que se desea publicar, contin´ uan preguntando por informaci´on especializada del art´ıculo basada en las selecciones anteriores, y acaban solicitando una confirmaci´on de que todo est´a conforme para el usuario. En algunos de los pasos cabe la posibilidad de que aparezcan variantes en la secuencia, como por ejemplo los que se desprenden del hecho de que cada art´ıculo pueda incluir o no fotograf´ıa, por lo que para esos art´ıculos puede ser necesario rellenar un formulario aparte para enviar la foto al servidor. Adem´as, resulta deseable realizar una serie de m´ınimas comprobaciones en cada paso, como el cercioramiento de que las tarifas que se pretenden cobrar son las que el usuario espera, o que se confirme que cada art´ıculo ha sido efectivamente puesto en subasta (no hacer este tipo de comprobaciones significa no tener garantizado el cumplimiento de la tarea). El algoritmo de esta tarea consistir´a en el rellenado en secuencia de los formularios necesarios para la publicaci´on de un art´ıculo, contemplando las cuestiones mencionadas, de forma que esa secuencia figure dentro de un bucle que itere sobre los art´ıculos que se desea publicar, presumiblemente le´ıdos de alg´ un repositorio definido por el usuario. Buscar con Google cada semana las p´aginas de cierto tema, manteniendo para ello una lista acumulada de p´aginas ya conocidas que se restar´a a los resultados obtenidos. De esta forma se presentar´a al usuario una lista que contenga exclusivamente las direcciones hasta el momento no conocidas por el usuario y que los robots de Google, en su continuo devenir por la red, van descubriendo. En todo caso, los resultados que se analicen de Google no deben comprender s´olo la primera p´agina de resultados, sino que debe inspeccionar todas independientemente de la paginaci´on, filtrando de los resultados encontrados aquellos que aparezcan en la lista de conocidos por el usuario. Dicha lista deber´a residir en un fichero en el ordenador del usuario, capaz de ser actualizado por 14

´este, pues Google, en su versi´on actual, no permite albergar este tipo de informaci´on personalizada para cada usuario. Componer un listado con los titulares de los principales peri´odicos cada ma˜ nana. Los resultados podr´ıan ser visualizados en una televisi´on conectada a Internet mediante una set-top box que recoja los titulares de varias fuentes de noticias del Web y las presente agrupadas al usuario por secciones o seg´ un sus preferencias. Buscar, desde una nevera conectada a Internet, la mejor oferta de leche fresca en varias tiendas, incluyendo, a ser posible, no s´olo la b´ usqueda en tiendas habilitadas para neveras, sino en cualquier tienda que venda a domicilio. Ampliar la tarea anterior para que busque la tienda que pide menos dinero por la entrega a domicilio de una cesta de la compra con varios art´ıculos, incluyendo los gastos de env´ıo y descuentos aplicables de cada tienda. Chequear si, entre los mensajes en varias cuentas de correo Web (de varios portales) hay algunos que cumplan ciertos requisitos, como remitentes especiales o fechas o asuntos determinados. A cada uno de esos mensajes, aplicarles ciertas acciones, como extraer de ellos los cuerpos de los mensajes para ser le´ıdos, cambiarlos de carpeta, responderlos, reenviarlos a alguna direcci´on o simplemente borrarlos. Mandar un SMS (Short Message Service) a una lista de tel´efonos m´oviles usando los formularios que para ello ponen accesibles algunos portales del Web, a ser posible eliminando las restricciones que imponen estos portales sobre tama˜ no de los mensajes y n´ umero de mensajes enviados por unidad de tiempo. Buscar en alg´ un reconocido portal de ocio los restaurantes de una determinada zona geogr´afica, seleccionar aquellos que sirvan comida a domicilio y comparar sus ofertas. Combinar la informaci´on de restaurantes de un portal de ocio (que indique si aceptan tarjeta de cr´edito) con el callejero de la ciudad ofrecido por otro portal para obtener un listado de restaurantes que acepten tarjeta de cr´edito que est´en cerca de la salida del cine al que voy a ir esta tarde. 15

La mayor´ıa de los ejemplos anteriores est´a pensada para automatizar un elevado volumen de datos en una aplicaci´on accesible desde el Web, como puede ser una aplicaci´on de recolecci´on de datos de la Administraci´on, un buscador, una aplicaci´on de publicaci´on de subastas, una aplicaci´on de env´ıo de mensajes a m´oviles o una que gestione cuentas de correo electr´onico desde el Web. En algunos casos, en lugar de acceder a una aplicaci´on, la tarea debe acceder simplemente a varias p´aginas de estructura conocida pero de informaci´on variante, con el fin de combinar la informaci´on dispersa en esas fuentes de la forma deseada por el usuario.

1.3.

Tipos de programas de navegaci´ on automatizada

Para conseguir automatizar tareas en el Web se necesita disponer de aplicaciones que automaticen la navegaci´on de los usuarios en p´aginas y aplicaciones en el Web, de forma que sustituyan al usuario siguiendo alguna secuencia de enlaces que deban seguirse y formularios que deban rellenarse para poder realizar la tarea. Los programas que pueden navegar en el Web pueden clasificarse seg´ un su grado de particularizaci´on a las p´aginas Web que se espera que visiten. Dicho criterio permite clasificar estos programas en tres grandes grupos:

1.3.1.

Programas de navegaci´ on gen´ erica no adaptada

Son programas que no est´an particularizados a ning´ un sitio Web y que, por lo tanto, pueden ser usados en cualquiera de ellos. Normalmente se dedican a solicitar interactivamente al usuario informaci´on acerca de qu´e enlaces seguir (browsers), o bien a seguir todos los enlaces de un sitio Web para realizar una tarea muy sencilla, normalmente id´entica en cada una de las p´aginas encontradas, como por ejemplo, la indexaci´on por palabras de cada una de sus p´aginas (robots de buscadores), la comprobaci´on de enlaces rotos [126], la descarga completa de sitios Web [20] o el aviso de que ciertas p´aginas han sido actualizadas recientemente [15]. Dado que estos programas carecen normalmente de un contexto sem´antico (ver tabla 1.6) y por lo tanto, son incapaces de particularizar su comportamiento al significado sem´antico de los datos de las p´aginas visitadas, s´olo pueden ser usados en tareas muy sencillas, sin posibilidades de poder navegar de forma eficiente por el deep Web [110, 105]. 16

1.3.2.

Programas de navegaci´ on gen´ erica adaptada

Son programas que, siendo en principio utilizables en cualquier Web, necesitan meta-informaci´ on acerca del mismo para poder navegarlo de forma adaptada a sus caracter´ısticas particulares. Normalmente, suelen analizar primero la meta-informaci´on, expresada en t´erminos declarativos, del sitio Web para decidir mientras navegan qu´e enlaces tienen la mayor probabilidad de llevar a la consecuci´on de unos objetivos preestablecidos. El Web Sem´antico [87] del W3C es un prometedor exponente de esta forma de automatizaci´on de tareas en el Web.

1.3.3.

Programas de navegaci´ on particularizada

Son programas totalmente particularizados a las peculiaridades de un sitio Web concreto, por lo que, en principio, no son reutilizables en otros sitios Web. Estos programas, com´ unmente denominados wrappers o c´odigo envoltorio [70], presentan importantes ventajas, ya que no necesitan ning´ un tipo de metadatos y pueden estar completamente adaptados a las caracter´ısticas del sitio Web visitado. Mediante el seguimiento, particularizado al sitio Web, de enlaces pre-programados est´aticamente seg´ un la sem´antica que el programador impl´ıcitamente refleja en el c´odigo de estos programas, pr´acticamente casi cualquier tarea concebida por el usuario puede ser desarrollada de forma eficiente, teniendo adem´as en cuenta sus preferencias acerca de la forma en la que desea que se lleve a cabo la tarea. Por ejemplo, para borrar el correo spam en la bandeja de entrada de una cuenta de correo Web como el de Yahoo!, un usuario puede querer marcar los correos de ciertos dominios que ´el considera spam, para despu´es pulsar en el bot´on de borrado, mientras que otro usuario puede preferir seleccionar los mensajes con determinados asuntos movi´endolos a una carpeta temporal que ser´a borrada posteriormente. Sin embargo, este tipo de programas son muy costosos, tanto de desarrollar (debe implementarse uno para cada tarea), como de mantener (cualquier cambio en la estructura de las p´aginas accedidas puede provocar un malfuncionamiento del programa). En la tabla 1.2 aparecen resumidas las principales caracter´ısticas de los distintos tipos de programas que navegan por el Web seg´ un su grado de adaptaci´on a las p´aginas de esos sitios Web.

17

Gen´ erica no adaptada

Gen´ erica adaptada

Particularizada

Ejemplos

Browsers, robots

Web Sem´ antico

Wrappers

Algoritmo

Usuario, fuerza bruta

Guiado por objetivos

Pre-programado

Contexto sem´ antico

Nulo

Metadatos declarativos

Impl´ıcito en programaci´ on

Construcci´ on de caminos

Usuario, todos

Din´ amica

Est´ atica, pero flexible

Implantabilidad

F´ acil

Incipiente, a largo plazo

Conocida y factible

Mantenimiento

´Infimo

F´ acil (declarativo)

Costoso (programaci´ on)

Aplicable a cualquier Web

S´ı

Si tiene metadatos

No

Automatizaci´ on de tareas

MUY simples

No complejas

S´ı

Cuadro 1.2: Clasificaci´on de programas que navegan por el Web seg´ un su adaptaci´on Comparaciones de costes Siempre que se permita al autor un par de peque˜ nas licencias literarias, cabr´ıa quiz´a comparar los distintos tipos de programas orientados a la navegaci´on en el Web con soluciones m´edicas que intentan paliar una enfermedad en una persona y con la navegaci´on marina. Los programas gen´ericos no adaptados podr´ıan asimilarse a los tratamientos m´edicos m´as sencillos, sin receta y con un bajo coste, y que todo el mundo puede usar, como el hecho de beber agua, ingerir t´e verde o incluso tomar una aspirina. Son ´estas soluciones v´alidas y f´acilmente aplicables para problemas habitualmente comunes de encontrar. Los programas gen´ericos adaptados podr´ıan quiz´a asimilarse a una fisioterapia o a un tratamiento medicinal con receta m´edica. Este tipo de soluciones est´a enfocada a una finalidad m´as espec´ıfica que los tratamientos sencillos son incapaces de resolver por s´ı mismos, por lo que se requiere normalmente la ayuda de alguien externo capaz de facilitar la soluci´on al usuario. Finalmente, los programas no gen´ericos, esto es, los completamente particularizados, pueden ser comparables a una operaci´on de cirug´ıa. Este tipo de operaciones tiene un coste sensiblemente superior al de otras alternativas, pero es realmente efectivo cuando el problema del usuario no puede ser solucionado con las t´ecnicas anteriores. De la misma forma, puede hacerse un s´ımil de la navegaci´on en el deep Web con los viajes en el mar. Una navegaci´on basada en browsers puede ser asimilada con un buzo, capaz de sumergirse con autonom´ıa propia por cualquier recoveco marino por estrecho que sea, pero incapaz de recorrer grandes distancias ni de llegar a grandes profundidades (adem´as de estar frecuentemente orientada al ocio). Los robots son asimilables a los barcos, capaces de 18

recorrer grandes distancias en superficie, pero incapaces de navegar por el deep Web rellenando formularios o siguiendo enlaces de profundidad potencialmente ilimitada. La gran diversidad de robots seg´ un su complejidad es asimilable a la gran diversidad de barcos existentes, desde peque˜ nas balsas a transatl´anticos, seg´ un su complejidad. En todos los casos, su navegaci´on est´a centrada en la parte m´as superficial del mar y nunca se sumergen en el fondo del deep Web. La navegaci´on con alternativas gen´ericas adaptadas como la del Web Sem´antico es asimilable a varias alternativas, seg´ un el punto de vista de sus promotores o sus detractores. Para los primeros, el Web Sem´antico es comparable a un enorme submarino tripulado, capaz de automatizar cualquier tarea a cualquier distancia y profundidad y con capacidad aut´onoma (programaci´on de agentes y de inteligencia artificial) para tomar decisiones durante la navegaci´on, pero incapaz de introducirse por los recovecos en los que no cabe, es decir, incapaz de navegar sin sus correspondientes metadatos. Para sus detractores, sin embargo, el Web Sem´antico promete demasiadas cosas irrealizables a´ un hoy en d´ıa, y es en realidad m´as asimilable al uso de una red de transitables t´ uneles construidos debajo del fondo del mar (como el Eurotunel que atraviesa el canal de la Mancha). En ambos casos se requiere la construcci´on de rutas de navegaci´on (por las que quepa el submarino) o transitables t´ uneles adaptados al fondo marino, que sean asimilables a los metadatos adaptados al sitio Web al que describen. Estos metadatos act´ uan como gu´ıas de la navegaci´on, indicando por d´onde navegar y por d´onde no y cu´al es el camino que hay que tomar en cada bifurcaci´on para llegar a un destino. Finalmente, cuando se necesita recorrer grandes distancias, acceder a grandes profundidades e introducirse por peque˜ nos recovecos en los que no cabe un enorme submarino, y no se dispone de metadatos, lo habitual es recurrir a soluciones como los peque˜ nos batiscafos no tripulados y teledirigidos, costosos, pero capaces de recorrer cualquier ruta. La tabla 1.3 contiene un resumen de estas comparaciones aclarativas.

Gen´ erica no adaptada

Gen´ erica adaptada

Particularizada

Ejemplos

Browsers, robots

Web Sem´ antico

Wrappers

Medicina

T´ e verde, aspirinas, ...

Medicaci´ on con receta, fisioterapia, ...

Cirug´ıa

Deep Web

Buzo, barcos

Red de t´ uneles bajo el mar, submarino

Batiscafo no tripulado

Coste

Bajo

Medio/alto

Alto

Cuadro 1.3: Comparaciones aclarativas de alternativas de navegaci´on seg´ un coste

19

Las tareas que los usuarios necesitan automatizar en el Web pueden llegar a ser bastante complejas. S´olo aquellos programas capaces de manipular adecuadamente los datos que aparecen en los documentos visitados pueden servir al usuario para automatizar sus tareas en el Web. Dado que la mayor´ıa de las tareas realizables por las aplicaciones de navegaci´on gen´erica no adaptada son demasiado simples y que el Web Sem´antico es a´ un una tecnolog´ıa realmente incipiente, la principal alternativa utilizable actualmente consiste en la creaci´on de programas de navegaci´on particularizada a los sitios Web. La navegaci´on basada en wrappers ha sido sin duda la que m´as aportaciones ha realizado u ´ltimamente a la automatizaci´on de complejas tareas en el Web, en donde ha demostrado en repetidas ocasiones ser aplicable de forma fruct´ıfera [67]. Si bien los contextos sem´anticos (ver tabla 1.6) basados en metadatos declarativos pueden a´ un tardar tiempo en ser efectivos, es constatable que los contextos sem´anticos embebidos en las sentencias de programaci´on que forman parte del c´odigo de un wrapper son una poderosa arma de automatizaci´on. Por otro lado, si bien la construcci´on din´amica de caminos de navegaci´on guiados por el cumplimiento de objetivos resulta impracticable sin la existencia de metadatos, la construcci´on est´atica, pero flexible para ganar robustez, de caminos pre-programados de navegaci´on donde no sea necesaria la existencia de metadatos que indiquen los enlaces que se deben seguir, puede servir como base para la automatizaci´on de tareas que manejen aplicaciones accesibles desde el Web.

1.3.4.

Modos de integraci´ on de aplicaciones Web

Cuando se desea automatizar tareas que involucran a m´as de una aplicaci´on Web, dos modos de integrarlas suelen ser los m´as empleados. Integraci´ on de aplicaciones similares Es normal encontrar aplicaciones de diversos servidores que, siendo sem´anticamente similares porque est´an concebidos para fines parecidos, desde el punto de vista del marcado de sus p´aginas, son estructuralmente distintas. Normalmente, se trata de aplicaciones que, aunque pueden tener peque˜ nas diferencias entre s´ı, ofrecen una funcionalidad similar al usuario, cada una accesible desde su propio servidor. Es por ello que el usuario puede tener que conectarse simult´aneamente a varias de ellas a la vez, escogiendo sobre la marcha, qu´e acciones desea ejecutar en ciertas aplicaciones y qu´e otras acciones desea ejecutar en otras. Agentes de bolsa, personas con varias cuentas 20

de correo electr´onico o con varias cuentas bancarias, personas que manejen varios sitios de subastas en el Web o que quieran simplemente buscar las mejores ofertas en varias tiendas suelen tener que abrir varias ventanas, una para cada una de estas aplicaciones, y operar con todas ellas a la vez.

Integraci´ on de aplicaciones complementarias

Por otro lado, tambi´en resulta frecuente encontrarse con tareas que involucran el intercambio de datos entre varias aplicaciones construidas de forma independiente unas de otras, pero que no est´en integradas convenientemente, por lo que la u ´nica forma de manejarlas sea manipulando los formularios propios de acceso a la herramienta. Ante esta situaci´on, los usuarios t´ıpicamente deben conectarse a alguna de ellas y, tras analizar los datos obtenidos de ´esta, enviar esos mismos datos, quiz´a con alguna variaci´on, a otra herramienta, rellenando con el teclado y el rat´on su correspondiente formulario. Eso suele ocurrir en entornos donde, por ejemplo, una aplicaci´on se dedica a recoger peticiones de muchos usuarios y, antes de procesarlas convenientemente, un supervisor debe darles el visto bueno, reinsertando esos datos en otra aplicaci´on junto con alguna informaci´on adicional. En ese caso, el supervisor, si las herramientas no se han integrado convenientemente, puede tener que estar copiando los datos de una ventana de la primera herramienta y peg´andolos en una ventana de la segunda herramienta. Otro ejemplo distinto, pero con el mismo planteamiento operativo, se puede encontrar en personas que deban enviar por alguna aplicaci´on Web de correo electr´onico determinados fragmentos de documentos que una primera aplicaci´on les pueda estar mostrando en otra ventana. Sin duda, las tareas realizables pueden llegar a ser ciertamente impensables para los dise˜ nadores de las aplicaciones Web accedidas, pues son los usuarios quienes mejor definen la forma en la que desean hacer sus tareas. Por ejemplo, una persona puede desear responder desde el correo que tiene en Yahoo! los correos electr´onicos que le lleguen a su cuenta de correo en Hotmail, porque no desee responder directamente desde all´ı. En este caso, los formularios de Yahoo! deber´an recibir informaci´on, no s´olo del usuario, sino de la proporcionada por Hotmail, de la misma forma en la que un usuario que realizara esa tarea hubiera copiado y pegado ese texto desde la ventana de una aplicaci´on 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 p´aginas HTML disponibles dentro de todo el Web, tambi´en pueden encontrarse con frecuencia en abundantes fuentes de datos dentro de entornos corporativos de tama˜ no mediano o grande. Precisamente por ello, son numerosas las empresas que presentan actualmente necesidades de poder integrar, no ya en un u ´nico documento, sino quiz´a tambi´en en la toma de decisiones operativas de la empresa, los datos provenientes de varias de esas fuentes de datos preexistentes, de la misma forma en la que es necesario realizar tareas que combinen la informaci´on obtenida de distintas fuentes en el Web. Si bien es habitual que cada una de esas fuentes fuera desarrollada en su momento con distintas tecnolog´ıas y objetivos, lo cierto es que la gran mayor´ıa de ellas fue concebida para ser accedida de forma que la informaci´on resultante de cada una de ellas fuera a ser consultada directamente, bien por personas, bien, en el mejor de los casos, pese a su enorme coste, por otras aplicaciones capaces de realizar llamadas a una interfaz particular de la aplicaci´on. Las nuevas formas de negocio de hoy en d´ıa y la necesidad de manipular mucho m´as eficientemente grandes vol´ umenes de informaci´on de fuentes muy diversas han contribuido ineludiblemente a una necesidad cada vez mayor de que esas consultas a los antiguos sistemas aislados preexistentes puedan estar ahora integradas en otras consultas realizadas por nuevos programas capaces de combinar eficientemente la informaci´on que pueda estar distribuida en varios repositorios independientes entre s´ı. De esta forma, los datos relevantes se pueden considerar como provenientes de fuentes semi-estructuradas [66], esto es, con un formato reconocible m´as all´a del simple texto sin estructura, si se tienen en cuenta precisamente combinaciones especiales de etiquetas de marcado que son capaces de identificar a los datos clave que deben extraerse de las p´aginas. Un foco importante de investigaci´on en la actualidad es la construcci´on de sistemas capaces de integrar de manera sencilla datos semiestructurados heterog´eneos y dispersos de m´ ultiples fuentes accesibles por medios telem´aticos de forma que se obtenga de los mismos una visi´on similar a la proporcionada por una u ´nica base de datos convencional. La idea de este enfoque consiste en ocultar todo tipo de heterogeneidad de cada una de las fuentes de datos accedidas de forma que al usuario se le proporcione una u ´nica visi´on global de todo el sistema y pueda manipular cada uno de los recursos de la red de una forma uniformizada, pese a que cada sistema trabaje en realidad de 22

forma distinta y tenga sus propias particularidades sint´acticas. Los sistemas Datawarehouse, basados en la replicaci´on de informaci´on a un repositorio com´ un [68, 92] usados en entornos cerrados desde hace tiempo, no son adecuadamente escalables para ser usados en el Web. Quiz´a la aproximaci´on arquitectural m´as utilizada hasta el momento para este tipo de sistemas sea la de los sistemas mediadores [79, 101]. En ella, los datos permanecen en sus fuentes originales y un sistema intermedio, llamado mediador, se encarga de proporcionar a lo usuarios la ilusi´on de que existe una u ´nica fuente en la que se encuentran todos los datos combinados y unificados de manera coherente de acuerdo a un u ´nico esquema global. Cuando el mediador recibe una consulta sobre el esquema global, ´esta se reformula en diversas subconsultas que se realizan directamente sobre las fuentes originales. La interacci´on directa con las fuentes es delegada por el mediador a los llamados programas envoltorio (o wrappers), cada uno de ellos especializado en el di´alogo concreto con cada servidor. Estos se encargan de recibir las peticiones del mediador, traducirlas como subconsultas ajustadas al formato particular de cada fuente, ejecutarlas sobre la misma y obtener los resultados, devolvi´endoselos al mediador. Es entonces cuando los resultados de las fuentes son reestructurados por el mediador para ajustarse al esquema global y ser devueltos entonces al usuario. De esta manera, ´este obtiene la impresi´on de estar consultando un u ´nico sistema. Este esquema se encuentra representado en la figura 1.1.

Figura 1.1: Sistema mediador La motivaci´on de la construcci´on de este tipo de sistemas se encuentra tanto en los planes estrat´egicos a nivel corporativo dentro de una organizaci´on, 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 informaci´on enorme, que es dif´ıcil de gestionar, y a la que es complicado, cuando no imposible, sacar el m´aximo partido. Por otro lado, diversos factores, como la r´apida evoluci´on tecnol´ogica, las presiones del mercado o el efecto de la competencia entre diferentes proveedores de soluciones t´ecnicas, han causado que los entornos y las tecnolog´ıas utilizadas para la generaci´on y manejo de estos datos difiera en gran medida a lo largo del tiempo, creando as´ı, a lo largo de los u ´ltimos a˜ nos, un escenario donde grandes vol´ umenes de informaci´on se encuentra dispersa en fuentes independientes y heterog´eneas, cuyos datos necesitan ahora m´as que nunca ser combinados y unificados. Son muchas las organizaciones que est´an desarrollando o tienen planes de desarrollar sistemas capaces de proporcionar visiones unificadas de los datos manejados por la organizaci´on. Los problemas a los que los sistemas mediadores se han venido enfrentando en los u ´ltimos a˜ nos son extrapolables a la realizaci´on de muchas tareas en el Web. Muchos de las aplicaciones construidas en las intranets de los sistemas corporativos a lo largo de los u ´ltimos a˜ nos han sido creadas con interfaces para el Web. Es por ello que los sistemas mediadores se han visto u ´ltimamente cada vez m´as abocados a la automatizaci´on de tareas en las aplicaciones de las intranets de estas corporaciones. A pesar de que el n´ umero de posibles tareas automatizables en el Web es mayor que las realizables en las intranets de las aplicaciones corporativas, los sistemas mediadores, impulsados por las necesidades de estas corporaciones, no han dejado de ser un importante exponente de la necesidad de automatizar el tratamiento de datos obtenible de aplicaciones accesibles desde el Web.

1.3.6.

Asistentes de navegaci´ on Web

Para automatizar tareas en el Web se necesitan programas capaces de eliminar la necesidad de que el usuario deba interactuar incansablemente con el ordenador durante la ejecuci´on de la tarea. En lugar de solicitar que, durante la navegaci´on, el usuario active el seguimiento de cada enlace que se desea visitar, se deben preprogramar todas esas activaciones en un algoritmo, de forma que queden as´ı expl´ıcitamente la selecci´on preaprobada de los enlaces que se seguir´an durante la ejecuci´on de la tarea. El resultado de ese algoritmo normalmente consistir´a en presentarle al usuario s´olo los datos (resultados, confirmaciones, ...) que a ´este le interesan, evitando, en lo posible, mostrarle toda aquella informaci´on irrelevante para su tarea. El programa capaz de automatizar de esta forma las tareas del usuario conforme a sus intereses se denomina asistente de navegaci´ on Web. En la figura 1.2 aparece es24

quematizada la diferencia entre la tradicional navegaci´on manual basada en browsers y la navegaci´on basada en asistentes de navegaci´on Web. Con un asistente de navegaci´on Web, se persigue sustituir al browser y al usuario que lo maneja por un u ´nico programa capaz de automatizar una tarea de forma que los servidores Web involucrados presten a la aplicaci´on el mismo servicio que prestar´ıan a un usuario que realizara esa tarea con un browser.

Figura 1.2: Comparaci´on de navegaci´on manual con autom´atica

1.4.

Caracter´ısticas de los datos del Web

Para procesar datos automatizadamente hay que tener en cuenta las principales caracter´ısticas de los datos cuyo tratamiento se pretende automatizar. A continuaci´on se presentan algunas de las principales caracter´ısticas de los datos del Web.

1.4.1.

Voluminosidad

En las u ´ltimas d´ecadas las nuevas tecnolog´ıas han permitido la creaci´on, recopilaci´on y publicaci´on de grandes vol´ umenes de informaci´on accesible en una amplia diversidad de formatos y mediante una amplia gama de medios de acceso telem´aticos. Por otra parte, muchas aplicaciones ya existentes en las intranets de muchas organizaciones han sido reconvertidas para poder ser accedidas ahora desde el Web, mediante un mayor n´ umero de terminales. Esto ha llevado, por otra parte, a la aparici´on de un gran n´ umero de aplicaciones que, siendo accesibles desde cualquier punto del planeta mediante el Web, a trav´es de sus interfaces basadas en formularios, proporcionan al Web una enorme cantidad de informaci´on para la que no existen apenas medios adecuados de manipulaci´on. 25

1.4.2.

Heterogeneidad

El Web es un ente tremendamente heterog´eneo, lo cual ha implicado una gran dificultad a la hora de manejar adecuadamente los grandes vol´ umenes de informaci´on dispersa en el Web. La proliferaci´on de fuentes de informaci´on desarrolladas de forma totalmente independiente unas respecto de las otras ha llevado a un escenario en el que mucha informaci´on potencialmente u ´til para las necesidades particulares de muchos usuarios est´e dispersa y almacenada seg´ un esquemas y estructuras de almacenamiento con grandes heterogeneidades. Debido a la intr´ınseca naturaleza abierta en el Web, los contenidos de la misma se muestran d´ebilmente estructurados y, cuando lo est´an, su esquema es enormemente heterog´eneo, presenta irregularidades, y sigue muy pocas restricciones. Otra peculiaridad del Web actual es el hecho de que la inmensa mayor´ıa de su informaci´on es legible para las personas, pero no lo es para las m´aquinas, por lo que su tratamiento automatizado se encuentra con importantes problemas. La heterogeneidad de las Webs de las empresas supone a´ un mayores problemas cuando se las pretende interconectar con las de sus clientes o proveedores u otros canales de comercializaci´on.

1.4.3.

Orientaci´ on a los visualizaci´ on

Una de las grandes barreras a la automatizaci´on en el Web actual (no tanto por los principios en los que se fund´o, sino por el uso que se le ha ido dando despu´es) es que est´a muy orientado a la visualizaci´on. La gran mayor´ıa de los dise˜ nadores no han concebido sus p´aginas para ser procesadas por otro tipo de aplicaciones distintas a los browsers. Es m´as, tampoco resulta extra˜ no que algunos dise˜ nadores hayan concebido sus p´aginas para que sean navegadas exclusivamente desde ciertos browsers concretos, excluyendo, en ocasiones sin saberlo, en otras intencionadamente, la navegaci´on de otros tipos de programas como las que aparecen en la tabla 1.2. La actual orientaci´on a la visualizaci´on en el Web no es un problema en s´ı mismo para la accesibilidad si esa orientaci´on est´a basada en hojas de estilo. Sin embargo, quiz´a porque las hojas de estilo nacieron algo m´as tarde que el propio Web y a´ un no tienen un soporte completo en muchas herramientas, tradicionalmente las p´aginas han reflejado su orientaci´on a la visualizaci´on en el propio marcado HTML de sus p´aginas. La gran mayor´ıa de los sitios Web actuales centran a´ un el uso de su marcado HTML en aspectos primordialmente visuales (tama˜ nos y tipos de letra, colores, alineamientos, espaciados, distribuci´on por la pantalla, im´agenes, ...), muchos de ellos enfocados para impactar visualmente al usuario que use uno de los browsers 26

gr´aficos admitidos por el dise˜ nador del sitio Web. A pesar de que iniciativas como las de las hojas de estilo CSS bien permiten independizar a HTML de esa orientaci´on a la visualizaci´on, buena parte del marcado HTML que se usa en las p´aginas de millones de aplicaciones accesibles desde el Web, creadas a lo largo de los u ´ltimos a˜ nos, est´a a´ un orientado a estos fines. As´ı, en lugar de un Web en la que cualquier p´agina HTML pueda ser navegable desde cualquier browser y dispositivo de acceso, donde las distintas peculiaridades de cada uno est´en contempladas en distintas hojas de estilo, cada una de ellas adaptada a un tipo distinto de terminal, el Web actual adolece de un grave problema de orientaci´on a un reducido n´ umero de browsers, puesto que los usuarios que utilizan otros tipos de programas de acceso distinto a esos browsers, no tienen un adecuado acceso a los contenidos que desean visitar. Para muchos usuarios, son muchas las p´aginas inaccesibles, donde determinados contenidos dejan de ser visibles y muchas aplicaciones accesibles desde el Web dejan de ser funcionales simplemente por el hecho de que se acceda a ellas con browsers no considerados por el dise˜ nador del sitio Web. Por ejemplo, resulta habitual el hecho de que se visualicen enlaces que sin embargo no se pueden pulsar (tienen una capa invisible encima que lo impide), textos que quedan ilegibles por aparecer superpuestos unos sobre otros, o incluso servidores que, siendo en realidad visitables, discriminan seg´ un el agente de usuario empleado y acaban redirigiendo a la portada del Web o a una p´agina de error en la correspondiente respuesta a toda petici´on en la que no se acompa˜ ne la identificaci´on del browser esperado en ese Web. En muchos sitios, la navegaci´on basada en browsers sobre terminales tipo texto, como Lynx [10] resulta impracticable. Incluso la navegaci´on basada en browsers gr´aficos resulta impracticable en muchos sitios Web si no se tiene activada alguna funcionalidad especial que el dise˜ nador del sitio Web consider´o como necesaria, como son las cookies, las rutinas JavaScript [74], las im´agenes, o las animaciones en Flash u otros formatos. A ello hay que a˜ nadir la escasez pr´actica de descriptores textuales adecuados en numerosos componentes de las p´aginas, como los scripts, los applets, los plugins, los frames o los controles ActiveX, muchos de los cuales s´olo resultan funcionales en determinados browsers, pero no en otras aplicaciones.

Accesibilidad Iniciativas de mejora para la accesibilidad, como las publicadas por el W3C en sus recomendaciones [128, 137, 136], est´an encontrando u ´ltimamen27

te un decidido apoyo en numerosas personas e instituciones para conseguir que el acceso a los contenidos Web sea funcional con independencia de cual sea la plataforma de acceso, tanto hardware como software. Estas recomendaciones u ´ltimamente hacen especial hincapi´e en poco costosas, pero efectivas mejoras de acceso al Web por parte de, tanto browsers espec´ıficos usados por personas discapacitadas, como los recientes terminales inal´ambricos con pantallas de reducidas dimensiones y escasa capacidad de procesamiento o ancho de banda limitado, tales como tel´efonos m´oviles, asistentes personales o peque˜ nos electrodom´esticos. La correcta operatividad con independencia del browser utilizado o del dispositivo de acceso escogido es una de las gran´ des necesidades del Web actual. Ultimamente, el cada vez mayor n´ umero de formas de acceso ha puesto a´ un m´as de manifiesto el serio problema de accesibilidad existente en el Web, como lo demuestra el hecho de que los nuevos dispositivos sean incapaces de acceder adecuadamente a las p´aginas del Web legado. Este problema ha permanecido disimulado por el importante dominio de Microsoft Internet Explorer como browser m´as utilizado en los u ´ltimos a˜ nos. No obstante, numerosas iniciativas de mejora, como las del W3C y otras [109, 106, 96, 121] han sido propuestas para aportar soluciones. Dentro de las recomendaciones del W3C se enumeran varios tipos de programas de navegaci´on, mucho m´as all´a de los habituales browsers gr´aficos. El objetivo de estas recomendaciones es la de permitir el correcto acceso al Web desde terminales en modo texto, software espec´ıfico de navegaci´on para personas con visi´on discapacitada que presentan al usuario las p´aginas en Braille o en audio, as´ı como desde terminales de reducidas dimensiones, con peque˜ nos displays como los cada vez m´as habituales dispositivos inal´ambricos, y muchos m´as. El objetivo principal de estas iniciativas consiste en que las p´aginas publicadas en el Web sean accesibles a sus usuarios independientemente del dispositivo de acceso empleado por cada uno de ellos. Una de las ideas principales de estas iniciativas de mejora consiste en reducir al m´ınimo el uso del marcado HTML que est´e orientado a la visualizaci´on, delegando esa tarea en las hojas de estilo y simplificando as´ı el marcado estructural de las p´aginas. En la tabla 1.4 pueden contemplarse las principales diferencias entre las distintas versiones de HTML surgidas en los u ´ltimos tiempos, desde los puntos de vista de la orientaci´on a la visualizaci´on y a la accesibilidad.

Resulta curioso destacar en este punto c´omo los sitios Web que m´as ´exito han cosechado en los u ´ltimos tiempos (Google, Yahoo, eBay, EasyJet ...) suelen tener como caracter´ıstica com´ un el hecho de que no hacen apenas 28

HE = Hojas de estilo

HTML sin HE

HTML con HE

XHTML o XML

Orientaci´ on a la visualizaci´ on

En HTML

En hoja de estilo

En hoja de estilo

Accesibilidad por terminales

Baja

Media

Alta

Regularidad estructural

Orientaci´ on visual

Sencilla

Sencilla

Modificaciones en la estructura

Habituales

Escasas

´Infimas

Reglas de construcci´ on

B´ asicas

B´ asicas

Tipo de documento

Automatizaci´ on de tareas

Dif´ıcil

Media

F´ acil

Difusi´ on relativa en el Web

Alta

Baja

Muy baja

Cuadro 1.4: Principales diferencias entre las u ´ltimas versiones de HTML uso de tecnolog´ıas que mermen la accesibilidad de sus p´aginas. Sin embargo, la escasa implantaci´on pr´actica de las normas y recomendaciones del W3C durante muchos a˜ nos hace prever que la transici´on hacia un Web accesible para browsers de distintos terminales ser´a a´ un lenta, en cuanto a la inercia del Web est´a asentada en su gran tama˜ no y en la tradicional escasa orientaci´on de dise˜ nadores y herramientas a estos aspectos. La orientaci´on del Web a los browsers como u ´nicas herramientas de acceso es la raz´on de que el Web sea a´ un muy abundante en p´aginas que no s´olo no cumplen las reglas de la recomendaci´on oficial de XHTML, sino que ni tan siquiera cumplen muchas de las reglas de las recomendaciones anteriores de HTML.

1.4.4.

Relevancia dependiente de la tarea

Por datos relevantes se debe entender, no s´olo aquella informaci´on espec´ıfica que est´a siendo buscada y que forma parte de los resultados que, quiz´a tras alg´ un procesamiento, se le deben proporcionar al usuario al finalizar la tarea, sino, en general, todos aquellos datos que puedan ser utilizables en alg´ un momento dentro de ese proceso de navegaci´on. Ejemplos de datos relevantes son las direcciones de las p´aginas que se deben visitar, los campos de formularios que se deben rellenar, o quiz´a incluso simples campos que aparecen en las p´aginas en funci´on de cuyos valores se puede tomar la decisi´on de seguir uno u otro enlace o efectuar una u otra acci´on definible por el usuario. No toda la informaci´on de cada p´agina Web es igualmente relevante. Es com´ un que, para una tarea particular, de una sola p´agina apenas interese un dato, un determinado enlace o un formulario concreto y los dem´as datos de la p´agina puedan ser felizmente ignorados. La relevancia de cada informaci´on, por otra parte, no se puede considerar en t´erminos absolutos. La relevancia de un dato depende de la tarea concreta que se desee realizar, es decir, de los objetivos por los cuales la p´agina que contiene el dato ha sido consultada. 29

Por ejemplo, dentro de un mismo documento, para una tarea concreta, puede ser interesante un enlace, mientras que para otra tarea, puede serlo otro enlace completamente distinto. Para ciertas personas, determinada informaci´on puede ser considerada como relevante, mientras que, para otras, pese a que tengan prop´ositos similares, esa misma informaci´on puede no serlo. En cualquier caso, dicha informaci´on, relevante o no, es presentada al usuario t´ıpicamente embebida en p´aginas Web que, estando escritas en HTML para su visualizaci´on en browsers, no est´an, sin embargo, orientadas para ser procesadas por otro tipo de aplicaciones capaces de manipular esa informaci´on autom´aticamente. Es decir, las p´aginas HTML est´an construidas para ser visualizadas, pero no para ser comprendidas por m´aquinas. El problema de la integraci´on de datos del Web en aplicaciones, esto es, de su automatizaci´on, ha sido abordado de manera muy activa por investigadores de diferentes comunidades y disciplinas, tales como la Telem´atica, la Miner´ıa de Datos o la Inteligencia Artificial, realiz´andose en los u ´ltimos a˜ nos importantes contribuciones desde diferentes puntos de vista.

1.4.5.

Regularidad estructural

Las bases de datos, que almacenan su informaci´on de forma estructurada, al volcar sus contenidos en p´aginas Web, suelen conservar en ese volcado cierta regularidad, denominada estructural, en el marcado HTML de los datos volcados. Distintos datos conviviendo bajo la misma f´errea estructura de una base de datos acaban siendo volcados al Web con similares etiquetas HTML, por lo que conservan una cierta regularidad estructural en sus marcados. Un ejemplo de ello puede verse en la figura 1.3, donde se muestra parte del c´odigo de una p´agina Web que contiene los resultados de una b´ usqueda en Google. El hecho de que exista una regularidad estructural en las p´aginas HTML publicadas en un mismo servicio (aplicaci´on accesible desde el Web o conjunto de p´aginas l´ogicamente enlazadas para un fin com´ un y publicadas bajo una misma estructura) tiene un inmenso valor para la extracci´on de datos del Web. La regularidad estructural puede ser usada para identificar unos datos respecto de otros. Sin embargo, el hecho de que dicha estructura no sea expl´ıcita (como s´ı lo es el esquema de una base de datos), sino impl´ıcita, permite que los sitios Web puedan cambiar en cualquier momento sus estructuras de marcado HTML sin apenas contemplaciones. Adem´as, la estructura supuestamente regular de los sitios Web puede presentar irregularidades con frecuencia. Por ejemplo, es habitual que en el cat´alogo electr´onico de una tienda 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 acompa˜ nados adem´as de un indicativo promocional de oferta, que otros art´ıculos no poseen. Es precisamente la posibilidad que HTML ofrece para realizar m´ ultiples y flexibles 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 heterog´eneo a simple vista, pese a que los principios de su funcionamiento sean en realidad sencillos. Es precisamente esa combinaci´on de sencillez y flexibilidad, carentes en el mundo de las bases de datos, una de las principales razones que han encumbrado a HTML como el formato por excelencia de los documentos en el Web. Reconocer esta regularidad estructural en una p´agina permite extraer sus datos relevantes. Existe una gran necesidad actualmente de aplicaciones que puedan integrar la informaci´on semiestructurada de varias fuentes diversas preexistentes. La heterogeneidad de la forma de marcar datos en cada fuente hace necesario muchas veces un pretratamiento particularizado consistente en adaptar los datos provenientes de diversas fuentes a un formato com´ un. Una vez estructurados todos los datos en un formato com´ un, ´estos pueden ser procesados adecuadamente sin tener en cuenta su procedencia. Esto suele ser necesario en procesos de integraci´on de informaci´on proveniente de distintos servidores cuya forma de acceso no es posible que sea modificada. Ello 31

suele ocurrir muchas veces en el Web en general, o, a menor escala, en los servidores localizados en la intranet de una empresa, donde es primordial que los sistemas sigan funcionando para las personas y herramientas que los llevan usando sin necesidad de ser interferidos por el hecho de que una nueva herramienta de acceso se incorpore al sistema inform´atico preexistente.

1.4.6.

Ausencia de sem´ antica en el marcado

Cualquier dato que aparezca en una p´agina HTML no puede distinguirse f´acilmente de forma automatizada. Por ejemplo, un dato num´erico, no puede reconocerse f´acilmente como un precio, una cantidad, una fecha o un n´ umero de referencia por la sencilla raz´on de que en el marcado HTML del Web actual no se distingue entre unos tipos de datos respecto de otros. Por otro lado, pr´acticamente casi cualquier combinaci´on de etiquetas HTML puede usarse indistintamente para marcar unos datos u otros, raz´on por la que acaba siendo el usuario quien, aplicando sus conocimientos contextuales en la navegaci´on, infiere la sem´antica de esos datos al visualizarlos en la pantalla. Esto es algo que ocurre cuando se navega con un browser. En la navegaci´on manual se debe tomar muchas veces la decisi´on de pulsar en uno u otro enlace o la de rellenar un formulario en lugar de otro, o la de rellenar cierto campo de una forma en lugar de cierta otra dependiendo de los datos visualizados hasta el momento en la pantalla, pero que el ordenador no es capaz de distinguir respecto del resto de los datos visualizados porque HTML es un lenguaje de marcado poco orientado a la descripci´on sem´antica y con un uso muy orientado a la visualizaci´on.

1.4.7.

Niveles de estructuraci´ on

Tradicionalmente, en el campo de la documentaci´on, se ha distinguido entre datos estructurados y datos no estructurados. Los datos no estructurados son aquellos que no presentan ning´ un esquema o estructura m´as all´a de la mera secuencia de bytes o palabras. Los datos estructurados son aquellos que siguen un esquema de datos perfectamente definido (e.g. aquellos contenidos en bases de datos). El esquema que define la estructura de un conjunto de datos estructurados suele incluir f´erreas restricciones sobre los mismos, tales como un fuerte tipado de datos, restricciones en los rangos posibles de valores admitidos para ciertos datos, unicidad, cardinalidad de las repeticiones, limitaciones en el tama˜ no o posibilidad de impedir la existencia de campos con valores nulos. 32

Datos no estructurados Un ejemplo t´ıpico de datos no estructurados son los textos libres. Debido a su escasa o pr´acticamente nula estructura, la u ´nica manera posible de recuperar informaci´on de estos documentos es mediante consultas no estructuradas o imprecisas, tales como las b´ usquedas por palabra clave. Con este tipo de consultas s´olo es posible representar expresiones que recuperen aquellos documentos en los que aparece el conjunto de palabras clave buscadas. Es habitual en este tipo de consultas la posibilidad de utilizar operadores l´ogicos para combinar expresiones simples. B´asicamente, ´este es el sistema de datos en el que se basan los buscadores de Internet como Google o Altavista. Si bien este tipo de consultas son sencillas de realizar y existe un gran n´ umero de trabajos e importantes contribuciones a este respecto [28], lo habitual es que este tipo de soluciones trabajen con un nivel de granularidad demasiado grueso (el documento), frente a lo que muchas veces en realidad se necesita (el dato). Los muy bien conocidos buscadores como Google o Altavista consideran el Web como un gran repositorio de informaci´on no estructurada y son capaces de construir gigantescos ´ındices sobre el Web, permitiendo su consulta de forma eficiente. Sin embargo, para un cada vez mayor n´ umero de usuarios que encuentran la necesidad de realizar consultas m´as especializadas, esta abstracci´on del Web como un conjunto de informaci´on no estructurada es demasiado d´ebil, ya que, a fin de cuentas, no sirven para nada m´as que para localizar documentos que tengan las palabras consultadas, no para obtener el dato en s´ı que en realidad buscan, ni tampoco para automatizar el uso de aplicaciones manejables desde formularios.

Datos estructurados Los datos estructurados son aquellos que presentan un esquema r´ıgido y bien definido para los datos. Un ejemplo t´ıpico de fuente estructurada de datos son las bases de datos relacionales. En este caso existe un diccionario de datos que define la organizaci´on interna y las restricciones de los datos, as´ı como de las relaciones entre los mismos. Cuando los datos se encuentran en forma estructurada, es posible realizar consultas precisas mediante lenguajes de consulta estructurados, de los cuales el m´as popular es SQL [78]. Esta precisi´on a la hora de hacer consultas hace que los datos estructurados sean muy adecuados para su tratamiento por programas de ordenador. 33

Datos semiestructurados Al contrario de los datos estructurados, los datos del Web carecen de todas estas restricciones y pertenecen a una categor´ıa distinta. Esa categor´ıa de datos ha recibido el nombre de datos semi-estructurados [36]. Los datos semiestructurados se caracterizan porque, aunque siguen alg´ un tipo de esquema, el seguimiento que hacen del mismo es mucho menos r´ıgido que en el caso de los datos estructurados. Seg´ un [60], las principales caracter´ısticas de los datos semiestructurados son: El esquema de datos no es expl´ıcito, esto es, no es conocido de antemano. Puede existir, pero estar´a, en todo caso, impl´ıcito en los datos y cualquier restricci´on asumible de ese esquema deber´a inferirse de ellos de alguna manera. El esquema de datos est´a sujeto a cambios y puede cambiar con frecuencia. No existen impedimentos para que esto pueda ocurrir en cualquier momento. El esquema tolera irregularidades que no siempre aparecen especificadas. No existe un tipado fuerte de los datos individuales, por lo que es posible encontrar en ocasiones valores de tipos diferentes a los esperados. Por ejemplo, para un mismo tipo de dato consultado, es posible que ´este aparezca en varios formatos distintos. Sin tener la programabilidad de una f´errea base de datos en la que es f´acil asumir decisiones sem´anticas acerca de los datos, su bajo coste de creaci´on las ha convertido en poco tiempo en la alternativa usada por excelencia para la publicaci´on de datos en el Web. Sin embargo, la gran mayor´ıa de la informaci´on accesible por el Web no presenta un nivel de estructuraci´on tan fuerte, pese a que ser´ıa deseable poder manipularla eficazmente. En muchas ocasiones, especialmente en el caso de bases de datos accesibles desde el Web, la estructura de marcado HTML en la que esos datos se ven incrustados hace perder f´acilmente la visi´on de esa estructura f´errea. HTML es un buen formato para ser visualizado en navegadores. Sin embargo, su estructura no est´a orientada a la descripci´on de los datos, sino a su visualizaci´on. T´engase en cuenta, que en el proceso de transformaci´on de la informaci´on desde repositorios estructurados a formatos visualizables, se produce una p´erdida de estructuraci´on que, a lo largo de los u ´ltimos a˜ nos, las diversas aplicaciones 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 contenidos inmanejables eficazmente, cuando los m´etodos para reestructurar la informaci´on del Web son m´as necesarios. HTML es el lenguaje de marcado en el que se encuentran embebidos mayoritariamente los datos del Web. Apenas los Web Services [53] y unos pocos y marginales (comparativamente con el inmenso tama˜ no del Web) segmentos de negocio usan XML como formato de intercambio de datos. Algunos m´as son los sitios que aparecen publicados en XHTML [117]. Muy al contrario de los documentos XML, las p´aginas HTML se caracterizan porque su estructuraci´on est´a atada a muy pocas reglas. La gran mayor´ıa de ellas son reglas elementales de construcci´on, sin que las reglas l´ogicas de estructuraci´on propias del ´ambito de conocimiento del documento queden bien reflejadas en su marcado estructural. Este marcado, por el contrario, s´ı suele contener una elevada carga de aspectos orientados a la visualizaci´on. Esta d´ebil estructuraci´on de las p´aginas puede ser cambiada f´acilmente en cualquier momento, pues no existe un esquema de datos expl´ıcito que deba regir la estructura de las p´aginas. Por todos estos motivos, los documentos HTML pueden ser considerados como datos semiestructurados. La tabla 1.5 presenta un resumen de las principales diferencias entre las caracter´ısticas de los datos seg´ un sus distintos niveles de estructuraci´on. Datos no estructurados

Datos estructurados

Datos semi estructurados

Esquema de datos

Inexistente

Expl´ıcito

Impl´ıcito

Restricciones

Inexistentes

F´ erreas

Laxas

Irregularidades

Inexistentes

Prohibidas

Abundantes

Cambios de estructura

Inexistentes

Prohibidos

Habituales

Consultas

Imprecisas

Precisas

Poco precisas

Ejemplo

Texto plano

Base de datos

P´ agina Web

Coste de creaci´ on

Bajo

Alto

Bajo

Uso

Medio

Bajo

Muy alto

Cuadro 1.5: Diferencias entre caracter´ısticas de los datos seg´ un su nivel de estructuraci´on

1.4.8.

Distribuci´ on de la informaci´ on

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

aparecer distribuidos en varios de ellos por cuestiones organizativas. As´ı pues, informaci´on que necesita ser combinada para realizar una tarea puede encontrarse distribuida de muy diversas formas: Entre los documentos de diversos sitios Web, como por ejemplo informaciones complementarias de restaurantes en distintos portales de ocio. Entre los documentos individuales integrantes de otros documentos multimedia, como por ejemplo las diversas p´aginas que formen un mismo frameset. Entre diversas p´aginas enlazadas entre s´ı, como por ejemplo, los derivados de la paginaci´on de resultados de b´ usqueda. Mezclada dentro de una misma p´agina con informaci´on no relevante para la tarea, como por ejemplo, la publicidad y otras informaciones no relevantes para la tarea.

1.4.9.

Dif´ıcil modificabilidad

Los programas creados para navegar autom´aticamente en el Web, deben, por lo tanto, afrontar el problema del manejo de informaci´on semiestructurada, corriendo el peligro de ver modificada, sin previo aviso, la estructura de las p´aginas que se desea visitar. En el caso de la integraci´on de aplicaciones accesibles desde el Web, ´estas deben ser tratadas con sumo cuidado y respeto para no interferir en el correcto funcionamiento de las tareas realizadas por otros mecanismos, t´ıpicamente browsers, que otros usuarios est´en llevando a cabo. La mejor forma de integrar estas aplicaciones legadas suele consistir, no en modificarlas para que contemplen una nueva herramienta de acceso, sino en usar las interfaces que ya tengan desarrolladas, t´ıpicamente formularios en formato HTML, creando herramientas que emulen las herramientas de acceso preexistentes que hasta el momento han estado siendo usadas. En muchas ocasiones ello supone, si no un serio ahorro de costes, la u ´nica opci´on aplicable.

1.4.10.

Aportaciones de XML

XML [132], concebido como una tecnolog´ıa para definir lenguajes de marcado propios para cada campo del conocimiento, aporta numerosas y significativas soluciones a la hora de estructurar los documentos de una forma 36

mucho m´as clara que la manera en la que HTML lo permite actualmente. Gracias a su mayor expresividad, y a su facilidad para ser procesado por programas no orientados a la mera visualizaci´on, el uso de XML se ha extendido r´apidamente como soluci´on al intercambio de datos estructurados en muy diversos ´ambitos. Las principales cualidades de los documentos XML son las siguientes: Sintaxis f´ acilmente procesable XML presenta una sintaxis textual muy simplificada que permite estructurar f´acilmente los documentos en forma de ´arbol. Al contrario de su predecesor SGML [65], los programas que procesan XML pueden ser muy f´acilmente construibles debido a la simplicidad del formato, algo que sin embargo no le resta flexibilidad y extensibilidad para poder definir documentos complejos. Independencia de la presentaci´ on XML permite dotar f´acilmente a los documentos de una estructura sint´actica que est´e adecuada a la naturaleza propia del documento, prescindiendo absolutamente de la forma en la que ´este pueda ser visualizado, labor que queda delegada en las hojas de estilo. Estructuraci´ on de datos Las etiquetas XML no definen propiedades acerca de c´omo deben ser visualizadas, sino que simplemente describen los datos que contienen. Con el fin de dar una descripci´on formal a los posibles contenidos que puede tener una etiqueta dentro de un documento, XML incluye la posibilidad opcional de describir esas sintaxis mediante los DTD o XML Schema. Contexto sem´ antico Algo que no forma parte de la especificaci´on de XML y para lo que a´ un no se ha definido formato estandarizado de representaci´on es el contexto sem´ antico. Mediante un contexto sem´antico capaz de dotar de significados a cada una de las partes de esa estructuraci´on sint´actica (etiquetas y atributos XML), es posible as´ı que cada uno de los datos que aparecen en un 37

documento pueda tener significado sem´antico para los usuarios. De esta forma, las distintas partes de los documentos pueden presentar un significado conocido y sin ambig¨ uedades, adecuado para ser entendible por las m´aquinas, algo que las p´aginas HTML que forman parte del Web actual no cumplen, pues est´an orientadas a la mera visualizaci´on. La tabla 1.6 refleja un resumen de las aportaciones que realiza cada una de las tecnolog´ıas mencionadas en este p´arrafo a los documentos estructurados en XML. Tecnolog´ıa

Aporta

Finalidad

Herramientas

XML

Sintaxis

Datos descritos

DTD, Schema, Relax-NG, ...

Hojas de estilo

Presentaci´ on

Documentos presentables

CSS, XSL, ...

Contexto sem´ antico

Sem´ antica

Documentos procesables

Metadatos RDF/OWL, programas ...

Cuadro 1.6: Resumen de aportaciones de XML

Sin embargo, siendo XML una buena opci´on, lamentablemente a´ un no es usada masivamente en el Web. Para ello resulta necesario un cierto consenso a la hora de escoger el lenguaje concreto de entre los m´ ultiples lenguajes existentes de un dominio de conocimiento para marcar adecuadamente los contenidos. Por otro lado, lo cierto es que XML apenas resuelve una parte del problema: la de la estructuraci´on de los documentos y la posibilidad de asociar, gracias a un contexto que suele estar impl´ıcito en las personas, significados sem´anticos a cada una de esas partes estructuradas del documento. Sin embargo, XML no realiza aportaciones a la forma en la que esos documentos deben ser obtenidos de las fuentes de datos, algo que normalmente no se puede conseguir en un solo paso. Sin embargo, al igual que ocurre con la orientaci´on a la accesibilidad e independencia del dispositivo de acceso, son numerosos los inconvenientes que permiten augurar que XML a´ un tardar´a mucho tiempo en ser una soluci´on efectiva. Entre esos inconvenientes cabe destacar los siguientes: El uso de XML directamente en los browsers, como mero formato de visualizaci´on, acompa˜ nado, eso s´ı, de sus correspondientes hojas de estilo, no aporta ventajas sobre otros formatos para los que ya existen browsers, como HTML. El ya gigantesco tama˜ no del Web supone sin duda una gran inercia a la hora de acoger nuevas tecnolog´ıas. Ello implica que, aunque en determinado momento, XML pase por fin a ser la soluci´on com´ unmente 38

aceptada por los servidores Web, la lentitud con la que se reajustar´an las p´aginas de los servidores Web ya existentes implicar´a que el acceso a sitios Web basados en HTML seguir´a siendo necesario durante mucho tiempo. Y a´ un as´ı, no es previsible tampoco que HTML llegue a desaparecer por XML, por lo que habr´a un gran n´ umero de aplicaciones que no migrar´an a XML. En cualquier caso, en la actualidad, tras cuatro a˜ nos despu´es del nacimiento de XML, ´este apenas se encuentra usado en unos pocos segmentos verticales de negocio, de una forma marginal si se lo compara con HTML. El hecho de que las especificaciones del W3C que parecen prometer nuevas soluciones est´en a´ un en fase de borrador supone un serio inconveniente para ser adoptadas por los desarrolladores, que las contemplan a´ un con muchas reticencias.

1.5.

Coste de la navegaci´ on automatizada

Uno de los aspectos m´as curiosos para la automatizaci´on de tareas en el Web es que la mayor´ıa de las mejoras de accesibilidad mencionadas en el apartado 1.4.3 en lo referente a la independencia de dispositivos de acceso en la navegaci´on con browsers, son tambi´en directamente aprovechables para otras aplicaciones que no son browsers, como las de navegaci´on autom´atica. Un marcado poco orientado a los aspectos de visualizaci´on, que delegue esa labor en hojas de estilo, independiente del dispositivo de acceso, y cercano a la estructura l´ogica del documento, es m´as simple y regular y menos proclive a ser modificado con el tiempo, pues ser´an las hojas de estilo quienes asuman los cambios de presentaci´on. Ello redunda en una importante minimizaci´on de costes, tanto de publicaci´on en el lado del servidor como de procesamiento en el cliente que manipule las p´aginas obtenidas del servidor. En el lado del servidor, la opci´on de mantener documentos accesibles, cada uno de ellos visualizable con varias hojas de estilo alternativas, cada una de ellas a su vez orientada a un dispositivo de acceso, ser´a sin duda mucho m´as econ´omica (en tiempo, espacio y esfuerzo a largo plazo) y escalable que la de mantener para cada p´agina una versi´on orientada a cada terminal. En el lado del cliente, la simplicidad del marcado de las p´aginas accesibles reduce sensiblemente la complejidad de procesamiento. Esto tiene especial importancia en las reglas de extracci´on de datos basadas en la regularidad estructural de las p´aginas. Al ser esta regularidad estructural m´as simple y m´as estable, estas reglas ser´an a su vez m´as simples y estables, por lo que 39

necesitar´an un menor esfuerzo de desarrollo y de mantenimiento. Las aplicaciones capaces de navegar en el Web que aparecen en el apartado 1.3 pueden, sin duda, ser construidas desde varias plataformas basadas en distintos lenguajes de programaci´on. Desde C, Java, Perl, TCL-TK, Prolog, Visual Basic hasta el mismo ensamblador, cualquiera de estos lenguajes puede ser usado en la construcci´on de estos sistemas, habida cuenta de la existencia de varias bibliotecas de soporte utilizables en cada uno de estos lenguajes, como las mencionadas en el apartado 3.4. Sin embargo, no todas las alternativas presentan la misma flexibilidad para cada labor, ni tampoco tienen los mismos costes, soliendo haber unos lenguajes m´as orientados que otros para cada tipo de labor. Para minimizar los costes, es necesario que la plataforma de ejecuci´on proporcione un buen soporte al acceso de datos en el Web por el protocolo HTTP, emulando lo m´as parecidamente el comportamiento de un browser y ejecutando la mayor cantidad de acciones que impl´ıcitamente ´este ejecuta, algunas de las cuales aparecen en el apartado 2.1, como por ejemplo que ´este sea robusto en los fallos que ocasionalmente ocurren en las comunicaciones (sobrecarga en la conexi´on, tiempo de respuesta excesivo en el servidor, ...), enlaces rotos a componentes del documento, y que permita ubicar f´acilmente los errores cuando ´estos se produzcan, para ayudar a una m´as r´apida reparaci´on del c´odigo de la aplicaci´on. Desde el punto de vista del programador, la plataforma de ejecuci´on debe proporcionarle adem´as un API de desarrollo con el adecuado nivel de abstracci´on, la posibilidad de a˜ nadir sus propias medidas de robustez ante inesperados comportamientos del servidor (p´aginas de error, cambios de regularidad estructural, ...) y, sobre todo, una sencilla forma de definir para fuentes de datos semiestructuradas, reglas de extracci´on de datos, sencillas, potentes y f´aciles de mantener, pues suelen ser la parte que m´as suele sufrir ante los inevitables cambios en la regularidad estructural de las p´aginas. Los costes de la navegaci´on automatizada, que aparecen resumidos en la tabla 1.7, pueden separarse en tres grandes grupos:

Coste

Necesidad

Para programador

Para plataforma

De desarrollo

Buen API

Buen nivel de abstracci´ on

Buen soporte acciones impl´ıcitas

De ejecuci´ on fallida

Robustez

Ante cambios o fallos del servidor

En comunicaciones

De mantenimiento

Bajo coste

Reglas de extracci´ on de datos

Ubicaci´ on de errores

Cuadro 1.7: Resumen de tipos de coste de la navegaci´on automatizada

40

1.5.1.

Coste de desarrollo

El desarrollo de aplicaciones de navegaci´on automatizada debe tener en cuenta las caracter´ısticas de los datos que va a manejar, que se encuentran en el apartado 1.4. El coste de desarrollo depende sin duda de la complejidad de la tarea que se desea automatizar, pero tambi´en es altamente dependiente del API que ofrece la plataforma de desarrollo de estos programas. En general, lo deseable es que este API tenga un completo soporte de las acciones b´asicas impl´ıcitas que aparecen en el apartado 2.1 y que a su vez ese API tenga un buen nivel de abstracci´on para poder facilitar convenientemente la implementaci´on de las acciones b´asicas expl´ıcitas, esto es, los pasos b´asicos de la tarea, detallados en el apartado 2.2. Una ´optima plataforma de desarrollo ser´a aquella que permita detallar cada una de estas acciones con el m´ınimo n´ umero de l´ıneas de c´odigo de alto nivel, entendibles por mucha gente y evitando en la medida de lo posible que sus diferencias con un browser trasciendan al usuario, para garantizar que la parte de la tarea que especifica la recuperaci´on de documentos del Web sea realizada de la forma m´as sencilla posible. Sin embargo, la recuperaci´on de documentos del Web no es m´as que una de las acciones que deben formar parte de la tarea. Tal y como figura en el apartado 2.2, debe procesarse el documento para extraer los datos relevantes que en ´el figuran, estructurarlos, opcionalmente homogeneizarlos en el caso de que puedan proceder de varias fuentes y procesarlos conforme a la tarea que se est´e automatizando. Todas estas acciones deben ser programadas para cada tarea. Sin duda, dado que a fin de cuentas el desarrollo de estos programas es una labor de programaci´on, conviene dotar al programador de las mejores t´ecnicas de reutilizaci´on de c´odigo propias de los lenguajes de alto nivel de abstracci´on, como son la encapsulaci´on en funciones definidas por el usuario y la modularizaci´on de las mismas para que pueda construir sus propias bibliotecas reutilizables por ´el y por otros usuarios. De esta forma puede reducirse igualmente el time to market, es decir, el tiempo de desarrollo y se puede disfrutar m´as f´acilmente de prototipos m´as r´apidamente aplicables. No obstante, una de las principales fuentes de coste de desarrollo de estos programas es la falta de soporte adecuado para muchas acciones ocultas al usuario durante la navegaci´on y que son normalmente ejecutadas por los browsers. Siendo lo ideal que dichas acciones sean llevadas a cabo de forma transparente por estas plataformas para que no trasciendan al usuario, lo habitual es que las actuales plataformas de desarrollo de estos programas proporcionen un soporte bastante incompleto de las mismas, por lo que al final, el programador debe introducir su propio c´odigo para llevar a cabo un 41

sinf´ın de peque˜ nos detalles t´ecnicos de los que los usuarios de los browsers no acaban siendo normalmente conscientes y que aumentan considerablemente la complejidad de la tarea. De esta forma, una peque˜ na y sencilla labor en el Web puede f´acilmente requerir el desarrollo de programas demasiado grandes y complejos que intentan resolver una gran variedad de peque˜ nos detalles t´ecnicos m´as propios de la configuraci´on del servidor que de la propia tarea y que adem´as, al ser tremendamente cambiantes, suponen una importante fuente de futuros fallos de ejecuci´on. El coste de desarrollo queda minimizado con la utilizaci´on de lenguajes de programaci´on con el adecuado nivel de abstracci´on y soporte transparente a los detalles de la navegaci´on. Un lenguaje de programaci´on de alto nivel de abstracci´on, encapsulable, modular, con la posibilidad de definir f´acilmente reglas de extracci´on de datos basadas en la regularidad estructural y con flexibilidad para estructurar esos datos extra´ıdos resulta primordial para reducir los costes de desarrollo de estas aplicaciones.

1.5.2.

Coste de ejecuci´ on fallida

El coste de ejecuci´on fallida es el coste que supone un fallo de ejecuci´on al realizar una tarea. Dicho coste suele depender de la relevancia de la tarea y no ser dependiente de la forma en la que este programa pueda haber sido construido. Este coste, no obstante, puede quedar convenientemente minimizado con la utilizaci´on de medidas capaces de dotar de robustez a la navegaci´on, para que el programa trate de la forma m´as adecuada los comportamientos no esperados de las comunicaciones o del servidor. B´asicamente, para aplicar las medidas de robustez se suele tener en cuenta la ubicaci´on del fallo y el tipo de tratamiento que se desea aplicar. Ubicaci´ on del fallo Fallos en las comunicaciones Las comunicaciones con el protocolo HTTP pueden fallar si existe una sobrecarga en la conexi´on TCP/IP, el servidor al que se intenta conectar est´a inaccesible o su respuesta tarda un tiempo considerado demasiado alto. Este tipo de fallos, normalmente notificados al programador en forma de excepciones o de c´odigos de error, pueden ser convenientemente tratados tanto desde el c´odigo de las bibliotecas de la plataforma de ejecuci´on, como por c´odigo del usuario. Fallos del servidor Las aplicaciones del Web legado no siempre funcionan 42

de la manera en la que de ellas se espera. Ante correctas peticiones de procesamiento de formularios, las aplicaciones del Web pueden funcionar puntualmente de forma incorrecta, devolviendo al cliente p´aginas de error inesperadas por ´este. En estos casos, el error no est´a ni en la aplicaci´on de navegaci´on, ni en la conexi´on TCP/IP, sino en el servidor. Distinguir una p´agina de error (que normalmente ha sido obtenida sin errores desde el punto de vista del protocolo HTTP), de una p´agina que confirme que se han procesado adecuadamente los datos enviados en un formulario, no es algo realizable de forma gen´erica, sino que depender´a de la aplicaci´on y de su forma de devolver p´aginas de error. Aunque otras medidas son posibles, lo habitual suele ser tratar estos errores insertando c´odigo que asevere que la respuesta de una petici´on indique que ´esta ha sido correctamente procesada, t´ıpicamente con una sentencia del tipo assert. No insertar este tipo de comprobaciones puede impedir el tener garantizado que el servidor haya procesado adecuadamente la petici´on recibida. Por otro lado, la p´agina devuelta puede no ser una p´agina de error y contener los datos que espera el cliente, pero puede estar tan mal construida, que no se respeten algunas normas b´asicas de construcci´on de p´aginas necesarias para su correcto procesamiento. En esos casos, lo habitual suele ser corregir internamente los errores de estas p´aginas antes de que sean manipuladas por el programa para que presenten ante el programador una estructura correctamente procesable.

Fallos del cliente por cambios en el servidor Por otro lado, conforme a lo expuesto en el apartado 1.4.7, la regularidad estructural de las p´aginas del servidor puede cambiar en cualquier momento al ser el Web una fuente semiestructurada de datos. Por este motivo, los programas de navegaci´on en el Web suelen incluir c´odigo para detectar los cambios de regularidad estructural en las p´aginas visitadas, de forma que, si ´esta cambia, el programa pueda actuar en consecuencia. Lo habitual suele ser capturar el error y ejecutar reglas secundarias de extracci´on de datos, o bien no capturar el error, propagando excepciones y confiando en que la regularidad estructural no cambie durante mucho tiempo. Dependiendo del grado de robustez que se quiera a˜ nadir a estos programas y del coste asumible por el programador, se puede insertar un n´ umero mayor o menor de reglas secundarias que redunden en una mayor posibilidad de encontrar el dato buscado ante estos posibles cambios. 43

Naturaleza del tratamiento Tratamiento gen´ erico Los tratamientos gen´ericos son aquellos que pueden implementarse para solucionar errores producidos en la navegaci´on con cualquier servidor o aplicaci´on accesible desde el Web. Se trata de fallos que son procesables en las rutinas de las bibliotecas de la plataformas de ejecuci´on y que suelen permitir cierta parametrizaci´on desde el c´odigo del cliente. Ejemplos de estos tratamientos gen´ericos son algunas rutinas existentes, como [104, 58, 146], que permiten reparar la estructura de las p´aginas HTML mal construidas. Otros ejemplos son los temporizadores, que limitan el tiempo m´aximo admisible en el que debe ser resuelta una petici´on en el Web. Tambi´en puede llevarse a cabo una pol´ıtica de reintentos suaves, consistente en reintentar varias veces una petici´on HTTP que no tenga efectos colaterales hasta que sea correctamente procesada, quiz´a con un n´ umero m´aximo de intentos. Se denomina petici´on sin efecto colateral a la que no modifica datos esenciales en el servidor y puede ser realizada m´ ultiples veces sin temor a sufrir efectos colaterales. Una petici´on con efectos colaterales, como por ejemplo una petici´on de transferencia bancaria, no debe ser reintentada m´ ultiples veces, salvo que se asuma el coste de su multiplicidad. Algunas iniciativas como [114] proponen extensiones al protocolo HTTP para que las peticiones con efectos colaterales puedan ser realizadas completamente de forma at´omica, o que, en caso de fallo, no tengan efectos colaterales, pero se trata a´ un de una iniciativa sin estandarizar y carente de soporte en el Web actual. Si todo esto falla, el usuario a´ un puede tratar el error en su c´odigo capturando las excepciones adecuadas o analizando los errores de estas llamadas con el fin de aplicar un tratamiento particularizado. Tratamiento particularizado Los tratamientos particularizados son aquellos que no son aplicables de forma gen´erica en bibliotecas, sino que, al depender de las aplicaciones concretas que est´en involucradas en la tarea, son mejor tratables en el c´odigo del programador (por lo que su coste es tambi´en m´as elevado). Son m´ ultiples las acciones de tratamiento que puede emprender un programador. Por ejemplo, puede aplicar una pol´ıtica de reintentos ante peticiones no correctamente respondidas, como por ejemplo, cuando el servidor indica que est´a sobrecargado de trabajo y responde con una p´agina en la que indica que se reintente la petici´on m´as adelante. Tambi´en es posible inundar el programa con reglas de extracci´on alternativas y redundantes para que se pongan en ejecuci´on en el caso de fallos de las reglas principales de 44

extracci´on de datos. Tambi´en es posible insertar c´odigo para asegurarse de que cada petici´on ha sido respondida correctamente y lanzar un mensaje de error y aviso al programador cuando no sea as´ı. En la tabla 1.8 aparece un resumen de las medidas de robustez m´as habituales aplicadas seg´ un el origen del fallo.

S´ıntoma

Tratamiento gen´ erico

Tratamiento particular

Lugar

Varios

Plataforma de ejecuci´ on

C´ odigo de programador

En comunicaciones

Excepciones, errores

Temporizadores, reintentos suaves

Reintentos

Fallos del servidor

P´ aginas de error

Reparaci´ on de p´ aginas

Asserts, reintentos

Cambios de estructura

Fallos en las reglas

No

Reglas secundarias, asserts

Cuadro 1.8: Resumen de medidas de robustez seg´ un origen del fallo

1.5.3.

Coste de mantenimiento

Los programas de navegaci´on gen´erica no adaptada apenas necesitan la´ bor de mantenimiento. Esta est´a apenas centrada en algunos browsers, para los que frecuentemente se lanzan nuevas versiones que mejoran imperfecciones de sus predecesoras o mejoran alguna peque˜ na funcionalidad. Las modificaciones en la regularidad estructural de las p´aginas no las afecta, como s´ı lo hace a las aplicaciones de navegaci´on gen´erica adaptada y particularizada. En el caso del Web Sem´antico, por ejemplo, esas modificaciones deben quedar convenientemente reflejadas en los metadatos del sitio Web, de forma que el mantenimiento se reduce a una labor declarativa. Sin embargo, en los programas de navegaci´on particularizada, este mantenimiento es una labor muy costosa que debe realizarse habitualmente en el mismo c´odigo del programa. Por muchas medidas de robustez que se quieran a˜ nadir para alargar la vida del programa, inevitablemente alg´ un cambio no contemplado en la regularidad estructural acabar´a apareciendo tarde o temprano, invalidando alguna de las suposiciones asumidas por el programador. La labor de mantenimiento es en estos casos la u ´nica opci´on. Con el fin de minimizar costes, suele ser deseable que el mantenimiento lo pueda realizar personal que no necesariamente tenga una elevada preparaci´on. Es por ello que resulta tremendamente importante que los programas de navegaci´on particularizada cumplan tres importantes requisitos: legibilidad, brevedad y simplicidad. 45

Legibilidad Las personas que realizan el mantenimiento de los programas no tienen por qu´e ser necesariamente las mismas que participaron en su desarrollo. Incluso a´ un cuando s´ı sean las mismas personas, las medidas de robustez anteriormente mencionadas pueden haber sido efectivas durante bastante tiempo y el programador que quiera realizar una labor de mantenimiento puede haber olvidado los detalles en los que se bas´o para su construcci´on. Por todas estas razones y por muchas otras, la legibilidad de los programas resulta primordial. Para mejorar esa legibilidad, es conveniente usar t´ecnicas de programaci´on con un nivel de abstracci´on adecuado para la descripci´on de tareas y que preferiblemente sean conocidas por mucha gente y est´en basadas en est´andares que eviten la ambig¨ uedad, de forma que cualquier peque˜ no trozo de c´odigo pueda ser f´acilmente entendido por las personas que lo analicen sin necesidad de tener un conocimiento completo del problema. Brevedad La legibilidad no es el u ´nico factor que influye en el coste de mantenimiento de estos programas. Un wrapper escrito en C o Java puede ser f´acilmente legible al estar escrito en un lenguaje de programaci´on conocido por mucha gente, pero si no usa unas bibliotecas de soporte con el adecuado nivel de abstracci´on, con primitivas que reflejen cada una de las acciones de la tarea en pocas l´ıneas de c´odigo, el tama˜ no del programa final puede f´acilmente dispararse. Para conseguir programas breves, lo deseable es poder disponer de un potente conjunto de primitivas capaces de reflejar cada paso de la tarea en unas pocas l´ıneas de c´odigo. Simplicidad Una buena plataforma de desarrollo se caracteriza por la flexibilidad y potencia de sus primitivas de construcci´on, las cuales deben ser capaces de permitir a su vez la suficiente parametrizaci´on para poder controlar todos los aspectos t´ecnicos de bajo nivel que requieran ser atendidos. Sin embargo, esa potencia suele conseguirse implicando cierta complejidad de manejo por parte del programador, por lo que es deseable adem´as de las propiedades anteriores de legibilidad y brevedad, la suficiente simplicidad del programa para que cualquier cambio que se realice en el mismo no acabe afectando a demasiadas l´ıneas de c´odigo. Por esa raz´on, es deseable usar mecanismos que, permitiendo la programaci´on de complejos algoritmos de navegaci´on y 46

manipulaci´on de datos, mantengan lo m´as simple posible los programas con el objetivo de que sea poco costosa la labor de localizar y modificar las l´ıneas de c´odigo implicadas en un cambio dentro de uno de estos programas. La simplicidad de mantenimiento se refleja en la capacidad de que cualquier cambio pueda f´acilmente localizarse sobre una peque˜ na parte del programa (una l´ınea de c´odigo es lo ideal) sin que el cambio implique necesariamente una revisi´on del resto del programa. Es importante que la plataforma de ejecuci´on pueda indicar el lugar donde se producen los fallos con el fin de tener localizado el lugar en el que debe aplicarse un cambio.

1.6.

Marco de trabajo

Numerosos han sido los trabajos que han elaborado aplicaciones de navegaci´on particularizada para los sitios Web en los u ´ltimos a˜ nos. Buena parte de ellos aparece resumida en el cap´ıtulo 3. Todos ellos coinciden en presentar soluciones con serios costes de desarrollo, problemas de aplicabilidad en diversas fuentes de datos (dadas sus enormes heterogeneidades), una elevada fragilidad ante errores y cambios en el servidor, y, principalmente, elevados costes de mantenimiento que sin duda han influido en su escasa utilizaci´on. Por estas razones, nuevas formas avanzadas de recuperaci´on y tratamiento de la informaci´on para la navegaci´on Web particularizada, aplicable al deep Web que se sabe localizada en el Web legado, con las caracter´ısticas mencionadas en el apartado 1.4, necesitan ser aplicadas, de forma que se aprovechen los avances de los u ´ltimos est´andares orientados al Web, con el fin de dar soluciones efectivas a los problemas anteriormente mencionados minimizando adecuadamente sus costes.

1.7.

Objetivos

En la presente tesis doctoral se pretende aportar soluciones para los problemas mencionados en el apartado 1.5 y que se encuentran resumidos en el apartado 1.6. Con el fin de facilitar la automatizaci´on de tareas en el Web legado, tanto basado en HTML como en cualquier formato XML, se persiguen m´etodos avanzados, para reducir el coste de desarrollo y mantenimiento de aplicaciones de automatizaci´on, de forma que a su vez ´estas sean lo m´as robustas posibles ante posibles errores en las aplicaciones que ejecutan en los servidores y ante la orientaci´on a la visualizaci´on de las p´aginas y a sus 47

cambios de regularidad estructural. A continuaci´on se detallan los objetivos de esta tesis: 1. Proponer unos mecanismos de desarrollo de programas que naveguen autom´aticamente en el deep Web, de forma que el coste de desarrollo de estas aplicaciones, mencionado en el apartado 1.5.1, se vea sensiblemente reducido frente a las opciones existentes actualmente y la automatizaci´on de tareas en el Web por medio de programas de navegaci´on particularizada sea as´ı asequible a un mayor n´ umero de personas. Estos m´etodos de construcci´on deber´an tener un adecuado nivel de abstracci´on, con el fin de favorecer su comprensi´on, y, en lo posible, permitir su utilizaci´on por herramientas que ayuden al programador en su desarrollo. 2. Proporcionar una plataforma que no s´olo pueda usarse con un elevado nivel de abstracci´on y comprensible por los usuarios conforme al objetivo anterior, sino que adem´as sea convenientemente parametrizable y con el mayor cubrimiento posible a la ejecuci´on de aquellas acciones que impl´ıcitamente el browser realiza de forma transparente evitando en lo posible que el usuario sea consciente de ello. Dichas acciones, que aparecen detalladas en el apartado 2.1, son necesarias para mantener correctamente el di´alogo y el concepto de sesi´on con los servidores Web con los que se dialoga. El fin de esta mejora consiste en abstraer al usuario del mayor n´ umero posible de detalles de bajo nivel, permiti´endole, sin embargo, tener el control de los mismos cada vez que lo necesite. Consiguiendo que la gesti´on de estas acciones gen´ericas de cualquier sitio Web queden convenientemente encapsuladas y no formen parte del c´odigo principal de los programas, los programas se mantienen lo m´as compactos posible. 3. Si bien es recomendable que la plataforma de navegaci´on se haga cargo de las acciones de las que no es normalmente consciente un usuario que navega manualmente usando un browser, las acciones que s´ı trascienden al usuario, y que aparecen en el apartado 2.2, como seguir un enlace o rellenar un formulario, deben poder ser activables de la forma m´as sencilla posible por parte de ´este. Lo ideal es que cada una de estas acciones pueda ser especificada con una acci´on sencilla en el caso de que use una herramienta (como por ejemplo en un navegador), o con un m´ınimo n´ umero de l´ıneas de c´odigo, en el caso en el que emplee un lenguaje de programaci´on, usando a ser posible un conjunto peque˜ no pero potente de constructores flexiblemente parametrizables. 48

4. Por otro lado, para las acciones m´ as complejas que debe especificar el usuario, que se encuentran detalladas en el apartado 2.2 y que normalmente se corresponden con las acciones de procesamiento de datos mencionado en el apartado 2.2.6, puede requerirse la especificaci´on de algoritmos complicados. Por ese motivo puede ser necesario la programaci´on de varias l´ıneas de c´odigo, con sentencias de programaci´on como llamadas a funciones que manipulen complejas estructuras de datos, diversas condiciones que impliquen varios posibles casos alternativos a tener en cuenta, bucles que se aniden entre s´ı o con las sentencias condicionales y datos de diversos tipos. Lo habitual es que el c´odigo que procese los datos de una tarea sea muy particular y dependiente de ´esta y de la forma en la que el usuario desee realizarla (por ejemplo, seleccionar la mejor oferta de leche fresca de un cat´alogo seg´ un varios criterios, como marca, precio, tama˜ no del envase y gastos de env´ıo). Por ello, lo m´as aconsejable consiste en permitir la programaci´on de rutinas definibles por el usuario en alg´ un lenguaje de programaci´on ampliamente conocido, como Java, u otros lenguajes igualmente reconocidos, de forma que esa rutina pueda ser convenientemente invocada desde el c´odigo de programa. De esta forma, pasando por argumento a esa rutina los datos extra´ıdos y estructurados de las p´aginas almacenados en repositorios programables (variables, ficheros, ...), la rutina puede manipular los datos obtenidos del Web. 5. Proporcionar mecanismos adecuados para favorecer la robustez de los programas ante fallos en las conexiones TCP/IP y adaptabilidad ante cambios en las p´aginas, reduciendo el coste de ejecuci´on fallida y que aparece detallado en el apartado 1.5.2. El objetivo consiste en incluir medidas de robustez ante fallos en las comunicaciones y ante cambios y fallos en las aplicaciones accedidas por el Web. Estas medidas se plasmar´an tanto en la plataforma de soporte a la ejecuci´on como en constructores directamente utilizables por el usuario en su propio c´odigo. Dicha funcionalidad no aparece en los browsers actuales, al igual que tampoco es com´ un encontrarla en otros tipos de plataformas. Tambi´en se debe contemplar una pol´ıtica de alternativas de uso en el caso de que se encuentren enlaces rotos. 6. Las medidas de robustez pueden amortiguar los efectos de los cambios de regularidad estructural del Web y pueden alargar el tiempo de vida de las aplicaciones de navegaci´on automatizada. Sin embargo, debido al car´acter siempre din´amico del Web, es necesario un mantenimiento para cuando esas medidas fallen. Por ello se pretende proporcionar 49

mecanismos para la minimizaci´on del coste de mantenimiento de las aplicaciones de navegaci´on automatizada, que aparece detallado en el apartado 1.5.3, de forma que este mantenimiento quede reducido a una m´ınima labor, con un coste sensiblemente inferior a las alternativas utilizables hasta el momento, de forma que la mayor´ıa de las acciones de mantenimiento consistan en la modificaci´on de una acci´on sencilla, de las reflejadas en el apartado 2.2, f´acilmente localizada y que normalmente afecte a muy pocas l´ıneas de c´odigo del programa de usuario, sin ser necesario revisar el programa completo. 7. Permitir que esa automatizaci´on se pueda aplicar a pr´acticamente cualquier fuente o aplicaci´on del Web legado, es decir, a las tradicionales p´aginas HTML orientadas a la visualizaci´on y cuyos principales atributos aparecen detallados en el apartado 1.4 y que mayoritariamente abundan en el Web actual. La automatizaci´on de tareas en el Web se debe poder aplicar no s´olo a las p´aginas que, por estar bien construidas, les sean inmediatamente aplicables las modernas tecnolog´ıas de manipulaci´on de documentos y extracci´on de datos, sino tambi´en a aquellas que est´en mal construidas (dentro de unos l´ımites que las permitan ser convenientemente reparadas). Para ello, se incluir´an en la plataforma de ejecuci´on m´etodos capaces de reparar autom´aticamente esos errores de las p´aginas recuperadas de los servidores. Igualmente, deber´an proporcionarse mecanismos, si no en la plataforma, al menos a disposici´on del usuario, para solventar los problemas derivados del hecho de que esas p´aginas est´en pensadas exclusivamente para el acceso por medio de un conjunto limitado de browsers gr´aficos, o con capacidad de accionar eventos especiales desde rutinas embebidas en applets, animaciones Flash o, principalmente, rutinas JavaScript. 8. Permitir aplicar ese tratamiento automatizado de la informaci´on mencionado anteriormente tambi´en a documentos de cualquier lenguaje definido sobre XML, siempre que al menos su esquema sea conocible a priori por el programador para las tareas m´as complejas que as´ı lo requieran. As´ı pues, se pretende que, aunque la mayor parte de las pruebas de implementaci´on de esta tesis se realizar´a sobre p´aginas HTML del Web legado, ese formato concreto no deje de ser s´olo un ejemplo particular de navegaci´on sobre documentos en el Web, siendo posibles igualmente otros lenguajes definibles en XML, no ya s´olo algunos de las ya conocidos (como WML + WMLScript [61], SMIL [125], RDF [123], RSS [16], SVG [124], MathML [120], ...), sino cualquier otro lenguaje XML en general, actual o futuro, es decir, ya inventado o a´ un por inven50

tar, independientemente de si su uso est´a centrado en la visualizaci´on en un browser o si tiene otra finalidad.

1.8.

Estructura de la memoria

El cap´ıtulo 2 presenta un an´ alisis de los principales aspectos de la automatizaci´on en el Web. Para poder realizar una efectiva automatizaci´on de tareas en el Web es preciso analizarlas primero, reconociendo sus partes o acciones b´asicas, examinando las alternativas aplicables a cada una de ellas, teniendo en cuenta las caracter´ısticas distintivas de la materia tratada (los datos del Web). Para cada parte, se analizan sus principales ventajas e inconvenientes desde los puntos de vista de aplicabilidad y de coste de implantaci´on, con el fin de poder escoger para cada problema la soluci´on m´as adecuada. En el cap´ıtulo 3 se describe el estado del arte de la automatizaci´on de tareas en el Web, analizando desde sus precedentes hasta las tendencias actuales. Un estudio sobre las soluciones tecnol´ogicas existentes, clasificadas seg´ un los criterios establecidos anteriormente puede encontrarse en el cap´ıtulo 4. Los cap´ıtulos 5 y 6 presentan unas propuestas de tecnolog´ıas para la s´ıntesis de aplicaciones para la automatizaci´on de tareas en el Web que, bas´andose en las ideas del cap´ıtulo 2, presentan unos mecanismos de construcci´on de estas aplicaciones capaces de ser operables en el Web legado y que tienen adem´as la aportaci´on de estar basadas en est´andares que reducen sensiblemente los costes de implantaci´on y mantenimiento. El cap´ıtulo 7 introduce unos ejemplos que demuestran la aplicabilidad de estas propuestas a tareas definidas sobre sitios Web conocidos. Finalmente se enumeran algunas conclusiones del trabajo as´ı como l´ıneas de actuaci´on para trabajos futuros.

51

52

Cap´ıtulo 2 An´ alisis de tareas Web Cuando la gente navega por el Web, aparte de por ocio o entretenimiento, suele hacerlo persiguiendo un fin concreto, un prop´osito particular. Ejemplos de tareas Web quiz´a no tan complejas como las del apartado 1.2 pueden verse en la siguiente lista: Obtener un documento o un conjunto de ficheros multimedia Leer un peri´odico Usar un buscador (o varios) Enviar postales electr´onicas Leer correo Web, lo cual implica las subtareas de identificarse, listar los mensajes, visitar siguientes, responder, ... Consultar disponibilidad de habitaciones en un hotel, suponiendo que ofrezca esta informaci´on online Comprobar que las p´aginas publicadas en un sitio Web cumplan ciertas propiedades (no tener enlaces rotos, adherirse a alg´ un formato particular, ...) Comprar billetes de avi´on o de tren Comprar en una tienda electr´onica, lo cual implica buscar cada art´ıculo, a˜ nadirlo al carrito, estar atento a las ofertas, pagar, ... Reservar salas de reuniones en la intranet de una organizaci´on 53

Presentar la declaraci´on de la renta Poner una denuncia en la polic´ıa Y muchas m´as Seg´ un crece el Web, con cada vez un mayor n´ umero de datos y aplicaciones accesibles, el n´ umero de tareas igualmente aumenta. De hecho, el crecimiento del Web no es el u ´nico impulsor del aumento de tareas realizables en el ´ Web. Ultimamente comienzan a ser cada vez m´as necesarias aplicaciones que combinen la informaci´on de varios sitios Web, de la misma forma en la que se combinan datos de bases de datos verticalmente fragmentadas y distribuidas [52]. Esas tareas empiezan a ser inmanejables para ser realizadas manualmente. En otras ocasiones, por el contrario, sobre una misma aplicaci´on accesible en el Web es deseable ejecutar varias tareas posibles. Pese a las reticencias de quien no quiere que sus datos sean comparados de forma expl´ıcita por un tercero, es poco extra˜ no que un comparador de ofertas como [3] o de asociaciones de consumidores soliciten al Web de un banco la TAE de su mejor dep´osito bancario a seis meses para compararla con la de su competencia. De la misma forma, tampoco deber´ıa resultar extra˜ no que ese mismo dato acabe siendo proporcionado a otra aplicaci´on encargada de calcular el TAE medio ofrecido por los principales bancos espa˜ noles para un estudio estad´ıstico. La utilidad que el dato tenga en la tarea es algo que depende mucho de la tarea y poco del servidor. Para poder automatizar las tareas en el Web es preciso analizarlas primero, diseccionando las partes en las que est´an estructuradas y reconociendo, de cada una de esas partes, sus capacidades de automatizaci´on y sus principales retos. As´ı, en una etapa posterior, se podr´an aprovechar esas cualidades de la mejor forma posible para sintetizar aplicaciones que automaticen el Web de forma m´as eficiente y menos costosa. Acciones b´ asicas A pesar de la clara e intr´ınseca heterogeneidad del Web, mencionada en el apartado 1.4 y manifiesta, no s´olo en sus datos, sino tambi´en en sus formas de presentaci´on, lo cierto es que, por debajo de toda esta visible heterogeneidad, los principios bajo los que se sustentan las tareas en el Web son sencillos. De hecho, la simplicidad de manejo de cualquier browser no es m´as que un fiel reflejo de que, efectivamente, las partes de una tarea realizable 54

con una navegaci´on en el Web se reducen a un conjunto limitado y sencillo de acciones b´ asicas. El conjunto de posibles tareas que se pueden realizar en el Web es inmenso. De hecho, no para de crecer en tanto en cuanto es cada vez mayor el n´ umero de aplicaciones que se encuentran disponibles a trav´es del Web. Sin embargo, los innumerables servicios del Web, sean ´estos simples p´aginas o bien complejas aplicaciones manejadas por varios formularios, pese a sus aparentes diferencias visuales, tienen en com´ un el hecho de estar todos ellos fundamentados en alguna secuencia (o secuencias) de un reducido conjunto de acciones b´asicas que resultan ser comunes a todas las tareas. Cada tarea realizable en el Web se puede desarrollar efectuando una secuencia particular de este conjunto de acciones b´asicas. Por ejemplo, una t´ıpica tarea de chequeo de cuentas de correo electr´onico en un portal de correo Web puede implicar una acci´on b´asica de solicitud de un documento donde aparece un formulario de identificaci´on que, una vez rellenado y enviado al servidor, permite el acceso a una bandeja de correo entrante en la que aparece una tabla con los principales atributos de los mensajes almacenados, ordenados por fechas y en los que es posible distinguir entre mensajes le´ıdos y no le´ıdos. Cada uno de esos mensajes a su vez puede ser le´ıdo si se sigue convenientemente un enlace. Tambi´en puede ser borrado, si se chequea su opci´on de selecci´on correspondiente y despu´es se pulsa al bot´on de borrado. Otras acciones, como responder o reenviar tambi´en son posibles. Secuencias distintas de este reducido conjunto de acciones b´asicas constituyen el quehacer diario del tr´afico Web actual al que dan servicio los numerosos servidores Web conectados a la Red. Para la realizaci´on de una tarea Web, el usuario debe realizar la ejecuci´on en secuencia ordenada, de cada una de las acciones b´asicas que conforman esa tarea.

Tipos de acciones b´ asicas Las acciones b´asicas que forman parte de una tarea no son todas de la misma naturaleza, pudiendo distinguirse entre acciones b´asicas impl´ıcitas y acciones b´asicas expl´ıcitas. Las acciones b´asicas impl´ıcitas son aquellas que no deben trascender al usuario y que son realizadas autom´aticamente por el browser en una navegaci´on manual. En ellas, el usuario no es necesariamente emprendedor de la acci´on. Se trata de acciones que se encuentran gestionadas internamente por los browsers, sin que el usuario deba proporcionar instrucciones expl´ıcitamente para ello. Ejemplos de acciones b´asicas impl´ıcitas son todas las referentes 55

a la gesti´on de cabeceras HTTP (gesti´on de cookies, redireccionamientos, identificaci´on de usuario y de agente de usuario, preferencias en los formatos aceptados o en el idioma, ...), o las que se deben realizar necesariamente con el contenido del cuerpo de la respuesta HTTP (correcci´on interna de errores de estructura en el documento, seguimiento impl´ıcito de enlaces, acciones embebidas en lenguajes de scripting, ...). Las acciones b´asicas expl´ıcitas son el conjunto de acciones que, en una navegaci´on manual, deben trascender al usuario, ya que el browser no puede o no debe emprenderlas por su cuenta. Es por ello que el browser debe esperar instrucciones del usuario, t´ıpicamente de forma interactiva, para poder continuar. De esta forma, el usuario se acaba convirtiendo necesariamente en el emprendedor de la acci´on. Ejemplos de acciones b´asicas expl´ıcitas son el seguimiento expl´ıcito de enlaces, el rellenado y env´ıo de formularios, la extracci´on de datos relevantes del documento o el procesamiento que debe realizarse con los datos recolectados. Como puede apreciarse, las acciones b´asicas expl´ıcitas tienen un nivel de abstracci´on m´as elevado y cercano al usuario, mientras que las acciones b´asicas impl´ıcitas tienen un nivel de abstracci´on m´as bajo y m´as cercano a los aspectos t´ecnicos de los protocolos HTTP y de los formatos de publicaci´on en el Web. Como puede comprobarse en la tabla 2.1, que refleja las principales diferencias entre las acciones b´asicas expl´ıcitas e impl´ıcitas, las primeras afectan constantemente al usuario de la navegaci´on manual. Por el contrario, esas acciones son atendidas por un programa que sustituye al usuario en las aplicaciones de navegaci´on automatizada, tanto gen´erica como particularizada. Las acciones impl´ıcitas, por su parte, dise˜ nadas para ser resueltas sin conocimiento expl´ıcito del usuario, son transparentemente gestionadas por los browsers en la navegaci´on manual. En el caso de la navegaci´on automatizada, lo deseable ser´ıa que la plataforma de navegaci´on (el programa que navegue bas´andose en metadatos, o las bibliotecas usadas para la construcci´on del programa de navegaci´on particularizada) ejecutaran todas esas acciones con la misma transparencia de un browser. No obstante, la falta de buenas plataformas de navegaci´on automatizada para el Web con soporte para todas estas posibles acciones muchas veces acaba obligando al programador a introducir su propio c´odigo de tratamiento para suplir las carencias de las plataformas de navegaci´on. Ello suele ser una fuente de encarecimiento de costes de estos programas, seg´ un el nivel de soporte que de estas acciones tenga la plataforma.

56

Acci´ on b´ asica expl´ıcita

Acci´ on b´ asica impl´ıcita

Usuario

Browser

Navegaci´ on manual Navegaci´ on autom´ atica gen´ erica no adaptada

Robot

Seg´ un programa

Navegaci´ on autom´ atica gen´ erica adaptada

Metadatos

Agente Web Sem´ antico

Navegaci´ on autom´ atica particularizada

Programador

Bibliotecas+programador

Nivel de abstracci´ on

Cercano a la tarea

Cercano a formatos y protocolos

Ejemplo

Enviar un formulario relleno

Gestionar una cookie

Cuadro 2.1: Diferencias entre acciones b´asicas expl´ıcitas e impl´ıcitas

2.1.

Acciones b´ asicas impl´ıcitas

Las acciones b´asicas impl´ıcitas son realizadas por muchos browsers sin que sus usuarios sean muchas veces conscientes de ello. Pese a su relativamente bajo conocimiento por muchos usuarios, las acciones b´asicas impl´ıcitas son necesarias para aspectos tan fundamentales como el mantenimiento de sesiones HTTP, las restricciones de acceso a contenidos, la adecuaci´on del Web a preferencias del usuario, o la ejecuci´on de m´ ultiples comportamientos internos necesarios para la correcta navegaci´on por cualquier p´agina accesible desde el Web. A continuaci´on aparecen detalladas algunas de las acciones b´asicas impl´ıcitas m´as importantes.

2.1.1.

Gesti´ on de cabeceras HTTP

El protocolo HTTP establece la posibilidad de intercambiar en varios campos situados en sus cabeceras, informaci´on relativa a las peticiones y respuestas intercambiadas. Estas cabeceras pueden ser usadas tanto por el cliente como por el servidor HTTP para obtener informaci´on que necesiten del otro extremo con el fin de mantener un di´alogo correcto. La mayor´ıa de esas cabeceras permanecen inalterables a lo largo de ese di´alogo, pero otras muchas van cambiando a lo largo de ese di´alogo, por lo que deben ser adecuadamente gestionadas para poder realizar correctamente la petici´on HTTP. En la tabla 2.2 aparecen las principales cabeceras que deben gestionar los clientes del protocolo HTTP. Cada una de esas cabeceras tiene su especial importancia. Por ejemplo, algunos servidores Web presentan p´aginas de error cuando son accedidos por programas que no acreditan ser Microsoft Internet Explorer en la cabecera de identificaci´on del cliente, pese a que sus contenidos sean en realidad navegables por otros browsers. En otros casos, no 57

especificar correctamente una cookie o el campo Referer en una petici´on a un servidor puede suponer la p´erdida de la sesi´on con el servidor. No indicar que se acepta HTML como formato, puede implicar la suposici´on por parte del servidor de que debe responder con documentos en formato WML o quiz´a en texto plano. No indicar que el idioma preferible es el espa˜ nol puede implicar que las p´aginas vengan por defecto en ingl´es. Nombre de cabecera

Emitida por

Significado

Ejemplo

User-Agent

Cliente

Identificaci´ on 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

Identificaci´ on 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 petici´ on

text/html

Content-Length

Cliente o Servidor

Tama˜ no del documento o petici´ on

12354

Cuadro 2.2: Principales cabeceras gestionadas por los clientes del protocolo HTTP

2.1.2.

Gesti´ on de errores en la comunicaci´ on con el servidor

Las comunicaciones con el protocolo HTTP pueden fallar si existe una sobrecarga en la conexi´on TCP/IP, el servidor al que se intenta conectar est´a inaccesible o su respuesta tarda un tiempo considerado demasiado alto para lo razonable por la tarea. Dependiendo de la gravedad del fallo (no es lo mismo que haya un fallo de transferencia en una p´agina HTML que lo haya en la transferencia de una de sus im´agenes), el error deber´a hacerse constar con mayor o nivel de severidad al usuario o al programa que dirija la tarea para que tome las medidas que considere oportunas.

2.1.3.

Reparaci´ on interna de p´ aginas mal construidas

Una vez obtenida una p´agina del Web y solventados los problemas de comunicaci´on con el servidor, debe procederse a analizar la respuesta, nor58

malmente contenida en una p´agina HTML. Lamentablemente, tal y como se mencionaba en el apartado 1.4.3, muchas de las p´aginas que se encuentran en el Web no cumplen el conjunto de normas b´asicas de construcci´on. Por esa raz´on, resulta necesario reparar internamente esos errores con el fin de permitir el an´alisis de esa respuesta por el cliente, ocultando al usuario esos errores en la medida de lo posible. Este trabajo extra en el lado del cliente debe ser realizado debido a la tradicional permisividad ante errores en las p´aginas obtenidas de los servidores.

2.1.4.

Seguimiento impl´ıcito de enlaces

Una vez correctamente analizada una p´agina obtenida del Web, es necesario identificar todos aquellos elementos multimedia que forman parte de la misma con el fin de seguir los enlaces que impl´ıcitamente deban visitarse. El seguimiento de enlaces puede ser entendido como impl´ıcito, si es el browser el que decide recuperar ese documento, quiz´a porque forme parte integrante del que acaba de ser descargado y analizado, o expl´ıcito, si es el usuario el responsable de la activaci´on del enlace. Por ejemplo, los enlaces que en HTML se definen con las etiquetas a o area son normalmente seguidos de forma expl´ıcita, porque no deben ser visitados a no ser que el usuario expl´ıcitamente lo solicite. Por el contrario, en otros tipos de enlaces que en HTML se definen con etiquetas como frame, img, script, link u object, es el browser quien determina si deben ser seguidos de forma expl´ıcita o impl´ıcita. Si, por ejemplo, se desea emular a un browser gr´afico como Mozilla [12] o Microsoft Explorer [91], los seguimientos de los enlaces definidos en las etiquetas anteriores, salvo los roles expl´ıcitos de link (next, previous, table of contents, ...), son impl´ıcitos, pues se entiende que un browser gr´afico normalmente descarga impl´ıcitamente de cualquier p´agina del Web todos sus componentes, como son los marcos, im´agenes, scripts externos y hojas de estilo externas. Por el contrario, cuando se desea emular a un browser textual como Lynx [10], el seguimiento de los anteriores enlaces se vuelve, si no expl´ıcito, muchas veces incluso inaccesible, porque se entiende que hay documentos enlazados que no son adecuadamente procesados por el browser. En la tabla 2.3 puede verse un esquema resumido del comportamiento de estos enlaces dependiendo del browser en el que se utilizan.

59

Browser

a, area

img, frame

link

script, object

Gr´ afico

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.

Ejecuci´ on de comportamientos embebidos en las p´ aginas

Una vez han sido correctamente descargados todos los elementos multimedia de las p´aginas, los elementos din´amicos de las mismas (rutinas JavaScript o JScript, Applets, controles ActiveX, animaciones en Flash, otros plugins, ...) pueden empezar a funcionar. Se trata de las rutinas que, mediante peque˜ nos programas insertados en las p´aginas Web y, gracias a un int´erprete, m´aquina virtual o plugin embebido en el browser, permiten al dise˜ nador de la p´agina tener acceso a ciertos recursos del browser del usuario. Las rutinas JavaScript, que suelen ser las m´as usadas, permiten controlar un amplio espectro de acciones t´ıpicamente manejadas por el browser. Por ejemplo, son capaces de manipular aspectos tan diversos como las propiedades de visualizaci´on de los elementos de las p´aginas (tama˜ nos, posiciones, colores, visibilidad, ...) , la descarga condicionada de elementos multimedia de una p´agina, manipular la base de datos de cookies o modificar al gusto del dise˜ nador de la p´agina la sem´antica del comportamiento de los controles de los formularios. Tanto es as´ı, que muchas p´aginas resultan innavegables si el browser con el que se las intenta acceder no dispone de un int´erprete ajustado a las especificaciones del JavaScript utilizado en la p´agina. Si la plataforma de navegaci´on no dispone de estos int´erpretes o estos plugins, los comportamientos embebidos no son ejecutables. Ello puede no suponer un problema serio para el procesamiento de p´aginas con comportamientos embebidos que s´olo afecten a aspectos de visualizaci´on, siempre que existan contenidos alternativos ofrecibles al usuario o, simplemente no aporten datos relevantes. Sin embargo, puede suponer serios problemas para la accesibilidad cuando esos comportamientos tienen un papel en la navegaci´on. Este tipo de rutinas tiene una caracter´ıstica muy importante desde el punto de vista de su automatizaci´on. Al tratarse de comportamientos que vienen pre-programados en elementos multimedia de las p´aginas, su comportamiento, no se encuentra por lo tanto pre-programado en ning´ un browser, es decir, no es conocible a priori, por lo que para su correcto funcionamiento se necesita del correspondiente soporte para la ejecuci´on. Sin embargo, dis60

poner de ese soporte puede ser dif´ıcil o costoso para muchos usuarios que no siempre lo encuentran disponible en browsers o plataformas de navegaci´on automatizada.

2.1.6.

Soporte para otros protocolos

En ocasiones, se deben enviar mensajes por correo electr´onico. En otras ocasiones, algunos documentos deben recuperarse usando otros protocolos como FTP. Tambi´en es posible que sea necesario acceder a ciertas p´aginas mediante protocolos seguros, principalmente SSL. Forma parte de las acciones impl´ıcitas de la plataforma de navegaci´on saber gestionar adecuadamente estos protocolos, de forma que el usuario no sea consciente de esos detalles de bajo nivel de cada uno de ellos.

2.1.7.

Tratamiento adecuado de cada campo de formularios seg´ un su forma de rellenado

A la hora de asociar valores a los campos de los formularios, es necesario tener en cuenta las reglas de rellenado de cada campo del formulario reflejadas en la tabla 2.4. Por una parte, debe considerarse el tipo de valor que indica la naturaleza del valor asociado a cada campo del formulario. Principalmente, pueden distinguirse textos libres especificados por el usuario, ficheros que deben ser enviados del cliente al servidor y valores ya especificados en la p´agina por el servidor. Por otra parte, debe considerarse la especificaci´on de rellenado por el usuario, es decir, aquello que el usuario debe proporcionar para que dicho campo de formulario quede adecuadamente relleno. Principalmente, puede distinguirse entre el rellenado directo, que consiste en el que el usuario proporciona directamente el valor con el que desea rellenar el formulario, o bien un rellenado indirecto, en el que el usuario especifica un criterio de selecci´on que sirve para decidir las opciones que deben quedar marcadas y las que no. El criterio de selecci´on consiste normalmente en un criterio booleano que, aplicado a cada una de las opciones seleccionables, indica si esa opci´on debe admitirse o no como seleccionada. Los criterios de selecci´on pueden ser de dos tipos, sencillos o m´ ultiples, dependiendo de si, cuando son aplicados a un conjunto de varias opciones, deben indicar una o varias de esas opciones como seleccionadas. Este acomodamiento, o conjunto de restricciones establecidas sobre el conjunto de valores posibles con los que se puede rellenar un formulario, se encuentra ya facilitado por los browsers y es una de las acciones b´asicas 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 selecci´ on

select.multiple, input.checkbox

Valores especificados por el servidor

Criterio de selecci´ on (m´ ultiple)

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 selecci´ on

Cuadro 2.4: Tipo de rellenado de campos de formularios HTML

2.1.8.

Creaci´ on de query-string a partir de un formulario relleno

Antes de enviar a un servidor un formulario relleno, es necesario codificar la informaci´on que encierra para su env´ıo, de forma que sea correctamente procesable en el servidor. Esta informaci´on codificada, denominada querystring, es enviada como parte de la correspondiente petici´on HTTP al servidor. En el caso de que la petici´on sea del tipo POST, el query-string debe formar parte del cuerpo de la petici´on, por lo que ir´a aislado aparte de las cabeceras HTTP. Por el contrario, si el formulario se env´ıa con un comando GET, el query-string es concatenado al final de la URL que se desea visitar. La acci´on de codificaci´on de formularios rellenos debe tener en cuenta su estructura, respetando el orden y el tipo de cada uno de los campos que componen el formulario. A la hora de crear el query-string, se deben establecer parejas campo-valor, independientemente de c´omo se hubieran rellenado los campos de ese formulario. Por otra parte, en la codificaci´on del query-string puede frecuentemente jugar tambi´en un papel importante el JavaScript. Muchos de los campos de los formularios dedicados a controlar eventos JavaScript no deben ser enviados al servidor. Los botones de env´ıo no pulsados tampoco deben ser enviados al servidor. 62

2.2.

Acciones b´ asicas expl´ıcitas

Las acciones b´asicas expl´ıcitas son las que definen los pasos en los que est´a involucrado el usuario durante la ejecuci´on de una tarea en el Web. Realizarlas con un navegador suele ser un buen punto de partida para empezar a construir el esqueleto b´asico de una aplicaci´on de navegaci´on automatizada. Las tareas del Web son, por lo tanto, especificadas bas´andose en este tipo de acciones. Algunas de ellas, sin embargo, no son siempre necesarias en todos los pasos. La tabla 2.5, muestra cada una de esas acciones en una fila, para comparar su capacidad de automatizaci´on desde los puntos de vista de la navegaci´on manual y de la navegaci´on autom´atica. Como puede apreciarse, desde el punto de vista de la navegaci´on manual, todas ellas, en mayor o menor medida, con mayor o menor soporte por parte del browser, son responsabilidad del usuario. Desde el punto de vista de la navegaci´on automatizada, estas acciones deben recaer en un programa, por lo que se mencionan las partes de ese programa que est´an afectadas por cada una de esas acciones. Por ejemplo, las acciones de seguimiento de enlaces y env´ıo de formularios apenas suelen suponer la correspondiente llamada a las primitivas GET o POST del protocolo HTTP, a la que s´olo hay que parametrizar convenientemente. Sin embargo, el resto de las acciones b´asicas expl´ıcitas no tiene un coste tan reducido como ´ese habitualmente, ya que, al ser dependientes de la tarea, deben ser programadas con c´odigo de usuario. Acci´ on b´ asica expl´ıcita

Navegaci´ on manual

Navegaci´ on automatizada

Extracci´ on de datos relevantes

Usuario

Reglas de extracci´ on (regularidad estructural)

Estructuraci´ on de datos semiestructurados

Usuario

Repositorios estructurados

Seguimiento expl´ıcito de enlaces

Usuario + Browser

Llamada a primitiva GET

Rellenado de formularios

Usuario + Browser

Metadatos, c´ odigo 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 b´asicas expl´ıcitas

2.2.1.

Extracci´ on de datos relevantes

La extracci´on de datos relevantes implica la selecci´on de los datos considerados relevantes embebidos en las p´aginas Web y su extracci´on para posteriores procesamientos. Estos datos, cuya relevancia se encuentra descrita en 63

el apartado 1.4.4, se suelen encontrar repartidos por varias p´aginas o marcos. Cuando no se trata de ficheros multimedia, lo normal es que se encuentren en forma de simple informaci´on textual (e.g.: precios, titulares, mensajes, tel´efonos, direcciones, cotizaciones, fechas, cantidades, ...) t´ıpicamente embebida en p´aginas HTML junto con otra mucha informaci´on que puede no ser relevante para la tarea (publicidad, marcado estructural orientado a la visualizaci´on, datos relevantes para otras tareas, ...). La capacidad de extraer datos del Web, es sin duda de las m´as importantes, pues juega un papel importante en todos los pasos ejecutados entre la navegaci´on por el Web. Seguir un enlace implica seleccionar en primer lugar el enlace que debe ser seguido y extraer de ´el la direcci´on a la que apunta. Enviar un formulario implica seleccionar en primer lugar todos los campos que forman parte del mismo y rellenar cada uno conforme a su naturaleza y a los objetivos del usuario, para despu´es activar la acci´on del formulario. Otros procesamientos m´as complejos definidos por el usuario, como comparaciones, integraci´on de datos y otros comportamientos, necesitan tambi´en la realizaci´on de complejas extracciones de datos. De esta forma se prescinde de todos aquellos datos que aparecen en las p´aginas pero que no intervienen en la tarea. En el caso de la navegaci´on manual basada en browsers, el usuario debe visualizar normalmente pantallas enteras para poder detectar visualmente la informaci´on que le interesa. Es normal que para ello deba examinar varias pantallas y ventanas o hacer scrolling. Desafortunadamente, los browsers de hoy en d´ıa no reciben especificaciones acerca de cu´ales son los datos relevantes para los usuarios y cu´ales pueden ser ignorados, con el fin de destacar los primeros y ocultar los u ´ltimos (esta labor quiz´a podr´ıa ser emprendida con scripts definibles por los usuarios aplicados a documentos del Web, pero ello no es una soluci´on siempre factible). La u ´nica funci´on de un browser es mostrar un documento de la mejor forma posible y ejecutar sus ´ordenes interactivas, siendo imposible destacar para cada usuario los datos que son interesantes para ´el y su tarea. Las opciones de destacado de partes de documentos est´an a merced de los autores de los documentos, no de sus lectores, algo que sin embargo algunos trabajos como [48] s´ı han logrado hacer bas´andose en una personalizaci´on que no todos los sitios Web ofrecen. Aunque la simple lectura de textos sobre las pantallas de un ordenador puede ser suficiente para algunos usuarios a la hora de pasar a realizar su siguiente acci´on, lo cierto es que el Web se caracteriza por presentar demasiada informaci´ on que presenta costes prohibitivos para ser procesada por personas, raz´on por la cual una separaci´on automatizada de los datos relevantes respecto del resto de datos no relevantes resulta conveniente en esos casos. 64

En el caso de la navegaci´on automatizada, la extracci´on de datos no est´a basada en la visualizaci´on, sino que consiste en una selecci´on de datos relevantes dentro de documentos semiestructurados, lo cual no es siempre sencillo y es adem´as claramente dependiente de la estructura interna de esos documentos. Para ello, pueden usarse reglas de extracci´ on de datos basadas en una regularidad estructural seleccionando aquellos datos que cumplan un formato esperado. Sin embargo, esta estructura de marcado en la que est´an basadas estas reglas est´a normalmente muy orientada a los aspectos de visualizaci´on, por lo que las reglas de extracci´on de datos, aparte de ser de las partes con mayor presencia en los programas, son tambi´en de las m´as fr´agiles, ya que cualquier cambio en la estructura esperada de las p´aginas afecta directamente a esas reglas. La f´acil construcci´on de estas reglas de extracci´on de datos es vital para conseguir un bajo coste, no s´olo de desarrollo, sino tambi´en de mantenimiento. En el caso de la navegaci´on manual, esta labor recae completamente en el usuario. El browser pr´acticamente no interviene ni realiza otra labor m´ as que presentar los datos en la pantalla junto con el resto de la informaci´ on, sin tener capacidad para tan siquiera resaltar el dato para el usuario, pues no tiene forma de saber cu´al de los datos que figuran en la p´ agina es el dato que interesa al usuario para su tarea. En el caso de la navegaci´ on autom´ atica, al tratarse de un tratamiento espec´ıfico y dependiente de la estructura de las p´ aginas, de los datos, y de la tarea que los va a utilizar, esta acci´ on no se encuentra pre-construida en una biblioteca gen´erica de la plataforma, por lo que debe ser programada en reglas de extracci´ on definibles por el usuario.

2.2.2.

Estructuraci´ on de datos semiestructurados

Los datos extra´ıdos pueden ser necesarios m´as de una vez a lo largo de la ejecuci´on de una tarea, por lo que conviene que sean convenientemente almacenados en un repositorio estructurado. Desde el punto de vista de la navegaci´on manual, esta labor recae en la responsabilidad del usuario, quien habitualmente suele resolver el problema memorizando el dato recientemente visualizado (t´ıpicamente en su memoria a corto plazo), apuntarlo en un papel o, en el mejor de los casos, recurrir el conocido uso del copiar y pegar en la ventana de otra aplicaci´on. Sin embargo, ni la mente humana, ni el papel, ni una ventana de un editor de texto son repositorios adecuados para el procesamiento automatizado desde un programa de ordenador. Adem´as, los datos obtenibles del Web pueden ser muy voluminosos (de ah´ı el desbordamiento habitual que sufren la mayor´ıa de los usuarios que navegan con browsers), por 65

lo que para poder almacenar convenientemente esos datos se necesitan repositorios capaces de almacenar grandes vol´ umenes de los mismos, muchas veces sin que su tama˜ no sea a priori limitable. Por esa raz´on, los programas de navegaci´on autom´atica suelen usar, no s´olo variables de memoria, sino estructuras de datos de tama˜ no variable, como vectores, listas o ficheros, en los que ir almacenando los valores extra´ıdos de las p´aginas para que puedan ser posteriormente procesados. Cuando se almacenan las partes seleccionadas de estos documentos en repositorios especializados, los datos seleccionados pueden ser convertidos a tipos de datos m´as f´acilmente procesables habituales en los lenguajes de programaci´on, como n´ umeros, booleanos, fechas, cadenas de caracteres o, quiz´as, nodos de un ´arbol de documento. En el caso de la navegaci´ on manual basada en browsers, el usuario es el responsable de almacenar los datos y por ello es ´el quien decide c´ omo almacenarlos. Normalmente los suele intentar memorizar o dejar en alguna ventana abierta del navegador que posteriormente est´e accesible para poderla volver a leer, pero ello implica la necesidad de tener que volver a extraer de ella nuevamente los datos cada vez que se deseen manipular, y la posibilidad de perderlos si se siguen enlaces en la misma ventana. En el mejor de los casos, pueden almacenarse en otras herramientas externas, pero ello implica una ardua labor de estructuraci´ on con el fin de poder manipular eficientemente grandes vol´ umenes de informaci´ on. En el caso de la navegaci´ on autom´ atica, al tratarse de un tratamiento espec´ıfico y dependiente de la estructura de las p´aginas, de los datos, y de la tarea que lo va a utilizar, esta acci´ on no se encuentra pre-construida en una biblioteca gen´erica de la plataforma, por lo que debe ser programada en las correspondientes sentencias de almacenamiento en repositorios estructurados.

2.2.3.

Seguimiento expl´ıcito de enlaces

Los datos en el Web se suelen encontrar distribuidos en m´ ultiples documentos que, por lo tanto, deben ser recuperados. Para ello suele usarse el protocolo HTTP, haciendo un seguimiento expl´ıcito de enlaces conforme a la tabla 2.3. A veces las direcciones de esos documentos no son conocidas a priori por el usuario, sino que tienen que ser obtenidas din´amicamente desde otras p´aginas ejercitando la navegaci´on. En los casos m´as sencillos, bastar´a con visitar una direcci´on Web en la que se sabe que figuran los datos que se desea consultar. En otros casos, es necesario establecer una sesi´on desde la p´agina principal del sitio Web de forma que hay que seguir varios enlaces y rellenar varios formularios antes de acceder finalmente a la p´agina 66

que contiene el dato. En el caso de la navegaci´on manual, el seguimiento expl´ıcito de enlaces consiste en una labor semiautom´atica, asistida por el browser, donde la labor del usuario se reduce a seleccionar y activar los enlaces que le interesan. En el caso de la navegaci´on autom´atica, esta acci´ on se encuentra ya completamente pre-construida en las primitivas de varias bibliotecas utilizables desde distintos lenguajes de programaci´ on para lanzar comandos GET, por lo que t´ıpicamente la labor de programaci´ on se reduce a parametrizar la llamada a esta primitiva.

2.2.4.

Rellenado de formularios

El rellenado de un formulario Web consiste simplemente en asociar uno o varios valores a cada uno de sus campos (tambi´en es posible dejar algunos de ellos vac´ıos). Los valores con los que se rellenan esos campos (tal y como viene expresado en la tabla 2.4) pueden venir definidos por el usuario, o pueden venir predefinidos en el propio formulario, pero en cualquier caso es el usuario el responsable de establecer aquellos valores que le interesen para su tarea. Por otra parte, puede haber campos de formularios que no son manipulados (porque no los ha querido rellenar) o que no son manipulables (porque est´an ocultos al usuario), en cuyo caso, conservan el valor con el que vinieron rellenados por defecto en el formulario. En el caso de la navegaci´on manual, se trata de una labor semiautom´ atica asistida por el browser, donde la labor del usuario se reduce a interactuar con los campos de los formularios. En el caso de la navegaci´ on autom´ atica, al tratarse de un tratamiento espec´ıfico y dependiente de la estructura del formulario, y de la tarea que lo desee rellenar, esta acci´ on no se encuentra pre-construida en una biblioteca gen´erica de la plataforma, por lo que debe ser programada en c´odigo definido por el usuario. Normalmente la complejidad del rellenado de cada campo es dependiente de la estructura interna de representaci´on de ese formulario, pues es normalmente sobre ella donde se realizan estas modificaciones para despu´es proceder a la orden de env´ıo del formulario, seg´ un la siguiente acci´ on expl´ıcita. En el mejor de los casos, con una buena representaci´on donde exista una lista de campos recorrible y unas primitivas de modificaci´on acordes con la sem´ antica de cada campo, esa labor puede realizarse en una simple l´ınea de c´ odigo para cada uno de esos campos. 67

2.2.5.

Env´ıo de formularios

Una vez que un formulario se encuentra ya relleno, la informaci´on recogida en ´el puede ser enviada al servidor para que sea procesada. En el caso de la navegaci´ on manual, se trata de una labor semiautom´ atica, asistida por el browser, donde la labor del usuario se reduce a seleccionar un bot´on de env´ıo (en el caso en el que haya varios) y pulsarlo. En el caso de la navegaci´on autom´atica, esta acci´ on se encuentra ya completamente pre-construida por las primitivas de varias bibliotecas utilizables desde distintos lenguajes de programaci´ on para lanzar comandos GET o POST, por lo que t´ıpicamente apenas se necesita programar y parametrizar la llamada a esta primitiva.

2.2.6.

Procesamiento de datos

Una vez que los datos del Web han sido recuperados, y homogeneizados a un formato estructurado, su manipulaci´on no dista de la que puede haber en cualquier tarea de tratamiento de datos (no necesariamente involucrada en el Web). Operaciones tales como comparaciones, acumulaciones, reordenaciones, operaciones aritm´eticas o l´ogicas o de procesamiento de textos pueden ser combinadas seg´ un las necesidades espec´ıficas de manipulaci´on de informaci´on que requiera la tarea. En el caso de la navegaci´on manual, el procesamiento que t´ıpicamente realizan los browsers a las p´aginas que recuperan del Web se limita a la mera visualizaci´on en las pantallas de los ordenadores, facilitando, eso s´ı, el control de todos los aspectos visuales y permitiendo al usuario la posibilidad de solicitar nuevos documentos del Web mediante el resaltado en la visualizaci´on de zonas activables del documento por el usuario mediante teclado o rat´on para el seguimiento de enlaces. Cualquier otro tipo de procesamiento queda delegado en el usuario. Muchas veces, ciertamente, estos tratamientos de datos en el Web son comparaciones sencillas o labores que manejan poca informaci´on, pero, cuando el volumen de datos es algo elevado, o cuando el tratamiento que se pretende realizar con esos datos empieza a incluir operaciones aritm´etico-l´ogicas un poco m´as complicadas que las simples comparaciones detectables a simple vista y que escapan del f´acil c´alculo mental, el procesamiento manual de esos datos se convierte en una labor realmente tediosa. En el caso de la navegaci´on autom´atica pueden definirse rutinas que pro68

cesen esos datos de otra forma m´as adecuada para las tareas. Mediante la programaci´on de rutinas definibles por el usuario, que reciban por argumento los datos obtenibles durante la navegaci´on, el tratamiento de estos datos puede ser realizado por el ordenador. Simplemente deber´an procesarse los datos relevantes que se encuentran almacenados en repositorios programables, conforme a los objetivos establecidos en la tarea. Tambi´en es posible que esos procesamientos puedan estar ya implementados en alguna herramienta externa. En esos casos, el tratamiento consistir´a en invocar a esa herramienta como un proceso externo, enviarle los datos para que los procese y esperar de ella los resultados. En el mejor de los casos, el procesamiento puede ser tan sencillo como la simple impresi´on por pantalla de unos simples datos obtenidos, para lo cual es posible programar esos comportamientos con sentencias sencillas dentro del mismo programa principal. La elecci´on sobre d´onde programar este tipo de comportamientos depender´a de la complejidad de los mismos, del hecho de que ya pudieran estar programados en alg´ un programa legado y de la capacidad del programador para reutilizar ese c´odigo. En el caso de la navegaci´on manual basada en browsers, el usuario es el responsable de realizar este procesamiento de datos, normalmente de forma mental y sin soporte por parte del browser. En el caso de la navegaci´ on autom´atica, al tratarse de un tratamiento espec´ıfico y dependiente de los datos, y de la tarea que lo va a utilizar, esta acci´ on no se encuentra pre-construida en una biblioteca gen´erica de la plataforma, por lo que debe ser programada en rutinas definidas por los usuarios, que no necesariamente ser´ an dependientes de la cambiante estructura de las p´ aginas al haber sido los datos convenientemente estructurados en una fase anterior.

2.3.

Subsanaci´ on de las faltas de soporte de la plataforma de navegaci´ on

Finalmente, tal y como se ver´a en el apartado 3, no todas las plataformas tienen un soporte completo a la ejecuci´on de aspectos de navegaci´on. Por ejemplo, muchas plataformas carecen de soporte a la interpretaci´on de rutinas JavaScript, que se encuentran habitualmente embebidas en las p´aginas visitadas. En estas plataformas no est´a soportada, por lo tanto, la navegaci´on basada en JavaScript, en la que las URL que deben visitarse no figuran expl´ıcitas en los enlaces que se pretende seguir, sino que dichas direcciones deben computarse por alguna rutina JavaScript activable por alg´ un evento provocado por el usuario con el rat´on o el teclado. Para poder navegar en 69

estos sitios desde este tipo de plataformas, el programador debe subsanar con sus propias l´ıneas de c´odigo las acciones que simulen el comportamiento de esas rutinas JavaScript. En otras plataformas no existe un conveniente soporte de las cabeceras HTTP o una adecuada creaci´on del conveniente query-string a partir de cada formulario relleno, por lo que el usuario debe programar estos comportamientos impl´ıcitos con su propio c´odigo. Todas aquellas acciones que, no teniendo soporte en la plataforma, sean significativas para la navegaci´on, deben ser suplidas con c´odigo definido por el usuario. Dicho c´odigo suele tener un coste significativamente elevado. Por esta raz´on, y para minimizar este coste, es importante, por lo tanto, escoger una buena plataforma de navegaci´on. Soporte de los browsers a las acciones b´ asicas expl´ıcitas Tal y como puede verse en la tabla 2.5, en la navegaci´on manual, el browser da un soporte semiautom´atico a tres de las acciones m´as sencillas (seguimiento expl´ıcito de enlaces y rellenado y env´ıo de formularios), dejando al usuario la responsabilidad de realizar las otras acciones sin ning´ un tipo de asistencia por parte del browser. Desde la extracci´on de datos relevantes hasta el procesamiento que pueda necesitar realizarse sobre esos datos, el usuario que utiliza browsers es quien debe encargarse de todo.

70

Cap´ıtulo 3 Estado de la cuesti´ on En este cap´ıtulo se realiza un repaso de los principales conceptos y t´ecnicas desarrolladas hasta el momento en el ´ambito de la integraci´on de datos semiestructurados, as´ı como de otras t´ecnicas, no ya de automatizaci´on de tareas en el Web, sino, m´as gen´ericamente, de navegaci´on autom´atica en el Web.

3.1.

Consideraciones previas

Antes de comentar esos trabajos aplicados al tema espec´ıfico de la automatizaci´on de tareas en el Web, conviene mostrar c´omo algunos sitios Web afrontan actualmente el uso de sus aplicaciones. Algunos sitios Web, muy pocos en t´erminos relativos, proporcionan aplicaciones ejecutables alternativas a los browsers para proporcionalidad una mayor facilidad de manejo a aquellos usuarios que realizan un n´ umero elevado de transacciones. En estos casos, lo habitual suele ser que los desarrolladores de la aplicaci´on proporcionen al usuario una forma de acceso indirecto a la aplicaci´on con la que interact´ uan de forma que el interfaz no est´e basado en el browser, sino que en un programa ejecutable capaz de automatizar varias de estas transacciones minimizando parcial, pero sensiblemente, la interactividad solicitada al usuario. Por ejemplo, eBay [6] o el antiguo QXL (recientemente fusionado con Aucland [1]) han proporcionado a sus mejores vendedores una aplicaci´on ejecutable (para uso exclusivo en entornos Windows) que permite la publicaci´on de m´ ultiples subastas en la red con un s´olo click 71

de rat´on. Por otro lado, algunas operadoras de contrataci´on de acciones en bolsa, como por ejemplo Consors [4] proporcionan a sus clientes una interfaz Java (normalmente un applet ejecutable en el navegador) para facilitar a sus usuarios m´as activos una plataforma de introducci´on de ´ordenes de compra-venta m´as manejable que el browser cuando se trata de un n´ umero elevado de operaciones o se requieren algunas funcionalidades como informaci´on en tiempo real. Si bien la elecci´on de la plataforma tecnol´ogica puede ser muy dispar (existen igualmente soluciones basadas en controles ActiveX y otras variantes), lo cierto es que este tipo de aplicaciones a veces no proporcionan una funcionalidad completa, ya que en ocasiones se limitan las opciones de la versi´on interactiva basada en HTML y en la comunicaci´on a trav´es del browser, por lo que f´acilmente pueden no contemplar todas las funcionalidades que desean los usuarios. Por otro lado, muchas de las p´aginas que necesitan ser accedidas, no tienen una interfaz especialmente amigable cuando se les usa desde otro tipo de browser distinto a aqu´el para el que han sido dise˜ nadas. Dicho de otra forma, sus p´aginas son poco accesibles. En cualquier caso, pocos dise˜ nadores de sitios Web est´an dispuestos a facilitar que sus p´aginas sean navegadas por programas automatizados (robots) en lugar de por personas usando browsers. Sin duda influyen m´as razones sociol´ogicas (miedo a perder atracci´on en la publicidad, miedo a que los contenidos propios sean aprovechados por terceros para hacer negocio sin que el verdadero propietario reciba beneficios, ...) que t´ecnicas (miedo a ver sobrecargada la capacidad de respuesta de los servidores).

3.2.

Automatizaci´ on de aplicaciones interactivas

Sin duda, estos problemas (el de la menor funcionalidad de las opciones no interactivas de las aplicaciones y el de la baja amigabilidad del interfaz de algunas aplicaciones) afectan al ´ambito de la automatizaci´on, pero no s´olo a la del Web, sino, en general, al de cualquier aplicaci´on dise˜ nada para ser usada de forma interactiva. Dado que la problem´atica de la automatizaci´on de aplicaciones interactivas [149] es anterior al nacimiento del mismo Web, conviene sin duda analizar algunas de sus conclusiones m´as relevantes para aprovechar as´ı la experiencia desarrollada. 72

3.2.1.

Lenguaje Expect

Aunque existen m´ ultiples trabajos enfocados en la automatizaci´on de aplicaciones interactivas en varios entornos, de todos ellos destaca sin duda expect [84]. En expect, mediante la utilizaci´on de un nuevo lenguaje de scripting espec´ıfico similar al de un shell, se permite realizar f´acilmente el control de programas interactivos lanzados en entornos Unix que est´en preparados para leer del teclado de una terminal. A diferencia de una shell normal, expect resulta especialmente u ´til para emular al usuario desde el teclado cuando este tipo de fuente de datos no puede ser f´acilmente redireccionado a un fichero para lectura o cuando es necesario responder adecuadamente a un prompt en un di´alogo con la aplicaci´on interactiva, con peticiones del programa y respuestas que deben introducirse por teclado en el momento en el que el programa interactivo las solicita. Tal y como reza en ese trabajo, los tradicionales shells Unix tienen, sobre las aplicaciones que invocan, un control que se limita a la creaci´on, espera y destrucci´on de procesos, as´ı como las opciones con las que deben ser invocados al principio y el redireccionamiento a/desde ficheros pero no tienen apenas control sobre aquellos programas que necesitan interactividad durante su ejecuci´on, dejando esa tarea relegada a que el usuario introduzca esos datos desde teclado. Mediante una filosof´ıa de lanzamiento de ejecuciones similar a la de los shells, pero con extensiones para controlar la ejecuci´on interactiva de estos programas, aplicaciones que hasta ese momento s´olo pod´ıan usarse de forma interactiva, como telnet, ftp, passwd, rlogin, crypt, fsck, sudo o incluso otras para las que pod´ıa emular al usuario ante otro usuario, como por ejemplo talk, y en general, cualquier aplicaci´on (incluyendo las que se pudiera construir el usuario por su cuenta) que pudiera ser usada de modo interactivo desde teclado, pueden ser controladas autom´aticamente desde un programa capaz de entender y proporcionar los datos que cada una de esas aplicaciones muestran y solicitan del usuario de forma interactiva. Para ello, se emula al usuario sustituy´endolo por la aplicaci´on de un conjunto de reglas condicionales capaces de detectar los distintos casos de peticiones esperables por las aplicaciones interactivas y as´ı asociar a cada regla un conjunto de acciones de respuesta. El lenguaje desarrollado en ese trabajo, llamado expect, actualmente instalado en muchas distribuciones de sistemas Unix, est´a basado en la sintaxis de TCL [97] y, entre las conclusiones reflejadas en [84] destaca, para ilustrar su uso con un ejemplo, como el script de la figura 3.1, dise˜ nado para controlar mediante el di´alogo interactivo con la aplicaci´on Unix ftp el acceso a un sitio ftp an´onimo, sustituy´o a un programa equivalente (que hac´ıa lo mismo) es73

crito en lenguaje C, pero que ten´ıa un tama˜ no aproximado de 60K. El script de la figura 3.1 espera a recibir la palabra Name del programa ftp antes de enviarle la palabra anonymous de la misma forma a la que espera a estar identificado correctamente antes de lanzar una petici´on de transferencia de ficheros. #! /usr/bin/expect -f spawn ftp [index $argv 1] expect "*Name*" send "anonymous\r" expect "*Password:*" send [exec whoami] expect "*ok*ftp>*" send "get [index $argv 2]\r" expect "*ftp>*"

Figura 3.1: Script Expect para controlar ejecuci´on interactiva de ftp Quiz´a lo m´as llamativo de expect como lenguaje sea sin duda la gran diferencia de tama˜ no existente entre la soluci´on escrita en ´el y la escrita en C, ambas para solucionar el mismo problema. La diferencia de tama˜ no se puede justificar en el hecho de que C es un lenguaje de programaci´on imperativo de uso gen´erico, mientras que expect es un lenguaje de scripting de alto nivel de programaci´on y orientado al mantenimiento del control del di´alogo con cualquier aplicaci´on y capaz de proporcionar distintas respuestas a la aplicaci´on dependiendo de lo que ella muestre a su salida. expect es, por lo tanto, un claro ejemplo de lenguaje con un nivel de abstracci´on lo suficientemente elevado como para poder ser usado casi a nivel de especificaci´on de requisitos. Sin embargo, un lenguaje para la automatizaci´on, pese a que disponga de un alto nivel de abstracci´on, para poder ser aplicable a cualquier herramienta interactiva, debe ser capaz de controlar aspectos de bajo nivel. Para mostrar la flexibilidad del lenguaje expect en este sentido, el script de la figura 3.2 ilustra la capacidad de emulaci´on de un usuario ficticio capaz de dialogar con otro (en un di´alogo muy sencillo, pero que podr´ıa ser f´acilmente adaptable) mediante el uso de la conocida herramienta talk de entornos Unix. El nivel de control de talk en este caso llega incluso a controlar aspectos como un modelo de tiempos variables entre pulsaciones de las teclas, dando al usuario que est´a al otro extremo de la comunicaci´on la ilusi´on de que realmente est´a dialogando con una persona pese a que en realidad no deja de ser un programa que emula a un usuario. No ya en una aplicaci´on como talk sino en cualquiera donde el n´ umero de posibles salidas pueda ser conocido, un conjunto completo de reglas y acciones que act´ uen en consecuencia pueden 74

automatizar completamente la gesti´on de una aplicaci´on 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 ejecuci´on 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 abstracci´on Con orientaci´on al di´alogo con aplicaciones existentes Que reduce sustancialmente el tama˜ no y, por lo tanto el esfuerzo para crear y mantener, de aplicaciones capaces de automatizar a otras Capaz de automatizar pr´acticamente cualquier aplicaci´on interactiva textual (no gr´afica) Capaz de analizar la informaci´on que proporcionan las aplicaciones interactivas y estructurar su comportamiento bas´andose en esos casos Capaz de asociar acciones a cada uno de los casos que se espera que proporcione la aplicaci´on interactiva Capaz de permitir al usuario gran flexibilidad para que defina sus propias reglas y sus propias acciones Capaz de emular al usuario controlando aspectos de bajo nivel Basado en la sintaxis de alg´ un est´andar conocido Estas caracter´ısticas han sido tenidas en cuenta para la automatizaci´on de tareas en el Web en el apartado 6. 75

3.3.

Web Sem´ antico

Uno de los grandes problemas del Web actual, desde el punto de vista de su procesamiento automatizado, es que est´a basado principalmente en HTML (formato dif´ıcil de entender por las m´aquinas al estar muy orientado a la mera visualizaci´on conforme al apartado 1.4.3). Teniendo esto en cuenta junto al hecho de que se espera que XML a´ un tarde varios a˜ nos en implantarse como formato para los documentos en el Web, desde el W3C se ha estado promoviendo en los u ´ltimos a˜ nos una ambiciosa iniciativa denominada el Web Sem´antico [32]. El objetivo del Web Sem´antico es el de permitir la navegaci´on automatizada por parte de programas capaces de entender el significado de los datos que aparecen en las p´aginas del Web, gracias al hecho de que a ´estas les acompa˜ nan 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 p´aginas Web. Las p´aginas as´ı descritas con los correspondientes metadatos pueden ser asimilables a bases de datos procesables por cualquier tipo de programa. As´ı pues, un agente inteligente basado en motores de inferencia capaces de procesar los metadatos descriptivos de una p´agina puede encontrar para el usuario la informaci´on que satisfaga sus requisitos de b´ usqueda con un mayor criterio que la simple b´ usqueda por palabras clave, cuando se busca en un conjunto de p´aginas unidas entre s´ı por hiperenlaces. Siendo el Web Sem´antico una opci´on realmente prometedora para el futuro del Web y de la construcci´on din´amica de caminos de navegaci´on, guiada por la consecuci´on de objetivos, lo cierto es que todav´ıa es una tecnolog´ıa incipiente a la que a´ un le falta por demostrar sus capacidades en entornos complejos, habiendo s´olo sido probada en entornos sencillos como [102]. En [64] se cuestiona c´omo un Web din´amico puede tener asociadas p´aginas de metadatos est´aticas, estableciendo diferencias entre las sem´anticas est´aticas de estos ficheros declarativos creados aparte por personas y las sem´anticas din´amicas necesarias para manejar los datos del Web, que normalmente se dan en el contexto de un lenguaje de programaci´on, abogando as´ı por soluciones no precisamente declarativas. Por otro lado, las necesidades de los usuarios son mucho m´as complejas que aquellas a las que puede dar respuesta un buscador. Una vez delante de la p´agina en la que debe empezar a trabajar, es necesario desarrollar una tarea cuyos pasos son normalmente conocidos por los usuarios y no es necesario que sean deducidos. En lugar de definir programas envoltorio, com´ unmente conocidos como 76

wrappers para cada fuente de datos accedida, el Web Sem´antico propone la utilizaci´on de programas de navegaci´on gen´erica capaces de autoprogramar su navegaci´on a cualquier sitio Web conforme a la informaci´on suministrada por los metadatos de ese sitio Web. Ello supone, en la pr´actica, delegar cualquier automatizaci´on de tareas en la construcci´on de una adecuada metainformaci´on de un sitio Web, capaz de dirigir el comportamiento de estos programas de navegaci´on gen´erica por ese Web de forma similar a la que lo navegar´ıa un programa envoltorio. El Web Sem´antico est´a en un estado a´ un inmaduro y carece del soporte necesario de muchas herramientas. Por otro lado, la mayor´ıa de las p´aginas del Web tambi´en carecen de los correspondientes metadatos, y eso es algo que tardar´a tiempo en paliarse aun cuando el Web Sem´antico recale en la construcci´on de Webs. Por todo ello, es previsible que la utilizaci´on de las t´ecnicas del Web Sem´antico tardar´an a´ un bastante tiempo en poder explotarse masivamente en Internet para la automatizaci´on de tareas en el Web.

3.4.

Mecanismos de construcci´ on de programas de navegaci´ on automatizada

Los siguientes trabajos abordan de una u otra medida el tema de la automatizaci´on de la navegaci´on en el Web. En buena parte de los proyectos en los que se desarrollan trabajos para la especificaci´on de aplicaciones para la Web, la gran mayor´ıa de los esfuerzos se vuelcan en la especificaci´on de aplicaciones accesibles desde el Web que sean funcionales y no produzcan errores a sus usuarios. Ejemplos de esta alternativa son XL [59] y Dicons [27] donde se definen lenguajes de especificaci´on para la Web, pero en el lado del servidor, no en el lado de un cliente que desee automatizar el uso de esas mismas aplicaciones. Otros trabajos, como WebML [50] intentan aplicar el modelo Entidad-Relaci´on de las bases de datos relacionales a ciertas p´aginas del Web. Tal modelado resulta enriquecedor en el sentido de que aporta una visi´on muy descriptiva y detallada del esquema de datos usado al publicar muchas de las p´aginas Web existentes hoy en d´ıa. Sin embargo, estas aproximaciones no son utilizables en los casos en los que las p´aginas y los datos contenidos en las mismas no siguen unas normas establecidas asimilables a las de un modelo Entidad-Relaci´on. WebML se presenta como una aportaci´on desde el punto de vista de los dise˜ nadores Web y de la publicaci´on estructurada y descriptiva de las p´aginas, sin abordar el tema de la integraci´on de datos semiestructurados por parte 77

de sus usuarios o lectores. Ya en el terreno del desarrollo de clientes Web que naveguen autom´aticamente, las herramientas m´as usadas para la automatizaci´on de la navegaci´on de enlaces en el Web suelen ser programas completos (disponibles con m´ ultiples opciones de ejecuci´on) para descargar documentos del Web o realizar otro tipo de acciones sencillas desde la Web superficial. Muy usado en este sentido es Wget [20], pese a que s´olo sirve para descargar documentos. Algunas herramientas como Curl [5] permiten un uso m´as avanzado al ofrecer al usuario la posibilidad de manejar tambi´en formularios adem´as de enlaces, eso s´ı, solicitando al usuario datos de bajo nivel como el query-string que se debe enviar, en lugar de crearlo ´el a partir de una estructura de datos que represente a un formulario relleno. Estas u ´ltimas no ofrecen la posibilidad de recibir establecido el gui´on de una sesi´on completa HTTP m´as all´a de una sola transacci´on, por lo que la secuencia de acciones de la tarea s´olo puede ser especificada desde fuera de la herramienta, mediante llamadas a la misma, t´ıpicamente en un lenguaje de int´erprete de comandos (shell) del propio sistema operativo, y siempre que no sea necesario el manejo de aspectos de bajo nivel, como son las cookies [95]. Algunas herramientas, como Veriweb [30], s´ı son capaces de seguir m´as de un enlace y formulario en una u ´nica ejecuci´on, pero se limitan a realizar pruebas de ejecuci´on sobre herramientas accesibles desde el Web, siguiendo sus enlaces y testeando que los caminos o tareas que cada una de esas aplicaciones permite realizar desde cada una de sus p´aginas no produzca errores en la aplicaci´on del servidor ni provoque que al cliente le lleguen p´aginas de error (que son indeseables para muchos sitios comerciales porque menguan futuras visitas al site). En cualquier caso, no permiten al usuario la automatizaci´on de una tarea concreta, sino que recorren todos los caminos encontrables probando con distintos datos para rellenar los formularios, por lo que sus algoritmos de fuerza bruta no resultan adecuados para la automatizaci´on de tareas condiderables de utilidad para los usuarios. Por otro lado, existen varias bibliotecas [39, 35, 23, 112, 118] sobre varios lenguajes de programaci´on (Prolog, Perl, Java, C, ...) que s´ı permiten la ejecuci´on de una secuencia preprogramada de transacciones Web, combinada a su vez con la extracci´on de datos desde documentos XML obtenidos por la red. En ocasiones, m´as que bibliotecas para alg´ un lenguaje de programaci´on, se proponen lenguajes propiamente de consulta para el Web [26, 51, 37, 93, 85]. Sin embargo, la gran mayor´ıa de estas bibliotecas o lenguajes no permite el di´alogo con servidores del Web legado por su falta de manejo de ciertas acciones impl´ıcitas que realizan los browsers sin que el usuario sea

78

consciente de ello, como las mencionadas en el apartado 2.1. Tambi´en suelen aplicar t´ecnicas de extracci´on de datos como son las expresiones regulares y la definici´on de analizadores l´exicos que tratan a esas p´aginas como texto plano, sin estructura y que han sido utilizadas en trabajos como [47, 46, 57, 49, 100, 99, 98, 48, 45, 88]. Sin embargo, ninguna de estas soluciones propone una extracci´on de datos semiestructudados basada en XPath. A lo sumo, algunas de ellas, como [29, 80] definen sus propias primitivas de extracci´on de datos, pero en ning´ un caso basadas en el est´andar del W3C. Otras t´ecnicas, como [81, 54, 80] resuelven bien la parametrizaci´on de acciones impl´ıcitas (ver apartado 2.1). Sin embargo, dejan no muy bien cubiertos desde el punto de vista de la mantenibilidad, aspectos tan importantes como lo es la extracci´on de datos del Web, una vez que la p´agina que contiene finalmente los datos ha sido recuperada. Desde el punto de vista de las aportaciones hechas por el W3C, varias t´ecnicas, como XSLT [130] o DEL (Data Extraction Language) [133] han sido propuestas para la obtenci´on en formato XML de datos extra´ıbles de otros documentos XML mediante reglas de extracci´on y transformaci´on. Ambas definen etiquetas para crear f´acilmente lenguajes de script que sean f´acilmente interpretables. Sin embargo, carecen de mecanismos para indicar la forma de obtenci´on 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 programaci´on sobre sintaxis XML en donde hay etiquetas capaces de representar variables, bucles, condiciones, y otros tipos de acciones. Este tipo de lenguajes de programaci´on, definidos sobre esta sintaxis es f´acilmente interpretable por varios programas y muy f´acilmente analizable. En el W3C, el tema de la extracci´on de datos se ha centrado u ´ltimamente en la definici´on del lenguaje de consulta XQuery, una extensi´on de XPath 2.0 (en realidad un superconjunto) que permite la consulta para la extracci´on de datos de cualquier documento XML, con funcionalidades avanzadas similares a las de otros lenguajes de consulta de bases de datos relacionales, como SQL [78]. Sin embargo, estas iniciativas, pese a que ofrecen muy buenas soluciones para ese problema (de hecho ´esa es la raz´on por la que en esta tesis se haya partido de XPath 2.0 para crear un lenguaje de consulta y manipulaci´on), no se enfrentan al tema de c´omo obtener los documentos XML del Web ni tampoco acerca de c´omo integrar los datos que aparezcan repartidos en distintos documentos. De entre los u ´ltimos proyectos m´as avanzados para ser aplicados al Web legado, puede destacar [94, 111], en el que se aplican modernas t´ecnicas de 79

extracci´on de datos semiestructurados a las p´aginas HTML, a p´aginas corregidas con Tidy [104]. En [94] se usa XSLT y en [111, 25] se considera al Web como una base de datos lo suficientemente estructurada como para poder usar lenguajes de consulta de bases de datos como XQL, un lenguaje de consulta predecesor de XQuery. Gracias a herramientas como Tidy, algunos usuarios pueden usar herramientas de evaluaci´on de expresiones XPath como [21] sobre el Web legado. Sin embargo, tres importantes factores no han sido tenidos suficientemente en cuenta por estos trabajos. En primer lugar, no solventan adecuadamente las dificultades que afronta escoger XSL como lenguaje de manipulaci´on de datos (se generan documentos de salida en lugar de manipular el ´arbol del documento y permitir el almacenamiento de sus partes en repositorios programables). En segundo lugar, no incorporan mecanismos de mejora a la robustez ante fallos, como los muy convenientes Service Combinators [40], siendo poco adecuados para la extracci´on de datos en p´aginas con estructuras de marcado cambiantes e irregulares. En tercer lugar, ninguno tampoco se ha enfrentado a´ un al uso del nuevo borrador de XPath 2.0 definido por el W3C para este fin, que incluye muchas e importantes mejoras respecto de la versi´on actual del est´andar que sali´o a la luz en 1999. Otros trabajos, como RoadRunner [55], pretenden aplicar algoritmos para generar autom´aticamente wrappers a partir de documentos de entrada. Pese a que ello supone un interesante enfoque capaz de minimizar los problemas de la generaci´on manual y del mantenimiento de estos wrappers, la casi total falta de estructura esperable en los documentos del Web provocan que este tipo de soluciones s´olo funcionen adecuadamente con ejemplos muy sencillos y muy regulares en su estructura, lo cual no siempre se puede es f´acilmente encontrable en las aplicaciones del Web cuyo uso se desea automatizar. Finalmente, uno de los m´as completos trabajos realizados hasta el momento en el campo de la integraci´on de datos en el Web corresponde sin duda a [31], donde se tienen en cuenta muchos factores adecuadamente escogidos que facilitan el desarrollo de programas envoltorio por personas con pocas capacidades de programaci´on. Una herramienta de f´acil utilizaci´on permite dotar a estos programas de la conveniente robustez ante cambios en las p´aginas, minimizando los costes de su mantenimiento. En ese trabajo, dos lenguajes han sido desarrollados y soportados para dos prop´ositos bien distintos, pero complementarios entre s´ı: la obtenci´on de documentos del Web 80

(mantenimiento del di´alogo en una sesi´on HTTP con servidores Web) y la extracci´on de datos relevantes de cada uno de esos documentos. El primero de los lenguajes, NSEQL, es un lenguaje de alto nivel de abstracci´on en el que se indica la secuencia fija y preestablecida de acciones que deben activarse en un m´odulo navegador, una tras otra, para obtener del Web los documentos involucrados en una tarea. En dicha secuencia de acciones, se hace t´ıpicamente una referencia impl´ıcita al elemento o documento activo seleccionado por alguna acci´on anterior, de forma que, adem´as de las acciones de seguimiento de enlaces, env´ıo de formularios y rellenado del valor de sus campos, se contemplan otras m´as propias de la orientaci´on a un browser como la focalizaci´on de documentos, formularios o elementos que quedan seleccionados como activos para que las siguientes acciones los puedan tomar como referencia. Otro lenguaje, llamado DEXTL se encarga de extraer los datos relevantes de cada una de esas p´aginas, de forma que el uso combinado de ambos lenguajes permite la automatizaci´on de pr´acticamente casi cualquier tarea en el Web. Sin embargo, algunas caracter´ısticas de estos lenguajes podr´ıan ser mejorables. Para empezar, DEXTL es un lenguaje desarrollado para un generador de analizadores l´exico-sint´actico propio, basado en expresiones regulares y en reglas gramaticales que indican la estructura esperada del texto para ser as´ı correctamente reconocido y de esa forma poderle aplicar las correspondientes reglas de extracci´on de datos. Una opci´on quiz´a m´as interesante, podr´ıa haber sido la de aplicar tecnolog´ıas como XPath para poder seleccionar adecuadamente los nodos relevantes del documento. Ello supondr´ıa cierta p´erdida de flexibilidad (XPath no podr´ıa ser aplicable a cualquier fichero de formato textual, como DEXTL s´ı lo permite), pero habr´ıa proporcionado quiz´a un mayor grado de robustez a las expresiones de extracci´on de datos en documentos HTML, puesto que una expresi´on XPath ocupa t´ıpicamente una u ´nica l´ınea de c´odigo f´acilmente entendible, en lugar de las varias que se necesitan para poder crear una expresi´on DEXTL equivalente. Por otra parte, el API de primitivas desarrolladas para NSEQL est´a demasiado particularizado para los eventos propios de un navegador. Pese a que proporcionan un avanzado esfuerzo por representar adecuadamente en el correcto nivel de abstracci´on las acciones que forman parte de la secuencia de eventos que un usuario genera con un browser durante un proceso de navegaci´on, es decir de acciones b´asicas como las mencionadas en la tabla 2.5, este API podr´ıa haber sido un poco 81

m´as simplificado, ortogonalizado para hacerlo independiente de los elementos concretos de HTML y sus posibles eventos, y reorientado a la robustez. Dado que NSEQL no se basa en un modelo de datos como el de XPath, sino en los elementos y documentos activos que un navegador puede tener en cada momento, muchas de las funcionalidades del API se basan en la aplicaci´on de alg´ un evento a alg´ un tipo concreto de elemento o atributo de HTML. Existe una funci´on para seguir enlaces de anchors, que sin embargo no sirve para seguir enlaces de otro tipo de elementos, como areas (es decir, mapas de im´agenes), que tambi´en tienen enlaces que a veces interesa poder seguir. La existencia de una referencia impl´ıcita al elemento o documento previamente seleccionado, y la ausencia de asociaci´on expl´ıcita de nombres a las p´aginas previamente visitadas, impide, por ejemplo, que una misma p´agina visitada con anterioridad a la p´agina actual pueda ser reutilizada sin tener que abandonar el contexto de la actual. Por ejemplo, dentro de un bucle en el que ciertas p´aginas con formularios deban ser revisitadas para emprender con ellas el procesamiento de un nuevo conjunto de datos en una labor repetitiva, resulta necesario emular la acci´on Back del navegador, que puede implicar traerse una nueva versi´on de la p´agina en lugar de reutilizar la que previamente hab´ıa sido obtenida. Por otro lado, buena parte de las funciones del API necesitan recibir combinaciones de tres datos, t´ıpicamente un texto, un booleano y un n´ umero entero, indicando que se desea escoger el en´esimo elemento de una lista de posibles que cumplan el tener al texto, bien contenido de forma exacta, bien contenido como subcadena, bien como texto, bien quiz´a en alg´ un atributo concreto, todo ello dependiendo del argumento booleano y del nombre concreto de la funci´on a la que se invoque. Dicho de otro modo, existen funciones para buscar elementos por texto o por algunos atributos, pero no para seleccionar elementos que cumplan una combinaci´on arbitraria de cualquier nivel de complejidad con varios de ellos, abstray´endose de nombres concretos de etiquetas o atributos particulares de HTML, como s´ı permiten los predicados de XPath. Por otro lado, el rellenado de formularios se plantea igualmente con un conjunto predefinido de funciones, cada una de las cuales permite realizar una acci´on concreta y predefinida sobre un tipo concreto de campo de formulario, cuando ser´ıa mucho m´as simple y flexible, aunque quiz´a tambi´en de m´as bajo nivel, permitir la modificaci´on gen´erica de cualquiera de sus atributos. Por ejemplo, una de las funciones permite 82

rellenar un campo de texto de un formulario (modificando su atributo value, se entiende). Otras funciones permiten seleccionar la opci´on de una lista de opciones posibles. Por el contrario, no existen funciones para cambiar otros tipos de atributos influyentes en los campos de formularios, como checked o disabled. En pr´acticamente casi todas las funciones, es imprescindible la indicaci´on de un n´ umero entero que indique la posici´on del elemento que se desea direccionar dentro de una lista de otros que cumplan una serie de caracter´ısticas. As´ı, por ejemplo, se puede seguir el s´eptimo enlace de una p´agina, por ejemplo. Sin embargo, el criterio de la posici´on de un elemento dentro de su p´agina es altamente sensible a cambios en las p´aginas HTML, pues en el momento en el que la p´agina del servidor a˜ nada una nueva opci´on a la lista de opciones, las posiciones de ´estas se ve irremediablemente trastocada, provocando que en la labor de mantenimiento de estos programas se deba proceder a la actualizaci´on de estos valores num´ericos. Una selecci´on basada en contenidos independientes de posiciones es m´as robusta o, en cualquier caso, m´as f´acilmente mantenible. En cualquier caso, el API est´a m´as orientado a los eventos que espera recibir un browser gr´afico como lo es Microsoft Internet Explorer, que al propio di´alogo HTTP que espera el servidor al que se accede remotamente, puesto que no se dialoga directamente con el servidor sino que de delega esta labor a este browser concreto. Sin embargo, el uso de un browser gr´afico en la plataforma de ejecuci´on le aporta una indudable ventaja: y es que este sistema tiene incorporada la ejecuci´on de rutinas JavaScript, algo que no tienen todas las plataformas de navegaci´on automatizada.

3.4.1.

Uso de APIs est´ andares

Por otro lado, programar con APIs est´andares tampoco es una garant´ıa de ´exito si ello implica la utilizaci´on inadecuada de la tecnolog´ıa. Por ejemplo, en [115] se explica lo dificultoso que puede ser realizar un programa Java que extraiga datos de un documento XML tan sencillo como el de la figura 3.3. Un programa Java que use DOM y quiera extraer las direcciones (elementos address) de aquellas personas que coinciden con su argumento puede ser el que aparece en la figura 3.4. Teniendo en cuenta que existe una expresi´on XPath //address[child::addressee[text() = ’Jim Smith’]] capaz de 83

John Smith 250 18th Ave SE Rochester MN 55902 Bill Morris 1234 Center Lane NW St. Paul MN 55123

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

Figura 3.6: Hoja XSLT que extrae datos de documento XML

86

3.5.

Conclusiones del estado de la cuesti´ on

La tabla 3.1 refleja un resumen de las tecnolog´ıas mencionadas en este cap´ıtulo, comparando unas con otras respecto a varios criterios comunes. La primera columna corresponde a las soluciones ad hoc, como [26, 51, 37, 93, 85], basadas en expresiones regulares y en plataformas creadas espec´ıficamente para resolver problemas concretos. La segunda columna se corresponde con la opci´on de usar un parser gen´erico tipo DOM al estilo del empleado en la figura 3.4, utilizable en una biblioteca utilizable desde un lenguaje de programaci´on. La tercera columna, muy similar a la segunda, refleja la opci´on de usar JavaScript circunscribi´endose a un browser, en tanto que tambi´en usa DOM, salvo que con otra sintaxis distinta a la de Java. La cuarta opci´on se corresponde con plataformas al estilo de Xalan [62], es decir, parsers tipo DOM pero capaces de evaluar expresiones XPath, lo cual simplifica mucho la labor de programaci´on, tal y queda reflejado en la figura 3.5. La quinta columna, se corresponde con la opci´on de usar WebL [80] y la sexta se corresponde con los resultados de esta tesis a efectos comparativos.

Ad hoc

Parser

JavaScript

Xalan

WebL

XPlore

Est´ andar

Exp. Reg.

DOM

DOM

XPath+DOM

No

MSC+XPath

Extracci´ on

Bajo

Bajo

Alto

Alto

Alto

Alto

Navegaci´ on

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

Localizaci´ on

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 extracci´on de datos presenta un bajo nivel de abstracci´on cuando se emplean expresiones regulares o un parser tipo DOM sobre lenguajes de programaci´on convencionales (salvo la contada excepci´on de JavaScript). A pesar de que todas las opciones presentan un nivel de abstracci´on adecuado para representar las acciones navegacionales del protocolo 87

HTTP, pocas de ellas ofrecen un buen soporte a los aspectos de m´as bajo nivel de dicho protocolo (acciones impl´ıcitas mencionadas en el apartado 2.1), por lo que no son utilizables para el establecimiento de sesiones con servidores Web. Por otro lado, aunque de uno u otro modo, sea posible la utilizaci´on de rutinas de usuario para las acciones m´as complejas, no siempre es posible definir de forma simple el comportamiento en las acciones m´as sencillas. Por ejemplo, las soluciones ad hoc suelen basar casi todo su funcionamiento en rutinas definibles por el usuario. En cuanto a la robustez ante fallos en la conexi´on, pocas opciones ofrecen mecanismos de recuperaci´on ante fallos. Por otro lado, la facilidad de localizaci´on de las zonas de c´odigo afectadas por un posible cambio en la estructura de las p´aginas puede ser complicada si se usa un parser tipo DOM, (debido al alto n´ umero de l´ıneas de c´odigo involucradas en cada acci´on) teniendo en cuenta, no obstante, que su legibilidad suele ser, pese a esa verbosidad, aceptable. Algo completamente distinto suele ocurrir con las expresiones regulares, que suelen concentrar en una zona de c´odigo muy concreta el lugar afectado por un cambio en las p´aginas, aunque sin embargo proporcionan una mala legibilidad de las mismas debido a su bajo nivel de abstracci´on. Finalmente, unas u otras opciones son aplicables a cualquier formato, tanto HTML del Web legado como XML, pudiendo requerir para ello herramientas externas como [104]. Como resumen, las soluciones actuales mencionadas en este cap´ıtulo adolecen de uno o varios de los siguientes problemas:

No basadas en est´ andares La mayor´ıa de los trabajos relacionados suelen afrontar el problema de la integraci´on de datos semiestructurados desarrollando lenguajes ad hoc para prop´ositos espec´ıficos, cada uno de ellos adaptado a sus propios prop´ositos espec´ıficos. La gran mayor´ıa de ellos suelen estar basados en analizadores l´exicos basados en expresiones regulares, aplicadas sobre los documentos como si fueran ficheros de texto plano, ignorando la estructura l´ogica de marcas del documento, al contrario que como ocurre con la utilizaci´on de otros est´andares conocidos. Muchos de estos proyectos, o bien han sido abandonados, o bien han tenido poco ´exito o repercusi´on en la comunidad, o bien est´an siendo explotados bajo un elevado coste de mantenimiento. Por el contrario, una soluci´on basada en est´andares resulta m´as f´acilmente mantenible debido a una mayor legibilidad y un mayor nivel de difusi´on. 88

Bajo nivel de abstracci´ on Los trabajos que s´ı suelen optar por una soluci´on basada en est´andares suelen muchas veces tropezar con una inadecuada elecci´on de la tecnolog´ıa que va a utilizar. As´ı pues, de los proyectos relacionados que s´ı han optado desde un principio por la utilizaci´on de est´andares XML en sus desarrollos, la gran mayor´ıa ha escogido usar tecnolog´ıas como SAX [86], DOM [131] (o similares) [77, 72] o XSLT [130]. Cada una de estas tecnolog´ıas presenta diferencias importantes en cuanto a la potencia, eficiencia y nivel de abstracci´on. Por ejemplo, SAX tiene un nivel de abstracci´on muy bajo pero eficiente (´ util para tareas sencillas sobre datos voluminosos), mientras que el de XSLT es m´as elevado. Por otro lado, DOM resulta ser la t´ecnica m´as potente de las tres, pero tambi´en la que requiere m´as conocimientos y experiencia, y por lo tanto, dedicaci´on y recursos. XSLT, dise˜ nado como un lenguaje de especificaci´on de transformaciones y, pese a su gran aceptaci´on, resulta demasiado sofisticado y verboso cuando las reglas de transformaci´on que maneja adquieren un poco de complejidad (muchos bucles, variables tipadas, condicionales y expresiones calculando valores temporales para ciertos c´alculos), en cuyo caso un lenguaje de programaci´on imperativo puede ser mejor opci´on. En cualquier caso, estas tres tecnolog´ıas adolecen de un mismo problema, y es que todas ellas comparten el hecho de requerir varias l´ıneas de c´odigo para una operaci´on que en principio podr´ıa ser considerada como sencilla.

Baja escalabilidad Los sistemas desarrollados hasta el momento no intentan minimizar la complejidad del c´odigo particularizado de acceso a los servidores Web (c´odigo envoltorio) [83], por lo que los sistemas desarrollables con estas t´ecnicas resultan ser muy poco escalables, es decir, muy costosos de desarrollar y mantener en cuanto el n´ umero de servidores a los que se accede crece.

Baja adaptabilidad ante cambios Los sistemas desarrollados hasta el momento no intentan favorecer, en las aplicaciones desarrollables con ellos, la adaptabilidad ante cambios en las p´aginas del Web. Por esa raz´on, es com´ un, que estas aplicaciones desarrolladas con estas t´ecnicas acaben dejando de funcionar por la aparici´on de peque˜ nos y frecuentes cambios, muchos de ellos incluso imperceptibles para los usuarios si se accede con un browser. 89

Limitaciones en la capacidad de construcci´ on Buen n´ umero de funcionalidades, principalmente acciones impl´ıcitas necesarias para mantener correctamente la sesi´on con servidores Web, no est´an completamente contempladas por la gran mayor´ıa de plataformas de desarrollo existentes, por lo que muchos programas desarrollados acaban por no poderse utilizar de forma efectiva en numerosos servidores del Web legado. Alto coste de mantenimiento Los productos tienen una vida corta, normalmente hasta que el Web al que acceden cambie algo que rompa con las suposiciones establecidas impl´ıcitamente por el programador del c´odigo envoltorio, por lo que necesitan ser revisados cada poco tiempo, siendo adem´as costoso localizar y corregir en el c´odigo del programa el cambio que ha provocado que la aplicaci´on haya dejado de funcionar. Como el Web es un ente cambiante que evoluciona din´amicamente, resulta bastante imprevisible el momento en el que se va a detectar un fallo o el impacto que un cambio va a suponer en un algoritmo de navegaci´on. Navegaci´ on superficial El denominado deep Web [110, 105], esto es, el Web obtenible del volcado de bases de datos, est´a a´ un por explotar convenientemente, ya que los sistemas de navegaci´on existentes apenas permiten seguir enlaces f´acilmente obtenibles, como los que tienen una URL est´atica o aquellos para los que no hace falta rellenar apenas formularios.

3.6.

Limitaciones de las tecnolog´ıas actuales

Buena parte de los proyectos que abordan el tema de la automatizaci´on de la navegaci´on en el Web, al igual que este trabajo, reconociendo igualmente que quiz´as los beneficios de iniciativas como las de XML o la mejora de la accesibilidad tardar´an en poderse apreciar, plantean sus propias soluciones directamente sobre las p´aginas HTML del Web legado. Buena parte de esos trabajos plantean sus principios considerando a las p´aginas Web como ficheros de texto plano, de forma que a las p´aginas Web obtenidas se les extraen los datos aplicando patrones basados en expresiones regulares ba90

sadas en el c´odigo HTML que rodea a cada dato que se desea extraer. Si bien la aplicaci´on de expresiones regulares resulta ser una t´ecnica lo suficientemente potente como para poder ser aplicada tambi´en a otros tipos de formatos textuales, lo cierto es que las expresiones regulares resultan ser una t´ecnica de bajo nivel de abstracci´on, donde, toda vez que peque˜ nos aspectos sint´acticos tales como la aparici´on inhabitual de m´ ultiples espacios en blanco o fines de l´ınea, la ambivalencia de comillas dobles y simples, la indistinci´on de may´ usculas y min´ usculas o el orden de aparici´on de los atributos de una etiqueta hayan podido ser superados, la legibilidad de esas expresiones se complica notablemente. Por otro lado, mediante el uso de esas expresiones regulares, la estructura de ´arbol de la p´agina HTML no es considerada. Este hecho puede no suponer un problema si la estructura de la p´agina HTML y la consulta que se le desea efectuar son lo suficientemente simples. No obstante, es deseable a veces poder aplicar patrones de extracci´on de datos a determinados fragmentos espec´ıficos de la p´agina, es decir, a cierto n´ umero de sub´arboles que cumplan determinadas propiedades (porque se sabe que s´olo se desea buscar en determinadas zonas relevantes de la p´agina), en lugar de a todo el documento. Para estos casos, las expresiones regulares resultan ser bastante limitadas. Los u ´ltimos proyectos que abordan estos problemas han descubierto en la familia de especificaciones XML una tecnolog´ıa adecuada con el que poder enfrentarse al problema anterior de una forma mucho m´as elegante y robusta. Para poder aplicar este tipo de soluciones se necesita, no obstante, de un software capaz de reparar los errores sint´acticos habituales en una gran cantidad de p´aginas Web. Dichos errores sint´acticos, tales como la falta de cierre de etiquetas, el incorrecto anidamiento de las mismas o la ausencia de entrecomillado en los atributos deben ser corregidos en las p´aginas seg´ un ´estas van siendo obtenidas de los servidores. Los documentos HTML as´ı obtenidos quedan transformados en sus equivalentes documentos XHTML [117] antes de poder aplicarles cualquier t´ecnica XML. Si bien existen numerosos programas [58, 146] capaces de obtener una versi´on de la p´agina donde se cumplan los principios de buena formaci´on de XML, esto es, conforme a la sintaxis b´asica de XML, la herramienta Tidy [104] suele ser la m´as habitualmente usada. Los pocos trabajos que emplean el enfoque de reparaci´on sobre la marcha de la sintaxis de los documentos (con herramientas como [104, 58, 146]), suelen aplicar a las p´aginas Web obtenidas, una vez ya corregidas, bien parsers tipo DOM [131] sobre los que aplicar directamente c´odigo programado en lenguajes convencionales de programaci´on (t´ıpicamente Java), o bien hojas de estilo XSLT [130] para extraer de las p´aginas la informaci´on que les interesa. 91

Cuando las hojas de estilo XSLT no ofrecen toda la funcionalidad deseable para el problema que desean afrontar, estos sistemas suelen permitir la aplicaci´on de funciones de usuario escritas en alg´ un lenguaje de programaci´on convencional. Si bien la estructura declarativa de las hojas XSLT permite definir un gran n´ umero de tratamientos aplicables a los documentos XHTML de entrada, muchas veces el tratamiento aplicable a ciertas p´aginas requiere algo m´as que la simple extracci´on de datos en documentos de salida. Esa extracci´on por s´ı sola puede ser suficiente en tareas simples de recuperaci´on de informaci´on, pero es insuficiente en aquellas tareas que deban manejar estructuras de datos que recopilen datos del usuario, como son los formularios. En ocasiones resulta necesaria la manipulaci´on mediante inserci´on y borrado de nodos y/o atributos o la manipulaci´on repetida de esos atributos en un mismo documento. Los formularios Web son muchas veces un claro ejemplo que demuestra, para la tarea de ser rellenados m´ ultiples veces, la necesidad de una manipulaci´on sencilla y eficiente de peque˜ nas partes de un documento, donde la referencia de un u ´nico ´arbol accesible representativo del documento sea constantemente visible sin la necesidad de estar creando y destruyendo sub´arboles mediante la aplicaci´on de sucesivas hojas XSLT. Si bien XSLT es una soluci´on entendible por numerosos programadores, el actual borrador de XPath 2.0 [141] est´a suponiendo serios replanteamientos acerca de lo que se espera que ser´an las futuras versiones de XSLT. Gran parte de la expresividad de XSLT 1.0 est´a sustentada en la capacidad de la robusta extracci´on de datos de XPath 1.0. XPath 2.0, gracias a la incorporaci´on de nuevos operadores que no aparec´ıan en la anterior versi´on y su integraci´on dentro del marco de XQuery [142] como lenguaje de consulta, est´a constituy´endose como un potente mecanismo de direccionamiento de datos en documentos XML, suficiente por s´ı mismo como para no necesitar la funcionalidad extra de XSLT a la hora de realizar integradores de datos semiestructurados. De hecho, XPath puede considerarse, a pesar de ciertas limitaciones de las que adolece, como un mecanismo de extracci´on y direccionamiento de mayor nivel de abstracci´on que el mero uso de expresiones regulares. Una de las contribuciones de este trabajo, de hecho, consiste, aparte de una plataforma de implementaci´on que eval´ ua expresiones del borrador de XPath 2.0, en un conjunto de extensiones propuestas para extender XPath 2.0 con el fin de convertirlo en un lenguaje completamente funcional y eficaz para esta labor y otras, como la manipulaci´on de documentos. Por otro lado, buena parte de los trabajos relacionados mencionados en la bibliograf´ıa han hecho uso de clientes simples del protocolo HTTP, la mayor´ıa de ellos disponibles f´acilmente desde diversas bibliotecas o programas y en diversos lenguajes de programaci´on. Si bien la mayor´ıa de ellos son ca92

paces de proporcionar una funcionalidad b´asica aceptable, lo cierto es que muchas de las t´ecnicas actualmente empleadas por algunos servidores Web para mantener el concepto de sesi´on con los clientes que a ellos se conectan, resultan no ser tenidas en cuenta por estas soluciones. Si bien las cookies suelen tener un comportamiento gen´erico normalizado y es posible su f´acil implementaci´on en los clientes HTTP al estar bien recogidas y localizadas entre las cabeceras de este protocolo, otras t´ecnicas, como ciertos identificadores de sesi´on, que se pueden encontrar ocultos entre los par´ametros de las p´aginas Web, pueden f´acilmente hacer malfuncionar el comportamiento de un cliente HTTP que no los contemple debidamente. Dicho de otro modo, los actuales clientes HTTP utilizables para los procesos de navegaci´on autom´atica tienen un bajo nivel de soporte para el conjunto de acciones impl´ıcitas que otras herramientas como los browsers gr´aficos s´ı realizan bien. Cabe destacar que aquellos enlaces que no figuran expl´ıcitos seg´ un las habituales normas de HTML, sino que funcionan como resultado de la computaci´on de alguna rutina de JavaScript o similares, resultan especialmente problem´aticos en tanto en cuanto pr´acticamente no existe ning´ un tipo de soporte para estos lenguaje en muchos de estos clientes HTTP. Ello provoca que para muchos usuarios la u ´nica forma de acceder a determinados contenidos sea a trav´es de un browser. Existen numerosos proyectos que han abordado la tem´atica de la navegaci´on autom´atica y de la integraci´on de datos del Web a lo largo de los u ´ltimos a˜ nos. Todos ellos, incluyendo el presente, se centran en la creaci´on de wrappers o c´odigo de programa especializado en el tratamiento particularizado de cada fuente de datos. Afrontar el problema desarrollando un u ´nico programa capaz de navegar en cualquier sitio Web, capaz a su vez de solventar todas las heterogeneidades de cada servidor, resulta algo impracticable en tanto en cuanto se necesita para ello introducir sem´antica necesaria para poder autodetectar la informaci´on necesaria para la navegaci´on, manejando aspectos como sin´onimos y reconociendo al momento los enlaces que se deben seguir y los formularios (campos incluidos) que se deben rellenar, lo cual resulta demasiado complicado incluso para tareas sencillas. El Web Sem´antico es una buena alternativa que intenta basar este reconocimiento sem´antico en el uso de metadatos que permitan ser utilizados para la deducci´on acerca de c´omo efectuar las acciones b´asicas expl´ıcitas de la navegaci´on (ver apartado 2.2). Sin embargo, el Web Sem´antico a´ un tiene importantes flecos que deben resolverse, y, en cualquier caso, no parece estar enfocado al Web legado, sino a un nuevo Web creado a partir de esos metadatos.

93

94

Cap´ıtulo 4 Selecci´ on de tecnolog´ıas para la automatizaci´ on de tareas en el Web En este cap´ıtulo se realiza un an´alisis acerca de las tecnolog´ıas concretas que han sido estudiadas para ser utilizadas en este trabajo y que de alguna u otra manera han planteado alguna contribuci´on para facilitar la automatizaci´on de tareas en el Web. Todas ellas ya exist´ıan antes de la realizaci´on de este trabajo y pueden ser consideradas como est´andares en sus respectivos campos de actuaci´on, raz´on por la cual, este cap´ıtulo no presenta una contribuci´on especial a esas t´ecnicas, sino tan s´olo una breve descripci´on de las mismas. Si acaso, una contribuci´on original de este trabajo s´ı puede consistir en la adecuada combinaci´on de cada una de ellas para resolver de la mejor manera posible el problema de la automatizaci´on de tareas en el Web, pero eso es algo que aparece desarrollado en los cap´ıtulos 5 y 6. Buena parte de las ideas reflejadas en esos cap´ıtulos proceden de las tecnolog´ıas descritas en ´este. Estas t´ecnicas est´an clasificadas en un m´etodo formal (Message Sequence Charts), cinco est´andares del W3C, algunos de ellos ya evolucionados, como DOM, o XSLT (aunque existen borradores m´as avanzados de la versi´on que ha sido objeto de este estudio), otros a´ un en fase de borrador, como XPath 2.0, XPointer y XQuery, y finalmente un est´andar de facto como lo es el interfaz SAX para programaci´on sobre XML orientada a eventos. Hay que a˜ nadir que ´estas no han sido las u ´nicas tecnolog´ıas que han influido en el dise˜ no de la soluci´on propuesta en esta tesis para la construcci´on de agentes Web. Otras tecnolog´ıas como el lenguaje de programaci´on WebL o las expresiones 95

regulares con las que se pretende contemplar el vac´ıo que en ese aspecto tiene XPath, han influido igualmente realizando su propia aportaci´on.

4.1.

MSC

Los Message Sequence Charts o Cuadros de Secuencias de Mensajes son representaciones gr´aficas de especificaci´on de requisitos de dise˜ no de sistemas concurrentes y que muestran el intercambio temporizado de mensajes entre los componentes de un sistema. Los MSC constituyen representaciones abstractas, capaces de ser usadas en muy diversos ´ambitos y siendo adem´as f´aciles de entender por mucha gente, incluso no expertos. Aunque en su nacimiento, los MSC estuvieron inicialmente pensados para representar el intercambio de se˜ nales entre componentes electr´onicos de sistemas de telecomunicaciones, su incorporaci´on a los formalismos establecidos por la ITU (International Telecommunication Union) de la mano de otro formalismo bien conocido como SDL (Specification and Description Language) [75] supuso una gran aceptaci´on por muy diversos colectivos y muy variados usos, llegando a realizar importantes aportaciones al mundo de la ingenier´ıa del software, como lo demuestra su decisiva influencia sobre la representaci´on gr´afica de los diagramas de secuencia de UML [108], que pueden ser considerados como una versi´on orientada a objetos de los MSC con peque˜ nas diferencias que est´an intentando ser solventadas por las revisiones de ambas especificaciones. En esa misma referencia bibliogr´afica se apunta, por ejemplo, que los diagramas de secuencia son una particularizaci´on algo m´as pr´actica y orientada a la programaci´on con objetos, mientras que los MSC tienen un fundamento mucho m´as te´orico, vienen acompa˜ nados de una sem´antica formal y son aplicables a m´as campos que el de la orientaci´on a objetos. De hecho, los MSC pueden aplicarse en otros muchos contextos aparte de los ya contemplados por SDL. Adem´as de la importancia que conceden a la representaci´on gr´afica, los MSC incorporan la valiosa aportaci´on de poder ser representados textualmente, de forma que resultan igualmente modificables y analizables por herramientas no gr´aficas. Dicha representaci´on textual sirve de base para la definici´on de la sem´antica formal que incorporan los MSC y que les permite estar sujetos a la demostraci´on automatizada de algunas propiedades de los escenarios reproducidos, como por ejemplo la imposibilidad de que determinado mensaje A sea enviado con antelaci´on a la recepci´on de otro evento en el sistema, como la recepci´on de otro mensaje B en alg´ un otro componente o la ejecuci´on de alguna acci´on. 96

Los MSC se han convertido en una potente t´ecnica de especificaci´on del comportamiento de un sistema desde el punto de vista de las interacciones de sus componentes. Al ser f´acilmente entendible por no expertos en programaci´on, suelen formar parte de los documentos de especificaci´on de requisitos que se intercambian ingenieros y analistas con sus clientes, constituyendo una representaci´on visual muy descriptiva de la interacci´on bajo distintos escenarios entre diversos componentes, especialmente entre aquellos que forman parte de un sistema distribuido. Los MSC pueden ser usados desde los primeros pasos del dise˜ no del software, gracias a lo cual, los errores detectados mediante su uso adelantado son resueltos con un menor coste que en etapas posteriores. En los u ´ltimos tiempos se ha motivado mucho el desarrollo de algoritmos para una variedad de an´alisis de MSC consistentes en la detecci´on de condiciones de carreras, conflictos de tiempos, toma de decisiones no locales, o incluso capacidad de generaci´on de aut´omatas finitos concurrentes que simulen el sistema modelado por el MSC, por lo que son varias las herramientas utilizables para analizar los problemas derivables en etapas de dise˜ no gracias al examen de los MSC. Desde el a˜ no en el que nacieron (1992) hasta la actualidad, los MSC ha venido incorporando nuevas funcionalidades en sucesivas ampliaciones revisadas por la ITU, la entidad que lo ha estandarizado. Los MSC se han convertido en una tecnolog´ıa particularmente u ´til en el modelado de las interacciones propias de protocolos en las comunicaciones, as´ı como tambi´en para la representaci´on de llamadas a procedimientos o m´etodos, incluyendo RPC. Su inter´es ha suscitado tambi´en en los u ´ltimos tiempos, el desarrollo de herramientas capaces de transformar representaciones de MSC en otros tipos de formalismos de especificaci´on, como SDL, Statecharts [71], o Promela [73]. Incluso, los MSC ya han sido empleados como m´etodo de especificaci´on en el desarrollo de aplicaciones alojables en servidores Web, como ocurre con [27]. Los MSC presentan mejores habilidades para representar aspectos de interacci´on, intercambio de mensajes y concurrencia que otros m´etodos formales para el caso del Web frente a otros m´etodos formales como LOTOS [33], Estelle [116] or SDL [75]. A continuaci´on se mencionan los componentes m´as importantes que se pueden encontrar en un MSC.

4.1.1.

Entidades

Est´an representadas por l´ıneas verticales, y modelizan cada uno de los componentes (hardware o software) que forman parte del sistema. Las l´ıneas 97

verticales que representan a los componentes sirven a su vez como eje temporal, de forma que aquellos eventos que se representan en la parte superior del dibujo de un componente le suceden a ´este con anterioridad a los que est´an representados en las partes inferiores. Ello implica que ning´ un mensaje debe ser enviado o recibido y ninguna acci´on debe ser ejecutada por un componente del sistema hasta que, desde el punto de vista de su representaci´on gr´afica, no se hayan procesado todos los eventos anteriores que consten previamente en su representaci´on. Una representaci´on de tres entidades puede encontrarse en la figura 4.1.

Figura 4.1: Entidades de un MSC

4.1.2.

Mensajes

Est´an representados por las flechas, horizontales o diagonales, que nacen de una entidad y mueren en otra. El esquema permite a su vez la representaci´on de mensajes intercambiados con el entorno externo del sistema representado, as´ı como posibles mensajes enviados perdidos por el camino e incapaces de llegar a sus destinos. Un mensaje representado por una flecha horizontal entre dos componentes indica que su tiempo de latencia es poco considerable, mientras que otro mensaje que aparezca con mayor diagonalidad representa un mayor retardo desde el momento del env´ıo por el componente emisor hasta el momento de la llegada al componente receptor. Una representaci´on del intercambio de mensajes entre varios componentes puede encontrarse en la figura 4.2.

4.1.3.

Acciones

Otros tipos de elementos representables en un MSC lo constituyen las acciones que cada componente puede realizar sin interacci´on con las dem´as entidades, consistentes en c´omputos internos. Estos procesamientos de datos pueden ser realizados para dar respuesta a una petici´on codificada en un 98

Figura 4.2: Mensajes de un MSC mensaje, para preparar el lanzamiento de nuevos mensajes que ser lanzados a otras entidades, o para analizar el resultado de respuestas recibidas. Las acciones se representan en los MSC con rect´angulos. Las acciones pueden involucrar la ejecuci´on de sentencias como llamadas a funciones o procedimientos ejecutados por la propia entidad y s´olo se consideran terminadas cuando los c´omputos terminan o esas llamadas a funciones o procedimientos retornan. Una representaci´on de una acci´on ejecutada entre la recepci´on de un mensaje a y el env´ıo de una respuesta b puede contemplarse en la figura 4.3.

Figura 4.3: Acciones de un MSC

4.1.4.

Temporizadores

Si bien el eje vertical de cada uno de los componentes de un sistema representa la secuenciaci´on relativa de los eventos que suceden en ese componente, lo cierto es que en dicho eje no existe medida alguna que represente temporizaciones ni medidas acerca del momento exacto en el que se espera que ocurran los eventos. En un MSC se refleja el orden posible de los eventos que ocurren globalmente en el sistema, pero no necesariamente se dan medidas acerca de los tiempos que deben transcurrir entre dichos eventos. En la figura 4.3 aparece claramente representado un sistema de dos entidades i y j de forma que presentan el requisito de que, en primer lugar, la entidad j env´ıa 99

un mensaje a a la entidad i, la cual realiza una acci´on y a continuaci´on env´ıa un mensaje de respuesta b a la entidad j. Sin embargo, en ning´ un lugar del modelo aparecen restricciones acerca de cu´al debe ser el tiempo transcurrido entre dichos eventos, ni es tampoco predecible ni acotable el tiempo existente entre el env´ıo del mensaje a y la recepci´on del mensaje b por la entidad j. Para poder contemplar en el modelo la duraci´on m´axima de estos intervalos entre eventos, los MSC permiten definir temporizadores, de forma que al vencimiento de un temporizador en una entidad se pueda provocar el comportamiento de una acci´on especial en dicha entidad que haga un tratamiento de la situaci´on. Los MSC ofrecen para ello operadores para crear y desactivar temporizadores, as´ı como una marca para se˜ nalar el evento de activaci´on del temporizador. Distintos tipos de operadores de temporizadores, cada uno de ellos nombrado con un nombre distinto, y para los cuales hay distintos comportamientos representados (establecimiento, desactivaci´on, 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 est´a completamente determinado, sino un conjunto de eventos pueden ocurrir en cualquier orden, de forma no determinista. En aras de que las representaciones sean lo suficientemente flexibles y permitan representar en un mismo gr´afico todas las posibles variantes de esas ordenaciones, t´ıpicamente atribuibles a aspectos no controlables como retrasos impredecibles en las comunicaciones, en la recepci´on o el env´ıo de varios mensajes, los MSC permiten la definici´on de zonas espec´ıficas en las entidades, llamadas corregiones representadas por fragmentos dibujados con trazos discontinuos en las entidades, de forma que 100

los mensajes que parten o llegan a una corregi´on pueden ser enviados o recibidos en cualquier orden posible respecto del resto de los eventos definidos dentro de la misma corregi´on. As´ı pues, dentro de una corregi´on con n eventos, se estar´an representando los n! casos posibles de ordenaci´on de una sola vez. Un ejemplo de corregi´on definida para el componente j puede contemplarse en la figura 4.5.

Figura 4.5: Corregiones en un MSC

4.1.6.

Condiciones

Una condici´on es el cumplimiento de una expresi´on de verdad, y sirve para indicar que el sistema ha entrado en un cierto estado. Una condici´on, que desde el punto de vista de programaci´on se puede asociar con una expresi´on booleana, puede afectar a m´as de una entidad en un sistema. El s´ımbolo de condici´on en un MSC, que es un hex´agono, aparece superpuesto a todas las entidades a las que afecta. Las dem´as entidades no afectadas por la condici´on se dibujan sin intersecar con el s´ımbolo de la condici´on, o bien aparecen superpuestas a ´el. En la figura 4.6 aparece representado un MSC donde la primera condici´on afecta a las entidades i y k, la segunda condici´on afecta s´olo a la entidad i y la tercera condici´on afecta a todas las entidades del sistema.

4.1.7.

Creaci´ on y destrucci´ on din´ amica de entidades

Las entidades pueden estar creadas antes del momento del que parte el modelado del MSC y seguir existiendo despu´es del momento en el que termina el modelado. En ese caso, se las considera entidades de creaci´on est´atica, y su creaci´on y destrucci´on no forma parte del modelado del sistema. No obstante, algunas entidades tambi´en pueden ser creadas y destruidas din´amicamente 101

Figura 4.6: Condiciones de un MSC en tiempo de ejecuci´on, dentro del modelado del sistema, como por ejemplo, como respuesta a alg´ un tipo de evento. Tanto la creaci´on como la destrucci´on de este tipo de entidades puede ser representada en un MSC f´acilmente. La creaci´on de mensajes se representa con una flecha discontinua desde la entidad creadora (la que invoca la creaci´on) a la entidad creada (la que aparece como resultado de la invocaci´on anterior). La destrucci´on de mensajes se representa al final de cada entidad con unas aspas en forma de cruz, momento a partir del cual, la entidad deja de existir. Una representaci´on de la creaci´on de dos entidades y la muerte de dos de ellas puede contemplarse en la figura 4.7.

Figura 4.7: Creaci´on y destrucci´on din´amica de entidades en un MSC

102

4.1.8.

Expresiones inline

Una expresi´on inline es una parte especial de un MSC sobre la cual est´a definido un operador que conjuga la forma en la que deben aparecer los eventos que forman parte de la expresi´on. Por ejemplo, una expresi´on inline de bucle indica que los eventos que forman parte de ella pueden ser ejecutados en secuencia varias veces. Existen varios ejemplos posibles de operadores, que aparecen en la tabla 4.1. Por ejemplo, existen operadores para indicar que dos o m´as partes de un MSC deben ejecutarse en paralelo (concurrentemente), o para indicar que, de varias partes de un MSC, se debe escoger s´olo alguna, quiz´a incluso dependiendo de una condici´on que determine cu´al es la parte que responde al modelado de los siguientes eventos. Existen operadores tambi´en para indicar repetitividad, es decir, que la secuencia de eventos producidos en un fragmento de un MSC se deben repetir varias veces hasta que se cumpla una condici´on de salida del bucle.

Expresi´ on 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 est´an representadas por rect´angulos, donde los operandos est´an separados por l´ıneas horizontales discontinuas, y donde el nombre del operador aparece en la esquina superior izquierda del rect´angulo. Las estructuras inline pueden anidarse unas dentro de otras. Una representaci´on de varias expresiones inline de un MSC, una de ellas anidada dentro de otra, puede contemplarse en la figura 4.8.

4.1.9.

Descomposici´ on modular

Es habitual que en los sistemas m´as complejos, el nivel de complejidad de un MSC presente dificultades de legibilidad en la representaci´on gr´afica. 103

Figura 4.8: Expresiones inline en un MSC El n´ umero de eventos y de expresiones inline puede f´acilmente llegar a ser demasiado grande, o la estructura de anidamientos puede presentar demasiados niveles, por lo que suele ser necesario simplificar la representaci´on con construcciones m´as sencillas, encapsulando las partes de m´as bajo nivel para que puedan ser convenientemente referenciadas, de la misma forma en la que se usan procedimientos y funciones en los lenguajes de programaci´on. Desde el punto de vista de los MSC, la soluci´on habitual consiste en distribuir la informaci´on del modelo en varios MSC m´as simples de forma que unos puedan ser referenciados por otros. Tales referencias se representan con unos rect´angulos con las esquinas redondeadas, cubriendo dichos rect´angulos aquellas entidades que intervienen en el MSC referenciado. Una representaci´on de un MSC que referencia a otros dos MSC externos puede contemplarse en la figura 4.9. La figura 4.10 representa un ejemplo de MSC en el que se combinan varios de los elementos anteriores.

4.2.

XPath

XPath es una recomendaci´on del W3C para el direccionamiento de datos en documentos XML. El actual est´andar es la versi´on 1.0 [129], recomendada desde noviembre de 1999. No obstante, a lo largo de los u ´ltimos a˜ nos los grupos de trabajo del W3C de XML Query y de XSL han estado trabajando 104

Figura 4.9: Referencias a otros MSC

Figura 4.10: MSC

105

en una nueva versi´on del est´andar, la versi´on 2.0 [141], que actualmente est´a todav´ıa en fase de borrador. Sin llegar a tener toda la funcionalidad de un lenguaje de consulta tan potente como XQuery (ver apartado 4.5), XPath permite una especificaci´on clara y funcional de consultas de datos en documentos y colecciones de elementos XML, pudiendo por tanto ser utilizable para las labores de extracci´on de datos mencionadas en el apartado 2.2.1. La expresividad de XPath permite que las especificaciones de expresiones de consulta sean lo suficientemente potentes como para resolver la mayor´ıa de las consultas usando apenas una expresi´on simple y f´acilmente entendible que ocupa normalmente una u ´nica l´ınea de texto. Ello ha permitido, por ejemplo, que actualmente se utilice XPath como lenguaje de consulta en bases de datos XML tales como [24, 63]. Por otro lado, XPath sirve como base de muchos otros lenguajes que recorren la estructura de documentos XML, tales como XPointer [138], XSLT [130], XQuery [142] o XUpdate [148]. Una importante caracter´ıstica de XPath es que no dispone de todas las caracter´ısticas necesarias para poder ser utilizado por s´ı s´olo como un lenguaje de programaci´on completo. XPath est´a dise˜ nado para ser utilizado dentro de un lenguaje anfitri´on, el cual deber´a ser capaz de proporcionar a XPath un entorno de ejecuci´on con acceso a las variables del entorno y capaz de encargarse de todas aquellas tareas ajenas a la labor para la que XPath ha sido dise˜ nado. Por ejemplo, XPath no contempla funcionalidades relacionadas con la transferencia de documentos en la Red, el acceso al sistema de ficheros, el env´ıo de formularios, la comunicaci´on con programas externos, la petici´on de datos al usuario ni tampoco la presentaci´on de datos a ´este. Todas esas funcionalidades son ajenas a XPath, y por lo tanto, quedan delegadas como labores del lenguaje anfitri´on en el que XPath est´e hospedado. Los u ´nicos repositorios que reconoce XPath para almacenar datos son variables en memoria capaces de ser accedidas y modificadas tanto por ´el como por el lenguaje anfitri´on en el que est´a hospedado XPath. Ejemplos de conocidos lenguajes anfitri´on de XPath son XSLT y XUpdate, pero no son los u ´nicos posibles. La existencia de varios posibles lenguajes anfitriones no debe sorprender, puesto que la sintaxis compacta de XPath est´a orientada precisamente a facilitar su hospedaje en varios posibles lenguajes anfitriones, especialmente los basados en XML, donde las expresiones XPath son id´oneas para ser almacenadas en atributos de etiquetas XML. Sin duda, gran parte del ´exito de aceptaci´on de XSLT es debido a que buena parte de su funcionalidad recae sobre XPath aprovechando este sencillo y elegante tipo de hospedaje.

106

La presencia de XPath, desde que apareci´o su primera versi´on, ha estado, pese a sus m´ ultiples posibilidades, principalmente limitada a dos campos. Por una parte, XPath ha sido usado en varias bases de datos XML, donde es empleado como lenguaje de consulta para la extracci´on de elementos XML resultado. Por otra parte, y de una manera quiz´a mucho m´as destacada por su mayor impacto de utilizaci´on en un mayor n´ umero de personas, XPath ha sido una de las bases de las hojas de estilo XSLT. En XSLT, XPath es empleado para seleccionar los nodos del documento de entrada a los que se les debe aplicar las plantillas de transformaci´on declaradas en una hoja de estilo. El aumento de expresividad adquirido en los borradores de la u ´ltima versi´on de XPath (concretamente en la versi´on 2.0, actualmente en fase de borrador donde a´ un hay aspectos en fase de discusi´on) ha sido realmente importante en los u ´ltimos a˜ nos. Estos aumentos de expresividad, que aparecen destacados en negrita en la figura 4.11 sobre los de la versi´on 1.0 de XPath, permiten a XPath 2.0 ser usado, m´as que un simple lenguaje de construcci´on de expresiones sencillas de direccionamiento de datos en documentos XML, pr´acticamente como un peque˜ no mini-lenguaje de programaci´on de funcionalidades muy recortadas. Pese a que ambas versiones son en el fondo muy parecidas, la nueva versi´on no es a´ un completamente compatible con el anterior est´andar, lo cual est´a provocando numerosas revisiones y debates [122] entre los grupos de trabajo del W3C donde se est´a llevando a cabo el proceso de homogeneizaci´on. La aplicaci´on del nuevo borrador de XPath 2.0 para el direccionamiento de datos en las p´aginas Web no ha sido contemplada por los trabajos relacionados en el cap´ıtulo 3, ni por pr´acticamente ning´ un trabajo recientemente publicado, al menos en lo que concierne al autor de esta tesis. Una de las razones principales que puede justificar esta falta de aplicaci´on de XPath 2.0 reside en que ´este es a´ un un borrador que no ha pasado a ser un est´andar consolidado por el W3C, raz´on por la cual los desarrolladores prefieren usar la versi´on recomendada de XPath 1.0, preferentemente en alg´ un entorno ampliamente conocido como lo son las hojas de estilo XSLT. Por otra parte, la gran mayor´ıa de las p´aginas Web no cumplen las reglas b´asicas necesarias para poderles ser aplicadas tecnolog´ıas XML, por lo que aplicar XPath sobre ellas directamente resulta, en primera instancia, impracticable. XPath 2.0 tal y como aparece definido, es un lenguaje funcional basado en expresiones que necesita estar hospedado por un lenguaje anfitri´on que sea capaz de albergarlo proporcion´andole un conjunto de funcionalidades b´asicas, tales como mantenimiento de un entorno de ejecuci´on que secuencialice

107

adecuadamente la evaluaci´on de las distintas expresiones XPath de consulta, o que se encargue de la recuperaci´on y lectura de las p´aginas a las que se deben aplicar las expresiones XPath de consulta. Un t´ıpico ejemplo de lenguaje anfitri´on para XPath es XSLT, el lenguaje de transformaci´on de documentos XML mediante hojas de estilo. Lenguajes de programaci´on convencionales, como Java, tambi´en pueden ser anfitriones de XPath, como ocurre cuando se hace uso de bibliotecas capaces de evaluar expresiones XPath recibidas como argumento [62] y que devuelven sus resultados en tipos de datos conforme a un API como DOM [131], tal y como aparece en la figura 3.5. Sin embargo, la gran mayor´ıa de esos lenguajes anfitriones usan la versi´on recomendada de XPath 1.0, y todav´ıa no hay implementaciones fiables que sirvan para calcular expresiones XPath 2.0. XPath est´a definido como un lenguaje de expresiones, lo cual significa que son ´estas, las expresiones, los bloques b´asicos de construcci´on de XPath. El lenguaje contempla varios tipos distintos de expresiones que pueden ser construidos con palabras clave, s´ımbolos y operandos. En general, los operandos de una expresi´on construida con un operador son a su vez otras expresiones. La figura 4.11 contiene un resumen de las m´as importantes destacando en negrita las que son aportaciones de XPath 2.0 respecto de XPath 1.0. Las siguientes secciones contienen una descripci´on detallada de cada una de ellas.

4.2.1.

Secuencias

El valor de una expresi´on es siempre una secuencia de valores. Una secuencia es una colecci´on ordenada de varios valores, con un n´ umero de elementos ilimitado, pero finito, incluyendo tambi´en el caso de la secuencia vac´ıa, es decir, la secuencia que no contiene ning´ un valor. Los elementos posibles de una secuencia son valores de tipos denominados como at´omicos, esto es, valores simples no formados por la composici´on de otros valores. Ejemplos de valores at´omicos son los valores num´ericos (de distintas subcategor´ıas dependiendo de su precisi´on, como valores enteros, decimales y de coma flotante), valores l´ogicos (o booleanos) y las cadenas de caracteres (strings). Cuando una secuencia tiene un u ´nico elemento se le denomina sigleton y el valor de la secuencia se asimila al del u ´nico elemento que contiene. Es decir, para XPath el valor efectivo de la secuencia (3), formada por un u ´nico elemento cuyo valor num´erico es 3, es asimilable a ese mismo valor num´erico. Asimismo, las secuencias deben ser todas planas, es decir, no se admite la definici´on de secuencias cuyos elementos sean a su vez otras secuencias. Por otro lado, mientras que en XPath 1.0 los tipos de datos at´omicos son apenas unos po108

Ejes: Expr/Expr, Axis::NodeTest Predicados: Expr[Expr] Referencia a variables: $Var Expresiones aritm´eticas: Expr + - * div mod Expr Llamada a funciones: QName(Expr) Expresiones l´ogicas: 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, b´asicamente los mencionados anteriormente junto con los nodos (referencias a elementos del documento XML, incluyendo el elemento ra´ız o p´agina), en los posteriores borradores del est´andar el conjunto de tipos b´asicos posibles ha sido ampliados con la incorporaci´on de tipos de datos provenientes de XML Schema (como fechas, duraciones, URIs, ...). Ello ha dotado al lenguaje de una mayor riqueza al incluir as´ı tipos especializados que, con frecuencia, aparecen en los documentos que se publican en el Web.

4.2.2.

Variables

Las variables son repositorios en memoria que albergan resultados de expresiones XPath y que constituyen la forma de comunicar XPath con su entorno. Gracias a las variables, expresiones XPath pueden utilizar los resultados de otras expresiones XPath. El acceso al valor de una variable dentro de XPath se representa con el s´ımbolo del d´olar $ seguido del nombre de la variable. Las variables de XPath son accesibles por el lenguaje anfitri´on de XPath de forma que ´este tambi´en es capaz de manipular los resultados de expresiones XPath.

4.2.3.

Operadores aritm´ etico-l´ ogicos y de comparaci´ on

XPath permite especificar operaciones aritm´eticas (sumas, restas, multiplicaciones, divisiones, ...) as´ı como operaciones l´ogicas (and, or, not) y comparaciones de diversos tipos (igualdad, menor que, menor o igual que, mayor que ...), incluyendo tambi´en operadores para comparar el orden de aparici´on de nodos dentro del documento. Todo ello permite la creaci´on de expresiones sencillas capaces de calcular operaciones habituales de an´alisis de datos en p´aginas XML que pueden ser combinadas f´acilmente.

4.2.4.

Ejes de navegaci´ on

Los ejes de navegaci´on son indicadores acerca de los caminos que deben seguirse para saltar de un nodo a otro dentro del ´arbol del documento. Normalmente esta navegaci´on necesita hacerse en varios saltos, raz´on por la cual las expresiones XPath est´an divididas en distintos steps o pasos, delimitados por barras inclinadas /. Dentro de cada paso, los saltos entre nodos est´an condicionados por los denominados ejes de navegaci´ on que indican la relaci´on vecinal existente entre el nodo de origen y el nodo destino de cada 110

salto. Estas distintas formas de proximidad vecinal son contempladas por el est´andar de forma que sean as´ı explorables todos los nodos, tanto internos a un nodo cualquiera (child y descendant), como externos al mismo (parent, ancestor, preceding-sibling y following-sibling). El acceso a los atributos XML de un nodo se puede realizar atravesando el eje attribute. XPath proporciona a su vez una sintaxis abreviada para cada uno de esos ejes de navegaci´on, lo cual permite la construcci´on de expresiones m´as cortas y legibles. La tabla 4.2 muestra un listado de los ejes de XPath.

Eje

Nodos considerados

ancestor

Cualquier nodo en el camino hacia la ra´ız

ancestor-or-self

Lo mismo, pero incluy´ endolo

attribute

S´ olo los nodos atributo del ´ arbol

child

Los nodos directamente contenidos por el nodo actual

descendant

Los nodos del sub´ arbol cuya ra´ız es el nodo actual

descendant-or-self

Lo mismo, pero incluy´ endolo

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 poder llegar a los elementos que interesa finalmente acceder, lo cierto es que muchas veces el atravesamiento de ciertos de esos nodos que aparecen direccionables por un eje de navegaci´on resultan no deseables. El uso de los ejes de navegaci´on, aunque est´e bien combinado con una adecuada elecci´on de los nombres de los elementos, resulta muchas veces insuficiente para evitar la navegaci´on por nodos no deseados. Por esa raz´on, XPath proporciona mecanismos adecuados para permitir la selecci´on, conforme a criterios especificables por el usuario, de los elementos de una secuencia obtenida en cada paso de una expresi´on XPath, de manera que s´olo sean seleccionados del 111

documento XML aquellos componentes que cumplan un conjunto de requisitos establecidos, siendo descartados aquellos elementos de la secuencia que no cumplan esa propiedad. Las funciones encargadas de filtrar o seleccionar aquellos elementos de una secuencia que cumplen las propiedades especificadas en una condici´on se denominan predicados, y son una parte muy importante de XPath, pues en ellos reside gran parte de su expresividad. Los predicados se representan en XPath rodeados de corchetes [] que, situados a la parte derecha de cada paso, rodean la condici´on que deben cumplir cada uno de los elementos seleccionados en ese paso para poder formar parte del resultado final.

4.2.6.

Llamadas a funciones

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

4.2.7.

Constructores de datos secundarios

Por otro lado, si bien la idea b´asica de XPath es la de permitir la extracci´on y direccionamiento de datos tal cual ´estos aparecen en el documento XML (datos primarios), el est´andar contempla adem´as operadores capaces de obtener datos que, no figurando como tales en el documento XML de entrada, s´ı son capaces de ser computados mediante sencillos algoritmos a partir de los datos que aparezcan en el documento. Ejemplos de estos operadores sencillos son la media, la suma, el m´ınimo y el m´aximo, aunque la lista es m´as extensa.

4.2.8.

Modificaciones introducidas en XPath 2.0 respecto de XPath 1.0

El actual borrador de esta t´ecnica es el de XPath 2.0, que, desde su primera publicaci´on en diciembre de 2001, ha sufrido varias revisiones, siendo [141] la m´as reciente de ellas. Desde entonces, el borrador de XPath ha in112

corporado una serie de modificaciones importantes que le han dotado de una mayor expresividad y capacidad de especificaci´on. Algunas de ellas son las siguientes:

Generalizaci´ on del concepto de secuencia En XPath 1.0 el tipo b´asico de datos es el node-set, en el que el orden de los elementos es el mismo que en el documento y no se admiten elementos repetidos. Por el contrario, en XPath 2.0, el concepto de node-set ha sido sustituido por otro m´as abierto como es la secuencia, donde, a diferencia de su predecesor, se permite la aparici´on de elementos repetidos y se pueden definir otros criterios de ordenaci´on distintos al de la aparici´on en el documento.

Expresiones condicionales y de iteraci´ on (if y for) XPath 2.0 incorpora tambi´en novedades respecto a su versi´on anterior en el campo del control de flujo para la evaluaci´on de expresiones XPath, algo que no aparec´ıa en las versiones anteriores del est´andar. Nuevos constructores de expresiones condicionales del tipo if-then-else y repetitivas del tipo for-in han sido incorporados, gracias a la influencia de XQuery para la definici´on de expresiones condicionales y repetitivas. No obstante, la definici´on de este tipo de expresiones no es la misma que cabr´ıa esperar en un lenguaje imperativo, ya que se trata de constructores de expresiones, m´as que constructores de sentencias. Es decir, una expresi´on for de XPath, lejos de constituir un conjunto de sentencias ejecutadas secuencialmente, en realidad construye una expresi´on en s´ı misma que tiene como valor la secuencia formada por los elementos construidos en cada una de sus iteraciones.

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

Operaciones de conjuntos Otra de las novedades incorporadas en la nueva versi´on de XPath son los operadores definidos para construir nuevas secuencias a partir de otras secuencias preexistentes. De este modo, existen operadores para crear la uni´on (union), la intersecci´on (intersect) o la diferencia (except) de secuencias como si fueran conjuntos, esto es, eliminando los elementos repetidos y dejando de considerar la existencia de un orden entre sus elementos. La secuencia formada por la uni´on o por la intersecci´on de dos secuencias A y B es la formada por aquellos elementos que pertenecen a A o/y pertenecen a B (respectivamente).

4.2.9.

Aportaciones de XPath

Una caracter´ıstica importante del presente trabajo es la de ser el primero que intenta, al menos en lo que el autor es consciente en la fecha de escritura de este documento, utilizar en profundidad aquellas nuevas funcionalidades de XPath 2.0, que no est´an en XPath 1.0, en el campo de la integraci´on de datos semiestructurados en el Web legado basado en p´aginas HTML. Para ello se ha desarrollado una extensi´on de XPath 2.0 basada en un conjunto peque˜ no de nuevos, pero potentes operadores que mantienen al m´ınimo las diferencias con el borrador de XPath 2.0 y que aparecen detalladas en el apartado 5.5. Por otro lado, se ha proporcionado un lenguaje anfitri´on, detallado en el cap´ıtulo 6 distinto a los habitualmente usados para XPath hasta el momento, que son XSLT o las bases de datos XML. Finalmente, se ha proporcionado una plataforma de ejecuci´on capaz de evaluar expresiones de consulta descritas en la extensi´on propuesta de XPath de forma que los resultados de esas expresiones de consulta sean utilizables por un lenguaje de programaci´on asequible al usuario y que le permita automatizar f´acilmente tareas en el Web. XPath es un lenguaje funcional basado en expresiones que est´a definido como una recomendaci´on del W3C orientada al direccionamiento de partes de documentos XML. XPath permite de una forma sencilla, y con alto nivel de abstracci´on, tener una visi´on en forma de ´arbol del modelo de datos del documento XML, de forma que la navegaci´on entre los nodos del mismo resulta sencilla, pudiendo estar enfocada directamente a las partes relevantes del documento, sin que para ello tengan que ser tenidas en cuenta las partes consideradas como no relevantes. El cometido para el que XPath ha sido dise˜ nado es el de permitir, de una forma clara, sencilla y no ambigua, el direccionamiento de datos (textos, n´ umeros, condiciones, y conjuntos de 114

informaciones semiestructuradas en general) dentro de documentos XML, proporcionando una visi´on del documento similar a la de un ´arbol de directorios en un sistema de ficheros, aunque con mayores capacidades de selecci´on y filtrado. XPath toma su nombre de su uso como una notaci´on de path o camino a trav´es de la estructura jer´arquica de los documentos XML.

4.3.

XPointer

XPointer es un borrador del W3C [138] que est´a definido como una ampliaci´on de XPath para permitir el direccionamiento de partes de XML que no se corresponden con los nodos de un ´arbol de documento y que no pod´ıan ser direccionadas con XPath. Para ello, XPointer expande la definici´on de tipos utilizada en XPath con tres nuevos tipos de datos que se resumen a continuaci´on:

4.3.1.

Puntos

Los puntos (point) se definen como posiciones entre dos componentes dentro de los documentos XML. Un punto representa la posici´on anterior o posterior a un elemento de datos del documento, como puede ser cualquier car´acter individual, entidad o nodo de un documento XML. Los puntos est´an definidos como un par formado por un contenedor y un n´ umero entero no negativo llamado ´ındice, que indica la posici´on del punto dentro del contenedor. Cuando el contenedor es un elemento que contiene texto, el ´ındice indica la posici´on en caracteres del punto dentro del contenedor. Cuando el contenedor es un elemento que puede tener nodos hijos, el ´ındice indica la posici´on de aqu´el nodo hijo, cuya localizaci´on de inicio se corresponde con el punto. La figura 4.12, tomada de la especificaci´on de XPointer [138] del W3C, refleja un ejemplo en el que aparecen detallados varios puntos y nodos de texto, as´ı como su relaci´on con los nodos contenedores de los mismos.

4.3.2.

Rangos

Los rangos (range) se definen como los fragmentos de documento comprendidos entre dos puntos arbitrarios de un documento. T´engase en cuenta que ello permite definir trozos de documento que no necesariamente est´an dentro del mismo contenedor. Por ejemplo, puede definirse un rango que empieza en la mitad de un p´arrafo y terminan en la mitad del p´arrafo siguiente. 115

Figura 4.12: Representaci´on de elementos XPointer en un fragmento XML Los rangos son asimilables a cualquier fragmento contiguo de un documento XML, como el que f´acilmente podr´ıa ser seleccionado mediante una herramienta visual haciendo una operaci´on de drag & drop.

4.3.3.

Patrones de texto

Una de las grandes necesidades en el campo del direccionamiento de datos semiestructurados consiste en la posibilidad de reconocer textos mediante expresiones regulares. XPath, enfocado principalmente al direccionamiento de nodos, no proporciona, al menos en sus primeras versiones de XPath 2.0, funciones capaces de devolver aquellas partes de los documentos XML donde se cumple una concordancia entre el texto del documento y un patr´on de texto usado para hacer b´ usquedas o reconocimiento de textos basados en expresiones regulares. Mediante la funci´on string-range() de XPointer, esto ya es una realidad, pero el string recibido por esta funci´on como patr´on es buscado literalmente en el documento (sin posibilidad de ser interpretado como una expresi´on regular), por lo que el tipo de b´ usquedas que se pueden realizar con este patr´on resultan algo limitadas. 116

4.3.4.

Aportaciones de XPointer

Extender XPath con nuevas funcionalidades definiendo tal y como XPointer propone mediante nuevo lenguaje considerado como una extensi´on de la parte b´asica de XPath es un buen enfoque, porque permite ampliar la funcionalidad de un lenguaje preexistente dot´andole de una mayor complejidad, sin que para ello se retoque la parte b´asica del est´andar, la cual puede ser, sin embargo, suficiente para tareas m´as sencillas. Teniendo en cuenta el car´acter eminentemente especializado de los nuevos operadores sugeridos por XPointer, su relativamente bajo n´ umero (tres), su escasa relaci´on con los operadores de XPath y el hecho de que XPath por s´ı mismo es capaz ya de dar respuesta a una buena parte de los problemas en los que es utilizado, no resulta raro darse cuenta de las razones por las cuales estas extensiones han formado parte de una definici´on externa a XPath, en lugar de ser incorporadas al borrador de XPath como nuevos conjuntos de operadores. Sin embargo, pese a este flexible enfoque seg´ un el cual se podr´ıa disponer de una tecnolog´ıa m´as potente que la que ofrece XPath gracias a unas pocas, pero importantes extensiones de funcionalidad, XPointer presenta algunas caracter´ısticas que le impiden ser considerada como una tecnolog´ıa apropiada para el desarrollo de este trabajo. Ciertamente hay buenas ideas que aporta esta recomendaci´on de las que tomar buena nota, pero existen igualmente problemas, entre los que se destacan unos a continuaci´on: La especificaci´on de XPointer prohibe expl´ıcitamente la definici´on de funciones de usuario, lo cual supone una restricci´on inasumible para poder afrontar los objetivos de esta tesis, entre los cuales est´a la definici´on de comportamientos encapsulables por parte de los usuarios. string-range por s´ı s´olo resulta presentar una funcionalidad algo limitada, ya que s´olo permite buscar texto tal cual dentro del documento, sin permitir generalizar las b´ usquedas con expresiones regulares. XPointer, desarrollado por un grupo de trabajo en el W3C distinto al de la definici´on de XPath, est´a basado en la versi´on de XPath 1.0, y por lo tanto no recoge las importantes ampliaciones de los nuevos borradores de XPath 2.0. Ello probablemente dejar´a de ser un problema en cuanto los dise˜ nadores de XPointer empiecen a trabajar en una versi´on basada en el nuevo borrador de XPath, pero no se tiene, por el momento, constancia de que tal iniciativa se vaya a llevar a cabo. De hecho, los avances que el grupo de XPointer ha conseguido por su cuenta no han sido incorporados en los borradores de XPath que han aparecido con posterioridad. 117

Finalmente, tampoco resulta interesante todas las nuevas funcionalidades de XPointer. Por ejemplo, la definici´on de puntos basada en posiciones num´ericas es muy poco tolerante a cambios en el documento (la simple inserci´on de una palabra o un nodo inesperado provocar´a un cambio en la posici´on del elemento que se desea extraer, lo cual implica una reprogramaci´on de las reglas basadas en posicionamientos expresados con posiciones num´ericas) y no todos los rangos definibles por XPointer interesan.

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

4.4.

XSLT

XSLT [130] es un formato de hojas de estilo muy conocido que se utiliza mucho para la transformaci´on de documentos XML en otros documentos. A diferencia de las tecnolog´ıas mencionadas en este cap´ıtulo (salvo quiz´a XUpdate y una versi´on de XQuery orientada al procesamiento automatizado, llamada XQueryX [135]), XSLT sigue una sintaxis XML, donde se utiliza el concepto de plantilla para aplicar unas reglas de transformaci´on a elementos de documentos XML direccionados con XPath. Precisamente esa buena relaci´on de complementareidad entre las hasta ahora utilizadas versiones de XSLT y XPath (versiones 1.0 en ambos casos), se ha convertido en una de las razones del ´exito de aceptaci´on de XSLT. No obstante, por debajo del enfoque de simple transformaci´on de XSLT, se esconde todo un lenguaje de programaci´on funcional capaz de ser un buen lenguaje anfitri´on para XPath. El modelo de trabajo de XSLT es sencillo. Basta con aplicar una a una el conjunto de plantillas al modelo en ´arbol DOM del documento de entrada, para as´ı ir generando los resultados deseados en el documento de salida. Pese a usar la complejidad de DOM para acceder a un documento XML, XSLT no permite la manipulaci´on del documento XML de entrada, sino que s´olo genera nuevos documentos. 118

4.4.1.

Aportaciones de XSLT

Pese a su aceptaci´on por un gran conjunto de desarrolladores, XSLT resulta ser un lenguaje limitado en varios aspectos que le impiden ser una soluci´on compatible con los objetivos de esta tesis. Para empezar, su sintaxis XML le hace ser f´acilmente procesable por aplicaciones, pero demasiado verbosa y extensa, por lo que resulta dif´ıcil de mantener. De hecho, simples operaciones programadas en el lenguaje pueden f´acilmente requerir la programaci´on de bastantes l´ıneas de c´odigo, raz´on por la cual los programas desarrollados con XSLT acaban teniendo un tama˜ no similar al que podr´ıa tener su equivalente en un lenguaje de programaci´on convencional. XSLT proporciona una visi´on de alto nivel en el documento y su notaci´on funcional le hacen ser un lenguaje apropiado para tratamientos sencillos. Sin embargo, las hojas de estilo XSLT resultan bastante poco flexibles para realizar tareas complejos. Por otro lado, el nuevo borrador de XSLT 2.0 se encuentra ahora mismo en un serio debate de reformulaci´on debido a los conflictos de intereses que han aparecido como consecuencia de la extensi´on de XPath 2.0. Actualmente existen importantes problemas de integraci´on con XPath 2.0 debido a que la extensi´on de este u ´ltimo desde su recomendaci´on anterior ha incluido varios operadores cuya funcionalidad ya estaba siendo contemplada por operadores similares de XSLT, lo cual ofrece m´ ultiples fuentes de ambig¨ uedad para los desarrolladores. Es por ello que esta integraci´on est´a siendo objeto de estudio por el grupo de trabajo. A continuaci´on se muestran algunos ejemplos que ilustran este tipo de conflictos recientemente aparecidos: 1. En la figura 4.13 se muestran dos versiones del c´odigo XSLT necesario para calcular el valor m´aximo de un par de variables. La primera versi´on est´a basada en XPath 1.0, por lo que, dada la simplicidad del est´andar, casi toda la labor acaba recayendo en la funcionalidad proporcionada por XSLT. La segunda versi´on, basada en XPath 2.0, resulta mucho m´as simple y compacta por el simple hecho de traspasar la funcionalidad de XSLT a XPath, quedando en una u ´nica l´ınea de c´odigo lo que en la versi´on XSLT requer´ıa varias. 2. En este ejemplo se puede comprobar el sensible aumento de expresividad y de nivel de abstracci´on experimentado por XPath experimentado por sus expresiones cuantificadas. Ambas expresiones XPath intentan determinar la condici´on de que, en un documento XML que refleja los resultados de unas encuestas, los participantes de la misma no hayan dejado ninguna pregunta (question) sin contestar (el atributo @value deber´a ser no nulo). Expresar esa condici´on resulta sencillo en XPath. 119





Figura 4.13: Expresi´on XPath reformulada con el operador if

Para ello, la expresi´on en XPath 1.0 contabiliza el n´ umero de preguntas efectivamente contestadas y comprueba que ese n´ umero coincide con el n´ umero de preguntas de la encuesta. Esto, que es una soluci´on perfectamente v´alida implica realizar siempre dos contabilizaciones que pueden ser muy costosas cuando el n´ umero de elementos es muy elevado. Por el contrario, usando el nuevo cuantificador universal de XPath 2.0, la soluci´on, adem´as de ser m´as eficiente de calcular en t´ermino medio, pues en el momento en el que se encuentra una pregunta sin contestar puede interrumpirse la b´ usqueda para dar un resultado negativo, resulta m´as elegante, ya que simplemente se pregunta si todos los elementos de la lista de preguntas cumplen la condici´ on de estar respondidas. En la figura 4.14 pueden comprobarse las formas de expresar una misma condici´on, tanto en XPath 1.0, como en XPath 2.0, con el nuevo operador cuantificado.





Figura 4.14: Expresi´on XPath reformulada con el operador every

120

4.5.

XQuery

Paralelamente al lanzamiento de XPath 2.0, el mismo grupo de trabajo de ese borrador ha estado trabajando en el lanzamiento de la primera versi´on de XQuery [142], actualmente definido tambi´en como borrador (a´ un sujeto a cambios). XQuery se define como un lenguaje de consultas estructuradas para documentos XML de entrada de forma que los resultados se almacenan en nuevos documentos XML de salida. XQuery 1.0 abarca a XPath 2.0 como un subconjunto del lenguaje al que se le han a˜ nadido extensiones espec´ıficas no contempladas en XPath 2.0. Esto quiere decir que toda expresi´on XPath 2.0 es considerable a su vez como una expresi´on XQuery 1.0 y debe devolver el mismo resultado. El lenguaje de consultas XQuery permite realizar consultas a un documento XML como si ´este fuera una base de datos relacional, dando as´ı una visi´on muy estructurada del documento. Cuando el documento XML no tiene una estructura asimilable a la de una tabla, entonces entran en juego los operadores de XPath capaces de dar una visi´on en ´arbol. La compenetraci´on entre XPath y XQuery est´a garantizada, no s´olo por ser un objetivo del grupo de trabajo que redacta ambas especificaciones, sino tambi´en por el hecho de que buena parte de la funcionalidad de XQuery se encuentra ya recogida en la de XPath, donde el conjunto de operadores que pertenecen a XQuery y no pertenecen a XPath suponen una peque˜ na, aunque significativa parte de la especificaci´on. XQuery es el resultado del trabajo conjunto de varias personas que han recopilado esfuerzos provenientes de varios proyectos relacionados con la creaci´on de lenguajes de consulta, tales como SQL [78], XQL [107] o XML-QL [56] entre otros. El lenguaje mantiene un gran parecido con SQL y define reglas de construcci´on del documento XML de salida, que contendr´a los resultados de la b´ usqueda.

4.5.1.

Aportaciones de XQuery

Al estilo de XPointer, XQuery se presenta como una ampliaci´on de XPath. Sin embargo, pese a este flexible enfoque, seg´ un el cual se permitir´ıa mantener una especificaci´on simple para solucionar la mayor´ıa de los problemas y una especificaci´on m´as especializada para solucionar los problemas m´as complejos, el enfoque de XQuery hacia las bases de datos estructuradas acaba restando valor a XQuery para ser contemplado como una tecnolog´ıa v´alida para afrontar los objetivos de esta tesis. A ello hay que a˜ nadir el hecho de que XQuery est´a orientado, al igual que XSLT, a la creaci´on de un documento XML de salida que contiene los resultados de la b´ usqueda, pero no permite realizar modificaciones directamente sobre el documento de entrada. No obs121

tante, XQuery aporta algo muy positivo de lo cual carece XPath, que es la posibilidad de asociar expresiones XPath a distintas fuentes de documentos as´ı como integrar los datos de varias de esas fuentes.

4.6.

DOM

Sin duda alguna, DOM [131] ha sido, desde su nacimiento, el interfaz de programaci´on m´as conocido para el procesamiento de datos XML. Estandarizado casi desde el nacimiento del propio XML, el interfaz DOM define un conjunto de primitivas sencillas y potentes que permiten la manipulaci´on flexible del documento XML, manteniendo en memoria una representaci´on en forma de ´arbol en la cual se pueden recorrer los nodos en varios sentidos y direcciones, incluso de forma repetida si se desea. El almacenamiento en forma de ´arbol tiene como ventaja a˜ nadida a su gran navegabilidad el hecho de que es f´acilmente modificable en memoria, siendo muy eficiente este modelo para peque˜ nas modificaciones sobre grandes documentos. Sin embargo, entre sus desventajas est´a un elevado consumo de recursos espaciales, de forma que una representaci´on en memoria, dicho sea de paso, puede ocupar significativamente mucho m´as espacio que la versi´on serializada en un fichero. Sin embargo, la visi´on del documento como un ´arbol en memoria permite una gran facilidad de programaci´on para modificaciones en la estructura arb´orea del documento. Por ejemplo, la inserci´on, el eliminado de nodos o la manipulaci´on repetida del valor de atributos, puede ser realizada de forma directa atacando las partes del ´arbol afectadas sin que el resto sufra modificaciones, siendo estos tratamientos a su vez muy eficientes en el tiempo, toda vez que el principal consumo de recursos se realiza en el an´alisis inicial del documento. As´ı pues, DOM resulta ser una tecnolog´ıa especialmente adecuada para realizar tareas para las que otras tecnolog´ıas mencionadas en este cap´ıtulo, como XSLT o XQuery no son adecuadas. Adem´as, dado que, los documentos del Web no suelen ser demasiado grandes, el problema de esta los requisitos de memoria de DOM pasan a estar en un segundo plano cuando se trata de ser aplicado al tratamiento de p´aginas Web.

4.6.1.

Aportaciones de DOM

Sin duda alguna, de todas las tecnolog´ıas de este cap´ıtulo, DOM es la m´as potente y flexible para realizar tareas de integraci´on de datos semiestructurados en el Web. Su capacidad de permitir recorridos por el documento en cualquier forma y sentido la convierten en ideal para poder realizar diversas 122

extracciones de datos de un mismo documento, algo, por otra parte habitual en el ´ambito de trabajo afrontado en esta tesis. La supuesta sobrecarga de recursos necesarios para su procesamiento tampoco es en s´ı un problema, ya que los clientes, muy al contrario que muchos servidores Web, tienen muchas veces recursos m´as que suficientes para procesar las p´aginas del Web que van consultando, las cuales, dicho sea de paso, tampoco suelen tener un tama˜ no excesivo. Ahora bien, si bien la idea de representar documentos en forma de ´arbol es una aportaci´on realmente importante para el trabajo de esta tesis, el interfaz DOM en s´ı mismo presenta la importante desventaja de presentar al usuario un nivel de abstracci´on bastante bajo, lo cual redunda en que, incluso para las operaciones m´as sencillas, sean necesarias varias l´ıneas de c´odigo. Adem´as su orientaci´on imperativa precisa que cualquier tipo de navegaci´on en el documento deba realizarse solicitando al programador todo lujo de detalles, en lugar de usar expresiones de m´as alto nivel de abstracci´on. Una soluci´on al problema podr´ıa ser la combinaci´on de bibliotecas para XPath 2.0 usadas desde programas implementados conforme al interfaz DOM. Lamentablemente no existen bibliotecas disponibles que implementen la funcionalidad de XPath 2.0, ya que las pocas existentes est´an definidas sobre la versi´on anterior de ese est´andar. En definitiva, DOM aporta una excelente forma de representar documentos navegables en memoria en forma de ´arbol, pero su interfaz concreto tiene un nivel demasiado bajo para los programadores.

4.7.

SAX

Al margen de las especificaciones del W3C, un grupo de programadores, moderados por David Megginson en la lista de correo electr´onico xml-dev ha desarrollado un interfaz de programaci´on orientado al procesamiento eficiente de documentos XML. Para ello, en lugar de procesar todo el documento para obtener una representaci´on en memoria del mismo, este interfaz se encarga de permitir al usuario definir el comportamiento del procesador del documento ante el evento de leer cada una de sus partes seg´ un ´estas van siendo obtenidas del documento de entrada. Ello permite que el an´alisis de grandes documentos XML pueda realizarse seg´ un los elementos del documento XML van siendo procesados, uno a uno, sin necesidad de ir guardando todo lo le´ıdo hasta el momento. SAX es un interfaz que permite, pues el an´alisis en secuencia del documento XML de entrada y es muy recomendable para el an´alisis de grandes documentos. Una de sus principales desventajas, sin embargo, se deriva del hecho de que SAX no es un interfaz de programaci´on adecuado 123

para la manipulaci´on de documentos, ya que en el c´odigo de la programaci´on de cada evento ocurrido en el procesamiento, no se puede tener acceso a las partes del documento procesadas con anterioridad.

4.7.1.

Aportaciones de SAX

Aunque factible para realizar ciertas labores sencillas, SAX resulta ser una tecnolog´ıa inapropiada para afrontar los objetivos de esta tesis. Su bajo nivel de abstracci´on, demasiado particularizado a un tratamiento espec´ıfico (el procesamiento secuencial orientado a eventos), le impide ser considerado como una tecnolog´ıa adecuada para la extracci´on de datos relevantes en documentos XML, no s´olo por la dificultad que impone el interfaz para el acceso a estructuras de datos de complejidad media o alta, sino por el hecho de que implica realizar programas con un elevado n´ umero de l´ıneas de c´odigo, 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 documentos en el Web son p´aginas de tama˜ no relativamente bajo estando los retrasos causados principalmente por la latencia en la respuesta de los servidores y la red, m´as que el consumo de recursos de memoria de los clientes, por lo que, aunque sin perder de vista el factor de la eficiencia, ´este resulta no ser algo cr´ıtico en los momentos actuales, al menos dentro del procesamiento de documentos XML. Sin embargo, SAX es una opci´on basada en el uso de comportamientos definibles por el usuario y es muy adecuada para el procesamiento de documentos de gran tama˜ no. Pese a que en los ejemplos pr´acticos el tama˜ no de los documentos en el Web no suelen ser demasiado voluminosos, un interfaz basado en este tipo de procesamiento puede ser deseable para automatizar tareas en el Web donde el volumen de los datos en un mismo documento suponen un tama˜ no considerable, por lo que no deben descartarse las aportaciones de SAX cuando sea necesario un tratamiento m´as eficiente de los documentos.

124

Cap´ıtulo 5 XTendedPath: Lenguaje para la consulta y modificaci´ on de documentos XML El lenguaje XTendedPath descrito en este cap´ıtulo es una propuesta de lenguaje que tiene dos usos principales: la consulta y la modificaci´ on de documentos XML, labores clave en el tratamiento automatizado de datos por parte de tareas que navegan autom´aticamente por el Web. La consulta de documentos es clave para la extracci´ on de datos relevantes, una de las acciones b´asicas expl´ıcitas mencionadas en el apartado 2.2. La modificaci´on es clave para otras acciones, como la eliminaci´on de datos irrelevantes, la emulaci´on de comportamientos JavaScript cuando ´estos afectan a la estructura del documento o para otros comportamientos relacionados con formularios. Por ejemplo, muchas veces, el documento Web no est´a formado s´olo por contenidos generados en el servidor, sino que otros son generados en el cliente por JavaScript. Por otro lado, en ocasiones la mejor representaci´on interna de un formulario relleno es el propio sub´arbol del documento que contiene ese formulario como elemento. As´ı pues, realizar modificaciones en el rellenado de ese formulario requiere entonces poder realizar modificaciones en la representaci´on arb´orea del documento. XTendedPath, al contrario de otras propuestas ya existentes como las mencionadas en el cap´ıtulo 3, est´a basada en varios est´andares del W3C espec´ıficamente dise˜ nados para el direccionamiento de datos en el Web, como son el actual borrador de XPath 2.0 [141] y el est´andar XPointer [138], aunque tambi´en toma ideas de XQuery, DOM y XUpdate. Hasta el momento actual, ning´ un trabajo conocido por el autor dentro del campo de la extracci´on de 125

datos del Web legado ha utilizado XPath 2.0. De los trabajos mencionados en el cap´ıtulo 3, s´olo los m´as avanzados, como [94] han usado apenas XPath 1.0, que es la versi´on que est´a estandarizada actualmente, la cual se ha encontrado normalmente embebida dentro de hojas de estilo XSLT 1.0, para extraer los datos en forma de documentos. Otros trabajos, como [111] hacen uso de XQuery como lenguaje de consulta, pero s´olo son aplicables a p´aginas Web muy estructuradas, asimilables a tablas y datos muy regulares, lo cual no es siempre factible. Por el contrario, XTendedPath est´a dise˜ nado para poder ser usado en cualquier p´agina HTML o XML pese a que ´esta carezca de una fuerte estructura.

5.1.

Problemas de XPath 2.0

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

5.1.1.

Procesamiento incremental

La expresi´on “for” en XPath 2.0 no puede ser usada cuando el resultado de procesar cada elemento en una secuencia depende del procesamiento de los elementos anteriores. Es posible que en algunos casos ese procesamiento s´ı pueda realizarse, pero de una manera muy ineficiente. Por ejemplo: Calcular el producto de todos los n´ umeros 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 soluci´on XPath 2.0 es dif´ıcil e ineficiente es el siguiente: Dada una secuencia de nodos book dentro de un documento XML que refleja las ventas de una tienda, calcular la cantidad de dinero vendido por cada libro (calculada como el producto de su precio por su n´ umero de unidades vendidas). El resultado debe devolverse en una secuencia de pares t´ıtulo, importe acumulado, donde t´ıtulo es el t´ıtulo de cada libro de la secuencia e importe acumulado es el importe acumulado por las ventas de los libros hasta ese momento, desde el principio de la secuencia de libros hasta el libro correspondiente a cada posici´on. Para obtener ese resultado, se puede usar la expresi´on escrita en XPath 2.0 que aparece en la figura 5.1: for $i in (1 to count($items)) return ($items[$i], sum( for $j in (sublist($items, 1, $i)) return (@price * @sales) ) )

Figura 5.1: Expresi´on XPath 2.0 que calcula importe de ventas con subtotales parciales La expresi´on de la figura 5.1 tiene complejidad cuadr´atica. Es decir, si N es el n´ umero de elementos dentro de $items, se realizan N × (N + 1) / 2 sumas y N × (N + 1) / 2 multiplicaciones, lo cual es bastante ineficiente desde un punto de vista de complejidad de algoritmos. Para conseguir expresar el algoritmo con complejidad lineal, mucho m´as eficiente, ser´ıa necesario usar una variable que acumulara las sumas parciales realizadas hasta el momento, con el fin de no volverlas a recalcular en posteriores iteraciones. As´ı pues, el algoritmo anterior deber´ıa poder reescribirse de una forma similar a la que aparece en la figura 5.2: $s = 0; for $i in (1 to count($items)) $s = $s + (@price * @sales); return ($items[$i], $s)

Figura 5.2: Pseudoc´odigo basado en variables que calcula subtotales 127

Pese a lo que pudiera parecer, la expresi´on de la figura 5.2 no es una expresi´on XPath. XPath es un lenguaje funcional basado en expresiones, no un lenguaje imperativo basado en sentencias, por lo que no permite la posibilidad de tener un bucle dentro del cual haya dos expresiones que deban ser evaluadas una detr´as de otra como sentencias imperativas. El constructor for de XPath solamente admite una expresi´on return en su interior, que sirve para devolver el elemento que debe formar parte de la secuencia resultado, conforme se va recorriendo una secuencia de entrada. Por otro lado, pese a que en los lenguajes imperativos sea algo com´ un que una variable vaya siendo sobreescrita con diversos valores a lo largo de la ejecuci´on, los lenguajes funcionales no permiten ese tipo de efectos laterales, porque se dedican a la mera evaluaci´on de expresiones funcionales en las que los resultados se obtienen de aplicar funciones a unos argumentos. Dicho de otro modo, las variables en XPath pueden ser consultadas f´acilmente, pero no pueden ser sobreescritas como en un lenguaje de programaci´on imperativo. Por ese motivo, el c´odigo de la figura 5.2 deber´ıa en todo caso ser reconsiderado por uno que carezca de este tipo de problemas de efectos laterales y que tenga una notaci´on completamente funcional, como el que aparece en la figura 5.3. sumalibros = function ($items, $acum) if $items = () then () else let $primer = first($items), $producto = $primer/@price * $primer/@sales in ($primer, $acum + $producto, sumalibros(tail($items), $acum + $producto)) end sumalibros($items, 0)

Figura 5.3: Pseudoc´odigo basado en funciones que calcula subtotales Como puede apreciarse en la figura 5.3, el c´odigo que aparece tiene una notaci´on completamente basada en expresiones y no en sentencias, propio de un lenguaje de programaci´on funcional. Para ello se ha creado una funci´on auxiliar llamada sumalibros que devuelve la secuencia vac´ıa cuando la secuencia de entrada $items est´a vac´ıa y genera el resultado de la forma deseada, acumulando el producto de cada libro en un subtotal que se va acarreando para el resto de los elementos de la secuencia. Para construir el c´odigo de la figura 5.3 se han usado dos importantes caracter´ısticas no existentes en XPath 2.0. Por un lado, se ha definido una funci´on auxiliar de usuario, denominada sumalibros de dos argumentos y posteriormente se ha llamado a esa funci´on para calcular el resultado final. En 128

t´erminos de programaci´on funcional al nombre sumalibros se le ha asociado una expresi´on lambda [90] o funci´on de usuario. Los lenguajes funcionales suelen definir tambi´en variables con una construcci´on let en la que se declara una variable a la que se le asocia un valor que es inmutable a lo largo de toda la ejecuci´on, como por ejemplo en la expresi´on: let $i = 3 in $i + $i, cuyo resultado ser´ıa 6. Sin embargo, ni las expresiones lambda ni el constructor let forman parte del lenguaje XPath. El constructor let (que a su vez tambi´en puede ser reescrito como una expresi´on lambda) forma parte del lenguaje XQuery (basado en XPath 2.0), pero no est´a considerado en XPath 2.0. Por otro lado, aunque en XPath est´a permitida la llamada a funciones, ´estas no tienen forma de ser construidas por los usuarios y su uso se limita a un conjunto reducido de funciones localizables en bibliotecas del lenguaje.

5.1.2.

Dificultad para calcular valores agregados

XQuery permite la definici´on de funciones de usuario y del constructor let. Sin embargo XQuery, al igual que XPath, presenta dificultades para calcular valores agregados de una secuencia, especialmente cuando esos valores deben ser calculados de una forma no trivial. Por ejemplo: Obtener los nodos con m´aximo valor de una secuencia, especialmente en el caso en el que el valor de cada nodo de esa secuencia deba ser computado por una expresi´on compleja. Obtener los nodos con distinto valor de una secuencia, especialmente en el caso en el que el valor de cada nodo de esa secuencia deba ser computado por una expresi´on compleja. En XPath 2.0 no existe una forma gen´erica de evaluar este tipo de expresiones recibiendo como par´ametro una funci´on que eval´ ue esas expresiones complejas a las que se hace referencia. Por esa raz´on, en XPath 2.0 deben escribirse multitud de expresiones similares, cada una de ellas para cada posible expresi´on compleja y sin posibilidad de ser reutilizadas. Estas repeticiones y la falta de capacidad de reutilizaci´on del c´odigo provoca grandes consumos de tiempo, propensi´on a errores y generalmente ocasionan la generaci´on de c´odigo dif´ıcilmente mantenible y poco reutilizable. Ejemplos de problemas de este tipo son los siguientes: Obtener la suma de los cuadrados de los n´ umeros de una secuencia 129

Extraer aquellos n´ umeros de una secuencia, para los cuales f(item) es m´ınimo Para una funci´on f(), comprobar que todos los valores f(item) de una secuencia son mayores que cero (o menores o iguales a cualquier otro valor) Para una funci´on f(), comprobar que todos los valores f(item) de una secuencia aparecen en orden creciente Para las expresiones anteriores, aunque es posible encontrar una soluci´on basada en XPath, ´esta ser´a dif´ıcil e ineficiente. Adem´as, para cada posible funci´on f() deber´a reescribirse cada expresi´on, ya que las funciones no pueden ser pasadas como argumentos a otras funciones.

5.1.3.

Combinar dos o m´ as secuencias en una nueva

Es posible querer combinar dos o m´as secuencias en una sola. Dadas (a1 , a2 , ..., aN ) y (b1 , b2 , ..., bN ) con XPath no es sencillo calcular expresiones como: (a1 + b1 , a2 + b2 , ..., aN + bN ) (suma elemento a elemento) (a1 × b1 , a2 × b2 , ..., aN × bN ) (producto elemento a elemento) (a1 ∧ b1 , a2 ∧ b2 , ..., aN ∧ bN ) (conjunci´on l´ogica and elemento a elemento) ...

5.1.4.

XPath no puede expandirse indefinidamente

La complejidad de XPath ha crecido considerablemente en los u ´ltimos tiempos, pasando de ser un sencillo conjunto de expresiones a un lenguaje mucho m´as potente. Sin embargo, la capacidad de seguirse expandiendo resulta un tanto limitada. Por otro lado, aunque en el grupo de trabajo est´an trabajando en una homogeneizaci´on del lenguaje, existen ahora mismo varias formas de expresar tareas similares. Ello indica hasta qu´e punto es necesario reordenar la capacidad de expansi´on del lenguaje, y que actualmente est´a a´ un en una fase inmadura y es compleja y dif´ıcil de organizar. Un lenguaje que 130

proporcione soporte al orden superior puede proporcionar una soluci´on simple y elegante, a la vez que flexible y potente. Ser´ıa deseable que las principales funcionalidades del lenguaje (operadores, constructores y funciones) pudieran ser reducidas a un m´ınimo mientras que el lenguaje permita que nuevas funcionalidades puedan ser f´acilmente producidas y acumuladas en una biblioteca de funciones reusables de uso general.

5.1.5.

Poca flexibilidad para llamar a ciertas funciones

La llamada a funciones como sort o distinct-values resulta poco flexible ya que no es posible especificar las funciones de comparaci´on entre elementos. Ser´ıa deseable poder ordenar una secuencia pudiendo especificar el criterio de ordenaci´on en una funci´on definible por el usuario y con la que se pudiera parametrizar el comportamiento de la funci´on sort.

5.1.6.

Poca reusabilidad para expresiones de tipo “for”

En la expresi´on de la figura 5.4, la expresi´on expression no puede ser reutilizada, salvo que se copie y pegue en otro sitio, debiendo ser modificada de forma que las referencias a la variable del rango que recorre la secuencia sean convenientemente renombradas. for $i in $sequence return expression

Figura 5.4: Ejemplo de expresi´on de tipo for Por el contrario, con soporte a funciones de orden superior, podr´ıa usarse la funci´on map(f, $sequence) como equivalente a la de la figura 5.4 de forma que el c´odigo de la funci´on f() no deba ser modificado.

5.2.

Soluciones basadas en funciones de orden superior

Suponiendo que en XPath se pudieran definir funciones de orden superior, los problemas listados en el apartado 5.1 podr´ıan ser resueltos de forma 131

sencilla. Dado que, lamentablemente, no existe en XPath la posibilidad de definir funciones de usuario, para demostrar la facilidad de programaci´on de esta aproximaci´on y su f´acil legibilidad por los usuarios programadores, los siguientes ejemplos est´an proporcionados en lenguaje Haskell [113]. En el apartado 5.5.2 se proporciona una reescritura de este tipo de funciones en XTendedPath, la extensi´on de XPath que se presenta en el apartado 5.3. El lenguaje Haskell se usa en este apartado solamente como ejemplo de conveniencia. En ning´ un caso se intenta recomendar con ello que su sintaxis sea adoptada por XPath 2.0. Para comprender los siguientes ejemplos, algunas convenciones de Haskell deben ser explicadas. Convenciones de representaci´ on en Haskell Definir una funci´on en Haskell es muy sencillo. La expresi´on f x y = x * y define una funci´on f que devuelve el producto de sus dos argumentos. La expresi´on [1, 2, 3] expresa una lista formada por tres elementos, similar a la secuencia (1, 2, 3) de XPath. [] denota la secuencia vac´ıa, equivalente a () en XPath. Un operador infijo puede ser usado como una funci´on cuando se le escribe entre par´entesis. De esta forma: (+) 1 2 = 1 + 2 = 3. El operador : es usado para indicar que un elemento est´a al principio de una lista. De esta forma, x : xs define una lista donde x es el primer elemento y xs es el resto de la lista. La funci´on flip toma como argumento una funci´on y otros dos argumentos y produce como resultado la llamada a esa funci´on tomando los argumentos en orden inverso. As´ı: flip f x y = f y x. Igualmente, la recursi´on a lo largo de los elementos de una lista puede ser definida como aparece en la figura 5.5. La funci´on foldl toma tres argumentos, una funci´on f(), que toma dos argumentos, un valor z y una lista. foldl es una de las funciones m´as generales que trabajan sobre listas. Recorre la lista de izquierda a derecha, aplicando f() a cada elemento y al resultado acumulado hasta el momento, que es tenido en cuenta para el siguiente elemento de la lista. De una forma similar, tambi´en puede ser definida foldr. Como puede comprobarse f´acilmente, foldl (+) 0 xs es la suma de todos los elementos que aparecen en la secuencia xs. De la misma forma, podr´ıa escribirse sum xs = foldl (+) 0 xs para definir la funci´on sum. An´alogamente, se podr´ıa definir product xs = foldl (*) 1 xs que calcular´ıa el producto de los elementos de una secuencia, lo cual ser´ıa una soluci´on para uno de los 132

foldl f z [] foldl f z (x:xs)

= z = foldl f (f z x) xs

Figura 5.5: Ejemplo foldl en Haskell problemas apuntados en el apartado 5.1.1. Por otra parte, las funciones pueden usarse de forma currificada, lo cual quiere decir que las definiciones anteriores podr´ıan haber sido reescritas de la siguiente forma: sum = foldl (+) 0 y product = foldl (*) 1. Invertir el orden de una lista (problema apuntado en la secci´on 5.1.1) puede ser f´acilmente realizable con reverse = foldl (flip (:)) []. Concatenar los elementos de una lista (problema tambi´en apuntado en la secci´on 5.1.1) puede realizarse llamando simplemente a la funci´on concat = foldr (++) [] donde (++) es el operador de concatenaci´on para listas. Por otro lado, combinar dos listas de igual longitud en una sola puede ser realizado con la funci´on zip() que aparece en la figura 5.6. En ella, la funci´on f() es aplicada a cada par de elementos de la misma posici´on en ambas listas, y el resultado de esa funci´on forma el elemento que est´a en esa posici´on dentro de la secuencia resultado. zip f (a:as) (b:bs) zip _ _ _

= f a b : zip f as bs = []

Figura 5.6: Ejemplo zip en Haskell La funci´on zip() resuelve directamente muchos de los problemas mencionados en el apartado 5.1.3. Por ejemplo (a1 + b1 , a2 + b2 , ..., aN + bN ) es solamente zip (+) as bs. (a1 × b1 , a2 × b2 , ..., aN × bN ) es solamente zip (*) as bs. Una funci´on muy u ´til es scanl(), definida en la figura 5.7. scanl f q ys = q : (case ys of [] -> [] x:xs -> scanl f (f q x) xs)

Figura 5.7: Ejemplo scanl en Haskell 133

scanl es similar a foldl, salvo por el hecho de que crea una lista con todos los resultados intermedios acumulados, de forma que el primer elemento de la lista resultado es q y el u ´ltimo es el resultado acumulado de toda la lista de entrada. La longitud de la secuencia de salida es superior a la de entrada en una unidad. En el caso en el que est´e garantizado que la secuencia de entrada xs no est´e vac´ıa, la siguiente funci´on scanl1 puede ser definida, conforme a la figura 5.8. scanl1 f (x:xs)

= scanl f x xs

Figura 5.8: Ejemplo scanl1 en Haskell scanl1 se comporta igual que scanl, salvo que no toma un argumento como base o elemento neutro, sino que toma al primer elemento de la lista como elemento base para calcular las acumulaciones. Como puede comprobarse, scanl1 op xs produce una lista de longitud igual a la de xs en la que aparecen los resultados acumulados de la operaci´on op desde el principio de la lista hasta la posici´on actual. Por ejemplo: scanl1 (+) [1, 2, 3] = [1, 1+2, 1+2+3] = [1, 3, 6]. scanl1 puede ser usado en combinaci´on con zip para resolver el problema mencionado en el apartado 5.1.1. Por ejemplo, scanl1 (+) (zip (*) [1,2,3] [2,2,2]) devuelve [2, 6, 12], que es b´asicamente lo que se quer´ıa calcular con el problema de las ventas de los libros. Si se asocia a la funci´on filter el significado de los predicados de XPath, de forma que filter p xs = [ x | x ∈ xs ∧ p x ], pueden encontrarse f´acilmente soluciones para los problemas mencionados en el apartado 5.1.2. Por ejemplo, se pueden calcular todos los elementos de una secuencia para los cuales f(item) es m´ınimo con la expresi´on de la figura 5.9. En ella se declara ys como una lista temporal que almacena el resultado de aplicar la funci´on f() a la secuencia de entrada, se declara fmin como el m´ınimo valor de esa secuencia, y a continuaci´on se seleccionan aquellos elementos de la secuencia de entrada para los que f() da ese valor m´ınimo fmin. El punto es considerado en Haskell como el operador de composici´on de funciones. De una forma similar, en la figura 5.10 se puede comprobar si para todos los elementos de una secuencia se cumple que una funci´on f() devuelve resultados positivos. Finalmente, comprobar que, para una secuencia y una funci´on f(), el re134

minvals f xs = let ys = map f xs in let fmin = minimum ys in filter ((= fmin) . f) xs

Figura 5.9: Elementos para los que f() es m´ınimo allFPositive f xs = let ys = map (( > 0) . f) xs in foldl and true ys

Figura 5.10: Determinar si para una secuencia se devuelve todo positivo sultado de aplicar f() a la secuencia proporciona una secuencia ordenada creciente, es igualmente sencillo. En la figura 5.11 aparece un ejemplo basado en foldl y zip. En ella se declara zs como el resultado de aplicar f() a la secuencia de entrada. Posteriormente, la lista zs es fragmentada en dos sublistas. init zs contiene la sublista en la que se ha eliminado el u ´ltimo elemento y tail zs contiene la sublista en la que se ha eliminado el primer elemento. Para esas dos sublistas, se comprueba que los elementos est´an ordenados por parejas y finalmente se dilucida si todas esas parejas cumplen el hecho de estar ordenadas o si, por el contrario, hay alg´ un elemento en desorden. allFIncreasing f xs = let zs = map f xs in let ys = zip (