CC/PP: Composite Capabilities and Preference Profiles David Álvarez Quintana

Introducción Situación actual en el acceso a contenidos web:  Múltiples dispositivos de diferentes capacidades  Diferentes usuarios (lenguaje, gustos, edad…) Necesidad de un estándar que cubra esta situación.

Independencia de Dispositivo Información en cualquier momento, en cualquier lugar Dos puntos de vista a tener en cuenta:  El usuario consumidor de contenidos  El programador de contenidos independientes del dispositivo.

Independencia de Dispositivo: El usuario Implica acceso universal

Independencia de Dispositivo: El programador Implica un único desarrollo para todos los terminales

Preferencias de Usuario Descripción formal de las “condiciones” de usuario en la presentación de contenidos. Mecanismo de asignación de valores a sus preferencias. Repositorio de preferencias

El estándar CC/PP Infraestructura para la representación estándar de las capacidades de dispositivo y las preferencias de usuario. Basado en perfiles Utiliza RDF (Resource Description Languaje) como lenguaje formal de construcción de perfiles

Estructura CC/PP Estructura de documento jerárquico. Cada perfil será un conjunto de componentes  Características principales a modelar: Plataforma Hardware Plataforma Software Aplicación Cada componente se compondrá de uno o varios atributos  Valores concretos de los componentes Tamaño de pantalla Versión de JRE soportada Versión de navegador

Ejemplo de perfil de dispositivo <rdf:RDF xmlns:rdf=" xmlns:ccpp=" xmlns:ex=" EPOC 2.0 Symbian

Ejemplo de perfil de dispositivo (2) Mozilla 5.0 Symbian

CC/PPex: CC/PP Exchange Protocol Estándar CC/PP solo describe composición de perfiles. Requerimientos para el protocolo:  Compatible HTTP/1.1  Soporte de referencias externas a perfiles  Soporte de cacheo de información válida para todas las peticione dentro de una misma sesión. CC/PPex se basa en HTTP Extension Framework

Profile Header Lista de referencias a descripciones CC/PP Soporta direccionamiento indirecto mediante URI Gramática: Profile = profile-field-name ":" 1#reference profile-field-name = "Profile" reference = ( absoluteURI | profile-diff-name ) profile-diff-name = profile-diff-number "-" profile-diff-digest profile-diff-number = 1#DIGIT profile-diff-digest = sp;

Profile-Diff Header Contiene propiamente el perfil. Gramática: Profile-Diff = profile-diff-field-name ":" profile-desc profile-diff-field-name = "Profile-Diff-" profile-diff-number profile-desc = Ejemplo de Cabecera: Profile: "1-P1GRkSjKK50aTWXXndFcSQ==" Profile-Diff-1: <RDF xmlns=" xmlns:PRF=" <Description PRF:Vendor="Nokia" PRF:Model="2160" PRF:Type="PDA"

Profile-warning header Cabecera para la respuesta (response) del servidor. Gramática: Profile-warning = profile-warning-field-name ":" 1#warning- value profile-warning-field-name = "Profile-Warning" warning-value = warn-code SP warn-target SP warn-text [SP warn-date] warn-code = 3DIGIT warn-target = (absoluteURI | host [ ":" port ]) warn-text = quoted-string warn-date = HTTP-date

Warn-codes 1xx - Estado del perfil  100 OK  101 Used stale profile  102 Not Used profile 2xx – Tipo de adaptación aplicada  200 Not applied  201 Content generation applied  202 Transformation applied Ejemplo: Profile-Warning: "Used stale profile", "Not used profile", :80 "Not applied" "Wed, 31 Mar :49:37 GMT"

Conclusiones Buena infraestructura para la descripción de los dispositivos. No suficiente para alcanzar la independencia de dispositivo.  Apoyo de otras tecnologías para proceso de transformación SVG XSL Requiere madurez en definición de preferencias de usuario. Abierto a nuevas propuestas de protocolo para el intercambio de perfiles.