Isaac Bernardo Caicedo Castro¹ y Francisco Rueda Fajardo²

¹ Ingeniero informático, Universidad Pontificia Bolivariana, Montería, Colombia. M-Sc., en Ingeniería de Sistemas y Computación, Universidad de los Andes, Bogotá, Colombia. Investigador y docente, grupo SÓCRATES, Universidad de Córdoba, Montería, Colombia. ib.caicedo45@egresados.uniandes.edu.co, isaaccaicedo@sinu.unicordoba.edu.co
² Ingeniero de sistemas y computación, Universidad de los Andes, Bogotá, Colombia. D.E.A., en informatique, Université Scientifique et Medicale de Grenoble, Francia. Investigador y docente, grupo COMMIT, Universidad de los Andes, Bogotá, Colombia. frueda@uniandes.edu.co

RESUMEN

Actualmente la mayoría de los recursos de la World Wide Web (WWW) son accesibles desde PC y mediante HTTP sin embargo, se están realizando investigaciones, herramientas y propuestas para el desarrollo de aplicaciones multimodales que permitan el acceso a recursos de la WWW desde diversos dispositivos y por variados mecanismos. La motivación para el desarrollo de aplicaciones multimodales y multidispositivos reside en la conveniencia de las organizaciones en evitar la replicación de información y servicios disponibles en sus aplicaciones y páginas web. En el presente artículo se describe la estructura de una herramienta que permite el acceso multimodal y multidispositivo a recursos de la WWW a través de HTTP, SMS, WAP, MMS y S@T. El principal aporte de este trabajo consiste en proponer una arquitectura posible y sencilla para realizar lo anterior y en validarla mediante la implementación de un prototipo.

Palabras clave: multimodal, multidispositivo, SMS, WAP, MMS, S@T, WWW, XHTML, WML, S@TML.

ABSTRACT

Most World Wide Web (WWW) resources are currently accessible from PCs and through HTTP; however, multimodal application research is being carried out and tools and proposals are being developed allowing access to WWW resources from several devices and mechanisms. The motivation for developing multimodal and multi-device applications has arisen from organisations’ need to avoid duplicating information and services available in applications and web pages. This article describes the structure of a tool allowing multimodal and multi-device access to WWW resources through HTTP, SMS, WAP, MMS and S@T. This work’s main contribution lies in its proposing a possible and simple architecture for accomplishing this and validating it through implementing a prototype.

Keywords: multimodal, multi-device, SMS, WAP, MMS, S@T, WWW, XHTML, WML, S@T.

Recibido: marzo 3 de 2008
Aceptado: octubre 24 de 2008

Introducción

Actualmente se observa que las organizaciones requieren publicar información y servicios a través de la WWW, y replicarlos mediante aplicaciones que proveen la misma información y servicios a través de modalidades de uso propias de la tecnología celular como SMS, MMS, S@T y WAP.

Esto es así porque muchas personas no tienen acceso a PC, y si lo tienen, tal vez no pueden acceder a Internet y por ende a la WWW no obstante, hay muchos usuarios de telefonía celular con acceso a los servicios que soportan las modalidades previamente mencionadas.

Cada modalidad de uso de un teléfono celular tiene ventajas para los usuarios clientes, por ejemplo, un usuario que utiliza WAP puede navegar a través del micronavegador del dispositivo celular por la WWW. SMS es útil para enviar información en forma económica, pero la inclusión de información para enviar en un mensaje SMS es bastante incómoda por el teclado tan reducido de los dispositivos celulares. En ese sentido, S@T, que permite navegar a través de un menú, puede ser una opción más cómoda debido a que el usuario prefiere seleccionar información en vez de ingresarla. Otra alternativa es MMS, que permite utilizar algunos accesorios extra que vienen incorporados en los dispositivos celulares, como la cámara fotográfica, con la cual el usuario puede tomar una fotografía y anexarla en un mensaje para enviársela a un sistema que le retorne información basada en el contenido del mensaje y la imagen o imágenes anexas a él.

