DISAS: a DISelect-based Middleware for Building Adaptive Systems

1. DISAS: a DISelect-based Middleware for BuildingAdaptive Systems Lorenzo Gallucci1, Mario Cannataro1,3, Luigi Palopoli1,2, Pierangelo Veltri3 1EXEURA S.r.L., Italy, 2DEIS–University of Calabria, Italy, 3University of Catanzaro, Italy.

2. Background - Adaptive Web Systems • An Adaptive Web system models characteristics of the user and adapts delivered content accordingly • Application Domain Model (DM) describes basic information fragments and their relationships • User Model (UM) describes user’s characteristics and expectations • Adaptation Model (AM) describe the adaptation strategies, e.g. • content selection, i.e. a selection of content to be presented to the user, • content adaptation, i.e. a manipulation of information fragments, • and link adaptation, i.e. a manipulation of the links presented to the user. user’s terminal, network bandwidth browsing activity, vs static profile time, location, language Information Fragments&Metadata User’s Technology Data User’s Environment Data User’s Behavior Data Application DomainModel UserModel Adaptation Model Output

3. User Profile Detection and Content Delivery Strategies for web applications • Adaptation of content requires a dedicated agent to combine adaptable hypermedia (i.e. hypermedia plus rules) with user and terminal information (“profile”). • When deciding which party (client or server) stores profile data and performs content transformation two strategies can be adopted: • web client is required to perform adaptation autonomously • web client works together with the server to perform adaptation • Given a language describing AM, both strategies can be adopted, with different pro and con …

4. User Profile Detection and Content Delivery Strategies for web applications  1st strategy: “user agent” is sole responsible for performing adaptation • User profile is detected and monitored on the client side only (not shared with the web server) • User agent receives ADM as well as AM from the server and must be able to use both to perform adaptation. The software to do so may be: • mixed intothe HTML page by the web application • pro: a client-side scripting language is needed, so “write once, execute many” is exploitable • con: page processing may be slow, depending heavily on scripting runtime speed and availability of client libraries for efficient XML transformations on a variety of clients • embedded in the user agent itself • pro: shorter response times could be achieved (due to native code usage) • con: code might have to be re-implemented for different browsers

5. User Profile Detection and Content Delivery Strategies for web applications  2nd strategy: client works together with server in order to produce adapted page • client side is responsible for detecting user profile parameters data is updated at discrete times (when profile information is deemed to be refreshed) • a snapshot of most recently measured parameters is stored on server • hypermedia is adapted on server side, just before being sent to the client content transformations can be carried out only once (in response to page load request)

6. Background - DISelect: Content Selection for Device Independence • How to describe content transformations? • Content Selection for Device Independence (DISelect) W3C Working Draft defines: • a language for general purpose content transformation on an XML document, which contains: • content pieces • transformation constructs (i.e. XML tags and/or special attributes) using expressions • content filteringusing boolean expressions • content manipulationemploying general expressions

7. Background - DISelect: Content Selection for Device Independence • a reference environment • minimal set of functions describing User Model characteristics device parameters, network conditions, etc. • each function is usable as a term in expressions e.g. “di-cssmq-width(‘px’) > 800” • an event model • reprocessing event can be triggered on e.g. user profile change or forced redisplay • error/exception handling events • Example:<sel:if expr=”di-cssmq-width(‘px’) &gt; 800”><p>Shown only when screen width is greater than 800 pixels.</p></sel:if>

8. DISAS: DISelect Adaptive System • Introducing DISAS, an adaptative system built on: • a library, based on DISelect standard, that performs content adaptations (such as selection and manipulation) to XML and non-XML documents • a paired profile detection & management subsystem • Main goal:  support evolution of existing web application towards adaptivity • require only a small set of modules to be added • allow incremental insertion of adaptation constructs (“rules”) into previously non-adaptive pages. • use standards wherever possible

9. DISAS: DISelect Adaptive System • DISAS’s objectives: • to allow a developer to write content adaptation rules in dynamic web pages no problems with source of profile information used in rules • to develop an automatic and unobtrusive user profile detection software ease of integration in an established web system • to develop a component which has to process adaptable hypermedia “behind the scenes” instantiate rules on actual profile data, in order to produce adapted hypermedia

10. DISAS prototype • DISAS’s facts • working prototype of an adaptive web system library • built upon a set of standard Sun™ J2EE components • based on the XAHM model • follows the W3C Device Independence Working Group recommendations. • Placed between Web-based Information System and a standard web browser, is able to: • detect characteristics of the user’s terminal and user’s context network available bandwidth is also measured • deliver content expressed as well-formed XML documents containing DISelect code to the user device a filtering engine processes DISelect in order to perform adaptation to user devices capabilities and user profile. • exploit a considerable subset of DISelect rule language for non-XML coded hypermedia (such as HTML 4.0 code, JS or CSS) a “JSP tag library” allows DISelect constructs to be merged into active pages (also JSP code flow can be adapted)

11. DISAS prototype • DISAS supports: • two kinds of content selection: • simple (on/off) selection; • selection of zero or more members among a set of content fragments. • content manipulation/content generation (computed data is expressed via a DISelect expression). • Very basic, indeed, but more flexibility comes from two features: • arbitrary “variables” can be defined can store partial results can change over time (like mainstream imperative languages and unlike other XML manipulation languages, such as XSLT) • constructs can be arbitrarily nested and mixed

12. Conclusions & future works • DISAS offers a basic set of services to build adaptive systems: • automatic profile detection • seamless connection to content selection and manipulation • Nonetheless, their availability enables building more advanced services. • Task-specific “taglibs” may help in capturing higher level adaptation constructs (“idioms”) into JSP tag definitions, translating them into lower level DISelect constructs A taglib to support “Tigra Tables Pro” JavaScript library has been developed for the first application of DISAS

13. Conclusions & future works • In DISAS, both content transformation and profile detection are triggered by specific events.No persistent client agent currently exists, so: • DISelect transformation cannot be re-triggered • measurements on user parameters start only on server request. • Availability of such an agent would enable: • automatic re-adaptation in response to a change in some of the user parameters; • continuous update (“tracking”) of quickly varying parameters, such as network speed or lag.

14. Thank you!