A través de las modalidades de uso anteriores, una organización tiene la posibilidad de utilizar la tecnología para automatizar y mejorar sus procesos de atención a los clientes y estos pueden gozar de los servicios informáticos de las entidades mediante su dispositivo celular aun cuando no tengan acceso a un PC. Además, los operadores de comunicaciones se verán beneficiados pues se aumentará el tráfico en sus redes.

Lo anterior conduce a pensar que es conveniente que los usuarios puedan tener acceso a los recursos de la WWW a través de medios distintos del PC. El mecanismo tradicional que se ha usado para este propósito hasta ahora es el de replicar la información (tener una aplicación diferente para cada modalidad de acceso). Para evitarlo, sería conveniente contar con una herramienta que permitiera el acceso multimodal a los recursos de la WWW, como se ilustra en la Figura 1.

La implantación de la multimodalidad ha sido abordada por trabajos anteriores referidos en la literatura al respecto. El inconveniente de estas soluciones es que, o abarcan un reducido número de modalidades (por ejemplo, sólo la web tradicional y wav, o la web tradicional y voz ), o requieren de una capacidad especial de los dispositivos (como la posibilidad de manejar XHTML o de interpretar ciertos lenguajes), o se basan en la definición de lenguajes genéricos no estandarizados, cuyo uso generalizado es cuando menos dudoso. Otro aspecto que las soluciones no tienen en cuenta es el manejo de imágenes.

A continuación se examinarán los trabajos más importantes relacionados con el acceso multimodal a recursos web, luego se describirán el diseño de la solución propuesta y la implementación de un prototipo, y finalmente, se presentarán las conclusiones del trabajo.

Trabajos relacionados

La primera aproximación para permitir el acceso a un portal web desde diversos dispositivos y por diferentes modalidades de conexión consiste en mantener los recursos replicados, lo cual conduce a codificar la información en varios formatos: en HTML para que puedan accederla los PC de escritorio y portátiles, en WML para que puedan accederla teléfonos celulares y PDA a través de WAP; además, en construir aplicaciones especiales para interactuar por otras modalidades de conexión como SMS o MMS. Los inconvenientes de este enfoque, que a veces se llama "múltiple authoring" (Simon, Wegscheider y Tolar, 2005) son los típicos de la replicación: duplicación de trabajo, posibilidad de inconsistencias y dificultad de mantenimiento.

Otra posibilidad es usar formatos estándar como XHTML; sin embargo, no todos los dispositivos livianos pueden accederlo (por ejemplo, los teléfonos celulares más antiguos).

Otra tendencia es convertir un recurso codificado en un formato neutro, como XML o XHTML, al formato objetivo (digamos, WML), automatizando así la tarea de elaboración del sitio alterno para ser accedido por WAP, lo cual es una mejora sobre el enfoque previo (entre otros, HTML2WML (Maddingue, 2007), Lazy WAP (Tourbase, 2007), y Saxon, y Tidy (Wilson, 2007) ). Estos traductores realizan la labor estáticamente, es decir, es el desarrollador o web máster el que ejecuta la herramienta sobre el recurso original y publica este recurso y el traducido en el servidor web, con lo cual hay replicación de recursos. Otra posibilidad es que la traducción la haga dinámicamente el servidor de contenido (Pathan, Mottalib y Zibran, 2006) o un servidor especial, como en el caso del proyecto MONA (Wegscheider, Dangl, Jank y Simon, 2004).

Por otra parte, el estándar tecnológico VoiceXML, desarrollado y administrado por VoiceXML Forum (Voice, 2007), permite el acceso a contenido de la WWW a través de teléfonos, mediante diálogos. El componente encargado de traducir los documentos VoiceXML a audio, y viceversa, es la pasarela VoiceXML (tal los casos Voxeo voice center platform (Voxeo, 2007) y JVoiceXML (SourceForge.net, 2007)).

Con base en VoiceXML y XHTML el W3C hizo una especificación llamada XHTML + Voice Profile (W3C, 2001), para habilitar el acceso multimodal a recursos de la WWW.

También, el W3C ha sugerido en un documento borrador la arquitectura multimodal que especifica un marco de trabajo en tiempo de ejecución y un API de eventos para la comunicación entre componentes multimodales (W3C, 2006).

Algunas propuestas le permiten al desarrollador especificar la interfaz usando un conjunto de widgets genéricos, que son implementados en las variadas plataformas objetivo. Algunos lenguajes como AUIML (Azevedo, Merrick y Roberts, 2005) o UIML (Abrams, Phanouriou, Batongbacal, Williams, y Shuster, 1999) han sido desarrollados con este propósito. En (Souchon N. y Vanderdonckt J., 2003) hay una comparación entre las propuestas más importantes basadas en este enfoque.

El presente trabajo, enfocado principalmente a teléfonos celulares pero también aplicable a otros dispositivos móviles tiene la ventaja de que no implica replicación de la información. Tampoco requiere de características especiales en el dispositivo. En forma similar que algunos de los trabajos presentados más arriba, la solución propuesta permite una traducción dinámica de un formato neutro al requerido por el dispositivo, pero a diferencia de los trabajos presentados no se limita a traducir a WML sino que admite otros modos de comunicación como SMS, MMS y S@T. Entre las mencionadas, la única propuesta que admite estas modalidades es la formulada por la W3C, pero a diferencia de esta nuestro trabajo no está sujeto a la lógica de negocio de una aplicación web, o al contenido de una página web, como las aplicaciones que se ciñen a la sugerencia de la W3C.

La arquitectura presentada aquí no contempla el manejo de voz, y por lo tanto no es comparable a los sistemas que tienen como centro esta problemática. La extensión del sistema para que contemple esta facilidad es un desafío futuro.

La propuesta hecha en este artículo es más práctica que las que buscan representar la interacción con el usuario mediante un lenguaje genérico, pues se basa en el uso de un estándar como XHTML.

El sistema llamado Photo – to – Search (Fan, Xie, Li, Mingjing y Ma, 2005) es una propuesta para la búsqueda basada en imágenes de recursos en la web. El permitir el uso de imágenes es interesante teniendo en cuenta la dificultad de interacción a través del teclado en los teléfonos celulares y la funcionalidad que tienen muchos de ellos de permitir tomar fotos. Así, se podría tomar la fotografía de un código de barras, anexarla a un mensaje MMS y enviarlo a un sistema que devuelva el precio del artículo asociado con dicho código. Por lo anterior, en este trabajo se tendrá en cuenta esta facilidad.

Diseño de la solución

En el modelo propuesto la conexión de un cliente con el servidor de origen (en donde está la información que se desea consultar o modificar) se hace por medio de un servidor Proxy multimodal o SPM.

En esta sección se describen su arquitectura y funcionamiento.

Arquitectura

Con el fin de describir el diseño del SPM, se traen a colación los siguientes componentes de la arquitectura (ver Figura 2):

-Controlador: este componente es el encargado de recibir y atender las solicitudes de los clientes y de invocar los servicios de los demás componentes para el procesamiento de las solicitudes correspondientes. Es semejante al marco de trabajo en tiempo de ejecución propuesto en la recomendación del W3C.

-AnalizadorSolicitud: componente que se encarga de analizar las solicitudes recibidas por el controlador, y de identificar la modalidad mediante la cual se reciben las solicitudes, y las modalidades en la que le deben enviar las respuestas a los clientes. Además, debe identificar los recursos y los servidores de origen a los que desean acceder los clientes, los parámetros con los valores utilizados para realizar las solicitudes, y el formato al que se deben traducir las respuestas a los clientes. Este componente es similar al de entrega de contexto propuesto por el W3C.

En el caso en el que un cliente solicite una imagen, el Analizador Solicitud, con base en el perfil del dispositivo cliente, determina a qué formato se debe transformar la imagen, de tal forma que sea la de mejor calidad que pueda soportar dicho dispositivo.

Para determinar el perfil de los clientes, cuando la solicitud llega por WAP este componente emplea el User-Agent del dispositivo, y el Wireless Universal Resource File (WURF) (Wurf, 2007) que es un archivo en formato XML que contiene información de todos los dispositivos livianos y móviles del mundo. Otra alternativa es el UAProf; sin embargo, el WURF tiene varias ventajas sobre esta alternativa, como las de poder ser mantenido por una comunidad y modificarse si tiene errores o si aparece un nuevo dispositivo. Otra ventaja es que WURF es consultado localmente y no remotamente como UAProf.

Por otro lado, para determinar el perfil de los dispositivos clientes cuando la solicitud es hecha en las modalidades S@T, SMS o MMS, en dicha solicitud debe ir anexo el valor Internacional Mobile Equipment Identity (IMEI), que es un código en los teléfonos celulares que los identifica unívocamente a nivel mundial. Con este valor el AnalizadorSolicitud debe, con la aprobación del operador celular y del fabricante del teléfono, consultar la base de datos Equipment Identity Register (EIR) para determinar el perfil del equipo.

Finalmente, para que el AnalizadorSolicitud determine la modalidad de la solicitud, primero debe verificar si el valor del campo User-Agent se encuentra en el archivo wurf.xml; si es así, significa que la modalidad es WAP, en otro caso es HTTP y el agente usuario es un navegador web ordinario. Si el campo User-Agent es nulo y viene anexo en la solicitud un parámetro llamado tipocanal, significa que la modalidad es S@T, pero si dicho parámetro no viene anexo se trata de SMS o MMS, y en dicho caso, la modalidad de la solicitud la deduce el SPM por el formato de la misma.

-Traductor: este componente está encargado de transformar la respuesta proveniente del servidor de origen, de un formato neutro en que está representada a un formato objetivo adecuado a las capacidades del dispositivo del cliente. El formato adecuado es determinado por el componente anteriormente descrito (AnalizadorSolicitud).

XHTML fue seleccionado como el lenguaje neutro para la codificación de recursos en los servidores de origen por ser estándar, fácil de utilizar y de aprender, y por ser conocido por la mayoría de desarrolladores y web másters, dado que se parece a su ancestro HTML. Otros lenguajes como AUIML, UIML y UsiXML, fueron descartados por no ser estándares ni muy conocidos y sí difíciles de aprender. Tampoco se seleccionó RIML porque está orientado a VoiceXML, cuya implementación va más allá del alcance de la investigación.

Es importante mencionar que no todas las etiquetas de XHTML se pueden emplear para la codificación de los recursos en el servidor de origen, porque hay etiquetas en XHTML que no tienen equivalencia en los formatos objetivos, por ejemplo las etiquetas <iframe>, <frame>, <applet>, <hr>, etc., no tienen equivalencia en WAP, S@T y texto plano. En este trabajo se hizo un análisis de todas las etiquetas de XHTML y de cuál era el tratamiento más adecuado en cada caso (Caicedo, 2007).

-ProxyWebCache: Este componente se encarga de almacenar las solicitudes y su respectiva respuesta de tal manera que si el recurso solicitado está almacenado en la caché y no ha sido modificado en el servidor de origen, se utiliza el que está en la caché. El objetivo es disminuir la latencia del acceso entre el SPM y los servidores de origen en aras de disminuir los tiempos de respuesta del SPM.

-AnalizadorImagenes: Por último, este componente se encarga de traducir una solicitud en forma de imagen a una cadena de texto, empleando un método similar al propuesto en (Fan, Xie, Li, Mingjing y Ma, 2005). Se utiliza cuando el usuario envía al servidor de origen una solicitud con una imagen anexa a un mensaje MMS.

Funcionamiento

En la interacción entre el cliente y el servidor de origen hay tres escenarios: el primero se presenta cuando la modalidad empleada por el cliente para enviar las solicitudes y recibir las respuestas es WAP, HTTP o S@T; el segundo, cuando el usuario envía un mensaje SMS o MMS sin una imagen anexa, y el tercero, cuando el usuario envía un mensaje MMS con una imagen anexa. En el último caso el componente encargado del análisis de imágenes debe prestar sus servicios. A manera de ejemplo, se presenta en detalle el funcionamiento del sistema para el primer escenario (Figura 3).

Si la solicitud es HTTP o WAP antes de solicitar un recurso al SPM, el cliente debe descargar de este un índice con la dirección de los recursos en servidores de origen disponibles. Dicho índice está compuesto por enlaces al SPM, pero con un parámetro llamado uri, cuyo valor es el URI de un recurso de algún servidor de origen.

En el caso de que la modalidad de la solicitud sea S@T, en cada ítem del menú en la tarjeta SIM se encuentra un enlace hacia el SPM y un parámetro anexo llamado uri cuyo valor tiene el mismo significado explicado previamente, y otro parámetro llamado tipo-canal que le sirve al AnalizadorSolicitud para determinar que la modalidad de la solicitud es S@T. Por omisión, el valor de éste parámetro es sat.

Los mensajes intercambiados entre los componentes del SPM (el rectángulo izquierdo de la Figura 3) en este escenario son los siguientes:

1. Mensaje que equivale a la solicitud que proviene del cliente y es interceptado por el controlador.

2. Mensaje que transmite la solicitud proveniente del cliente, del Controlador al AnalizadorSolicitud.

3. Con la información del mensaje previo, el componente AnalizadorSolicitud identifica la modalidad por donde fue recibida esta, consultando el valor del campo User-Agent del encabezado del mensaje. Con dicho valor también determina el perfil del dispositivo cliente realizando una búsqueda en el archivo llamado wurf.xml, y en este mensaje el Analizador Solicitud le envía al Controlador el URI del recurso en el servidor de origen que solicita el cliente, los parámetros que acompañan el URI en la consulta del recurso, la modalidad de la respuesta y el perfil del dispositivo cliente.

4. Mensaje del Controlador al ProxyWebCache donde le comunica el URI del recurso (que está en el servidor de origen) solicitado por el cliente para que lo obtenga de la caché, o bien, si fue actualizado en el servidor de origen, lo descargue de este.

5. Mensaje equivalente a un Get condicional emitido del ProxyWebCache al servidor de origen.

6. Si el recurso en el servidor de origen es el más actual, este le retorna en el presente mensaje el recurso actualizado, y el Proxy webCache lo almacena en caché. Pero en el caso contrario, el servidor de origen envía en el presente mensaje la confirmación de que el recurso no ha sido modificado (o actualizado).

7. Mensaje mediante el cual el ProxyWebCache envía el recurso al Controlador.

8. Mensaje emitido si el SPM tiene que convertir el recurso solicitado a WML o S@TML, en este caso el Controlador debe enviar el recurso al componente Traductor.

9. Mensaje mediante el cual el Traductor envía al Controlador el recurso en el formato apropiado.

10. Finalmente, este mensaje significa que el Controlador envía la respuesta al cliente.

Se pueden plantear esquemas similares para los otros escenarios (Caicedo, 2007).

Hay ocasiones en las que un usuario puede indicar que la respuesta a una solicitud le llegue en otra modalidad. Por ejemplo, un usuario que se inscribe a un servicio cualquiera y desea que la confirmación se le notifique vía SMS o MMS, o una solicitud en SMS y la respuesta en MMS o Push WAP (se usa este término para referirse al caso en que se le envía al usuario un mensaje para que entre al portal WAP).

En el SMP el componente encargado de la permutación multimodal es el AnalizadorSolicitud, pero en la solicitud debe ir incluida la petición de la permutación, indicando la modalidad de la respuesta en un campo de un formulario HTML, o en un campo de una tarjeta WML o S@TML, o como parte de un mensaje SMS/ MMS. Sin embargo, en el caso de una solicitud mediante SMS el componente automáticamente realiza la permutación a MMS o WAP (mediante Push WAP) si la respuesta contiene muchos caracteres.

Implementación de un prototipo del SPM

Fue implementado un prototipo del SPM, el cual consiste en una aplicación web implementada con la tecnología de Servlets, sobre el contenedor Web Tomcat Apache. El corazón de la aplicación es el Servlet llamado Controlador, que es el encargado de atender las solicitudes de los navegadores web, de los proxys WAP, de las pasarelas S@T y del integrador de servicios. Este componente es el encargado de pasarle los mensajes a los demás objetos, y en sí mismo mantiene la caché mediante un objeto de la clase ProxyWebCach.

La caché se mantiene en memoria por el ciclo de vida del Servlet en el contenedor; cuando este inicia mantiene el valor y las instancias de todos los atributos del Servlet en tanto que no se elimine de la memoria el proceso contenedor.

El Controlador invoca los métodos de un objeto de clase AnalizadorSolicitudes para determinar la modalidad de la respuesta, y el formato objetivo al que tiene que ser transformada. Cuando la solicitud se realiza mediante SMS, el código en el mensaje de solicitud es traducido en un URI por este objeto, que lee un archivo en formato XML. En dicho archivo cada código es asociado con un URI, y también se encuentran los parámetros que se requieren para hacer la consulta al servidor de origen.

Una vez el Controlador conoce el formato de respuesta, invoca un método en los objetos de la clase traductora.

El prototipo se implementó para las modalidades HTTP, WAP, SMS y S@T y funcionó correctamente para el acceso a los siguientes recursos: una página XHTML cuyo contenido es únicamente texto, una página XHTML con una tabla, una página XHTML con texto y tres imágenes anexas, una página XHTML con un formulario para ingresar dos números, una aplicación web, codificada en PHP, encargada de recibir dos números (del formulario en la página XHTML anteriormente mencionada) y presentar la suma de estos; una página XHTML con un formulario para ingresar el ISBN de un libro y una aplicación web, codificada en PHP, que tras recibir el ISBN (del formulario previamente mencionado) genera un reporte sobre este, mediante la consulta a una base de datos.

Conclusiones y trabajos futuros

Las aplicaciones multimodales van a ser ampliamente empleadas en el futuro, ya que los dispositivos livianos y móviles son cada vez más potentes y mucho más baratos que un PC de escritorio o portátil.

En este artículo se presenta la arquitectura de una herramienta para habilitar el acceso multimodal a recursos en la WWW. Una de sus ventajas es que admite modalidades que no se tuvieron en cuenta en otros proyectos. El énfasis de la mayoría de los proyectos es XHTML y VoiceXML, pero no toman en cuenta nuevas tecnologías como S@T.

La otra fortaleza de la herramienta es su fácil uso por parte de desarrolladores y usuarios. Para los desarrolladores es práctico de usar esta herramienta porque lo único que tienen que hacer es codificar las aplicaciones (recursos dinámicos) y páginas (recursos estáticos) en XHTML, que es un lenguaje ampliamente conocido por ser descendiente de HTML, y que además es el recomendado por el W3C para el desarrollo de aplicaciones para múltiples dispositivos. Luego de la codificación, el desarrollador finaliza su trabajo registrando los recursos o la aplicación en el SPM.

El desarrollador no tiene que preocuparse por la lógica de la interacción multimodal, sino que simplemente enchufa su aplicación al SPM. Esto constituye una mejora sobre los borradores del W3C, pues estos proponen una arquitectura dependiente de la lógica de negocio.

Sin embargo, el desarrollador tiene restricciones para codificar los recursos, ya que hay etiquetas que no pueden utilizar, o bien, que no tienen traducción equivalente a los formatos de otras modalidades de uso distintas a HTTP.

Para los usuarios clientes también es fácil de usar. En el caso de utilizar la modalidad SMS, el formato de ingreso de datos es bastante simplificado, y en caso de utilizar MMS, el empleo de imágenes le proporciona una interfaz más cómoda que el teclado de un teléfono celular.

Una posible extensión a este trabajo sería la inclusión de Voice XML o un analizador de audio para clips incrustados en mensajes MMS.

Otro aspecto a mejorar es la seguridad. Se podría usar XML Encryption WG (W3C, 2007) para asegurar los recursos almacenados en los servidores de origen, y estos se descifrarían en el SPM para que él sirva el contenido a los clientes.

Bibliografía

Abrams, M., Phanouriou, C., Batongbacal, A. L., Williams, S., M., and Shuster, J. E. UIML: An Appliance-Independent XML User Interface Language., Proceedings of the 8th International WWW Conference, Elsevier Science Publishers, Toronto, Canada, 11-16 May, 1999.        [ Links ]

Azevedo, P., Merrick, R., Roberts, D. OVID to AUIML User Oriented Interface Modeling., IBM, 2000.        [ Links ]

Caicedo, I., Herramienta para habilitar el acceso multimodal a recursos de la WWW desde diversos dispositivos., tesis presentada en la Universidad de Los Andes para optar al título de Maestría, 2007.        [ Links ]

Fan, X, Xie, X., Li ,Z., Mingjing, M., Ma, W. Y., Photo - to - Search: Using Multimodal Queries to Search the web from Mobile Devices., China: University of Science and Technology of China; Microsoft research Asia, 2005.        [ Links ]

Maddingue., http://maddingue.free.fr/techie/html2wml/test.html, consultado diciembre 15, 2007.        [ Links ]

Pathan, A. M. K., Mottalib, M. A.; Zibran, M.F., An Internet framework to bring coherence between WAP and HTTP ensuring better mobile Internet security., Advanced Communication Technology, ICACT 2006, The 8th International Conference, Volume 1, No. 20-22, February, 2006.        [ Links ]

Simon, R., Wegscheider, F., Tolar, K., Tool-Supported Single Authoring for Device Independence and Multimodality., ACM International Conference Proceeding Series, Vol. 111, archive, Proceedings of the 7th international conference on Human computer interaction with mobile devices & services, Salzburg, Austria, 2005.        [ Links ]

Souchon, N., Vanderdonckt, J., A Review of XML-compliant User Interface Description Languages., J.A. Jorge, N. Jardim Nunes, J. Falc˜ao e Cunha (Eds.): DSV-IS 2003, LNCS 2844, © Springer-Verlag Berlin Heidelberg 2003, 2003, pp. 377–391.        [ Links ]

SourceForge.net.,Disponible en: http://sourceforge.net/projects/jvoicexml, diciembre 15, 2007.        [ Links ]

Tourbase., disponible en: http://www.tourbase.ru/zink/, consultado diciembre 15 de 2007.        [ Links ]

Voice XML Forum., Disponible en: http://www.voicexml.org, consultado diciembre 15 de 2007.        [ Links ]

Voxeo., disponible en: http://www.voxeo.com, consultado el diciembre 15 de 2007.        [ Links ]

W3C, XHTML+Voice Profile 1.0., W3C Note, 21 December 2001, Disponible en: http://www.w3.org/TR/2001/NOTE-xhtml+voice-20011221/, consultado diciembre 15 de 2007.        [ Links ]

W3C, Multimodal Architecture and Interfaces., W3C Working Draft 11 December 2006, disponible en: http://www.w3.org/TR/mmi-arch/, consultado diciembre15 de 2007.        [ Links ]

W3C., XML Encryption WG, 2007.        [ Links ]

Wegscheider, F., Dangl, T., Jank, M., Simon, R., A Multimodal Interaction Manager for Device Independent Mobile Applications., WWW 2004, May 17–22, 2004, New York, New York, USA.        [ Links ]

Wilson, M., Disponible en: http://www.topxml.com/wap/articles/htmlwml/default.asp, consultado diciembre 15 de 2007.        [ Links ]

Wurfl, disponible en: http://wurfl.sourceforge.net, consultado diciembre 15 de 2007.        [ Links ]