Position Paper: Style Sheets for Context Adaptation

François Bry and Michael Kraus

11 February 2002

Institute for Computer Science, University of Munich
http://www.pms.informatik.uni-muenchen.de
Introduction

Context adaptation of web contents is nowadays necessary because of the various devices used (especially mobile phones and PDA) and the advanced applications (such as contextual web services) the market is seeking for. Adaptation of web contents to various devices (such as standard size screens vs. PDA) and adaptation to various contexts (such as user profile, time, or location) do not differ in the techniques they require. In the following, proposals are made for enhancing existing standards with adaptation capabilities that consist in minimal conservative changes of the existing standards.

Objectives

1. Keeping Standard Diversity Small

The proposals in this paper rely as much as possible on existing and already established standards and technologies, instead of trying to introduce brand new standards and technologies. This means that, apart from small extensions, no new algorithms have to be conceived and implemented. It is better to extend existing standards in order to provide new functionailities than inventing a new standard for each functionality.

2. Conservative Extension of Existing Standards

When changing standards, both upwards and downwardly compatibility are important issues. Upwards compatibility means that existing data and related standards can still be used with the new, extended standard. This is achieved by extending, not altering the existing standard. Downwardly compatibility means that data and related standards based on the new, extended standard can also be used with old processors made for the original standard. This is achieved by extending in such a way that does not harm the old standard.

3. Open to Future Style Sheet Languages

The approach described in this paper is not specific to CSS or XSLT. It relies only on path selectors, which play a central role in web standards. The same approach can easily be applied to other or future style sheet languages or to other web standards like XML query languages, as long as they build on path selectors. Note also that this approach is stable against the changes from XPath 1.0 to XPath 2.0 (which have introduced a considerably more complex type system, a set of relational operators, and certain kinds of variables into the language).

4. Rule-Based Approach

The approach in this paper uses style sheet rules for expressing context adaptation. Style sheet rules allow to formulate context-sensitive presentation in a declarative way, as opposed to Javascript, for example. Using Javascript, it is also possible to implement certain kinds of adaptation functionalities, but this is done using an imperative programming language. This means that the actual presentation parameters are hidden behind assignments, loops, etc. In contrast, rules describe only a logic, no processing. The processing, or algorithm, can be kept the same when rules are refined.

5. Security Concerns

Because the style sheet based approach proposed in this paper relies on client-side computations only and does not require any processing on the server side, it does not face security problems as conventional approaches do, for example the combination of cookies, PHP and URIs. Many existing systems use this combination to extend HTML or XML with simple adaptive hypermedia functionalities. With the approach advocated for in this paper, the whole processing takes place within the browser. Therefore no private or sensible data has to be transferred to and from the server, what would compromize security.

These five objectives are fulfilled by those part of proposals below for which implementations are specified. The other parts of these proposals can clearly be realized so as not to jeopardize these objectives.

Proposal 1: Browsing Contexts and Style Sheets for Context Adaptation

1. Browsing Contexts: A Data Structure for Expressing Context Information

Adaptive hypermedia systems rely upon context information that can be classified in browsing environment (consisting of user profile/preferences and device profile/characteristics), browsing history (describing the browsing session so far), and application data (such as performances on excercises, answers to questionnaires, etc.). This information together forms what is often referred to in the adaptive hypermedia literature as user model [BRU96 ].

A browsing context is a data structure for describing a browsing environment, a browsing history, and application data in XML-style, that is, relying upon an XML application. The data structure browsing context is described in more details in [BK02 ].

A browsing context can be seen as meta information added to a document, called below the "nude document" for the purpose of context adaptation. A "nude document" enriched with a browsing context is referred to below as a "context enriched document". Like meta data such as the HTML head element is added to a raw document for enhancing its retrieval or processing, or style sheet data enhance a document with layout specifications, a browsing context enriches a HTML or XML document with context adaptation meta data. This meta data can be used by a (browsing context conscious) browser to adapt the rendering of a "nude document".

The context enriched document takes over the role of the original "nude document" within the browser, that is, style sheets are applied to the context enriched document instead of the "nude document", scripting languages have access to the DOM tree of the context enriched document instead of the DOM tree of the "nude document", etc. In fact, the context enriched document is a virtual document combining a browsing context (using which adaptation is expressed) with a standard HTML or XML document. Note that the approach described below does not require the materialization of this virtual document.

2. Modeling Virtual Locations

There are several different notions of location. Apart from two "classical" notions, that is first, the country or region where the user is (modeled in desktop systems), and second, the geographical position of the user (modeled in mobile devices), there is a notion of virtual locations. Virtual locations are for example home, car, "in office", "in a meeting" (that might last for several days and take place in different rooms), etc. Virtual locations often specify activities.

Virtual locations are not represented in today's computer devices and with current web standards.

A simple - although powerful - handling of virtual location in context adaptation would be to name them on the client-side and to refer them in browsing contexts.

3. Style Sheets for Content and Navigation Adaptation

The web style sheet languages CSS, XSL and DSSSL all use path expressions as selectors for style rules. The selectors are matched against the document tree.

Matching the path expression of a style sheet selector is not only against the document tree, but also against the browsing context document, allows to express both content and navigation adaptation. For example, the following XSLT template matches only if the user has visited the page http://www.michaelkraus.de before:

<xsl:template match="paragraph[//bc:history[uri="http://www.michaelkraus.de"]]">
  ...
</xsl:template>

In CSS, a browsing-context-enhanced style rule may look like this:

bc|history[uri="http://www.michaelkraus.de"] paragraph { ... }
4. Scripting Languages for Advanced Context Adaptation - Program Attachments to Web Pages

Web contents have to be clearly distinguished from programs. The current mix of web contents and programs - for example programs parts included in dynamic HTML pages, or, symmetrically, web contents in scipting language programs - makes the development, analysis, and maintenance of advanced applications unnecessarily difficult.

It is proposed that web pages are only allowed to contain - via reserved XML names to be defined - variable references, or procedure calls, or function calls, apart from static content. The computation of variable bindings and procedure definitions should be kept in a program attachment to the web page using a syntax to be defined.

A clear separation of the web page proper, that specifies a pattern for the web content, and a program attachment to the web page proper, where program code for the web page is specified, is essential for the modularization of large web pages with rich dynamics.

Proposal 2: Hyperlinks and Style Sheets Revisited

Hyperspace as Third Layout Dimension

Context Adaptation can be seen as "hyperspace layout" where hyperspace is understood as including the time dimension and user and device profiles. Style sheets are appropriate for layout in the hyperspace as much as for layout in the two-dimensional printing space. A unified approach for layout in both spaces, hyperspace and printing space, is preferable to different approaches for two reasons: Ease of programming (for people), ease of processing (for computers).

The following proposals are based upon the view of the hyperspace as third layout dimension.

1. Link Model vs. Browsing Model: Semantics vs. Navigation

It is proposed to distinguish between link model and browsing model as follows:

  • A link model defines link types, possibly hyperlink types, based on semantic relationships between data.
  • A browsing model specifies a hypertext behavior for links.

This distinction is analogous to the distinction between a generic markup language such as XML, whose purpose is to model the logical structure of data items, and a style sheet language such as CSS, whose purpose is to specify the layout for a given logical structure. It has been discussed for example in [BHK92 ], [BHK94 ], and [HS94 ].

Link models and browsing models are usually not distinguished. For example, the HyTime model [HY97 ], which inspired XLink, defines hyperlinks primarily in terms of the behavior of standard browsers (such as Netscape Navigator or Internet Explorer) to be used with standard size screens. If web contents are to be rendered not only with standard browsers and standard size screens, then the distinction between link model and browsing model is essential, for it makes a context-dependent (for example device-dependent) hypertext rendering of the same link model possible. The distinction between hyperlink model and browser model proposed here contributes to both, independence of data modeling from data usage and independence of data modeling from presentation devices.

Consider as an illustration the "behavior attribute" show of XLink. For simplicity assume a binary, directed hyperlink between a source data item and a target data item. The attribute show may have the value show="undefined" or one of the following three values: show="replace" means that the presentation of the source data item disappears from the window from which the hyperlink was actuated and instead a presentation of the target data item appears in this window; show="new" means that the presentation of the source data item remains unchanged and a presentation of the target data item appears in a new window; show="embed" means that a presentation of the target data item is integrated into the presentation of the source data item at the position where the hyperlink was actuated (in the case of data items consisting of text, this behavior is also known as stretch text). A link model might define the following, semantically characterized, hypertext-free link types: "hyperlink to new information", "hyperlink to alternative descriptions of the current information", "hyperlink to supplementary information". A browsing model could then specify that these three types of hyperlinks behave in the three ways described above. Different browsing models may specify the behavior differently, depending on the device or more generally on the context.

2. Hyperlink Disabling

Disabling a hyperlink is to be understood here as rendering the link anchor (text or image) while removing all hyperlink functionalities. Hyperlink disabling makes it possible to prevent a user from traversing a link which is not relevant to his current context. For example, hyperlinks to advanced information can be disabled for novice users, hyperlinks to large graphics can be disabled for PDA users, and a hyperlink to a patient's health insurance details can be disabled when, while making a diagnosis, a physician is consulting the patient's medical record. Note that currently none of HTML, XLink, CSS, and XSL/XSLT support hyperlink disabling.

Hyperlink disabling is one possible hyperlink presentation that can be expressed using an XLink attribute. New attribute/value pairs can be introduced into CSS to express such a hyperlink presentation.

The following presentations facets are desirable for versatile adaptive hypermedia systems:

  • Normal: traversable, anchor rendered as hyperlink
  • Untraversable: not traversable, anchor rendered as hyperlink
  • Hidden: not traversable, anchor rendered as normal text or image
  • Invisible: not traversable, anchor not rendered

Note that only the first of these facets is currently specified by the XLink or HTML standard. Note also that enhancing XLink or HTML with these facets would require neither significant changes of the standard, nor to enhance browsers with any complex processing.

3. Hyperlink Enabling - Hiding Elements in the Hyperspace

In rendering a document it might be beneficial to exchange its "structure dimension" for the "hyperspace dimension", that is, to make a subelement (for example a section) reachable through a hyperlink. This appear useful for example if the document is to be rendered on a small screen such as a PDA or a mobile phone.

The anchor of the element to be "hidden in the hyperspace" could be specified in the browsing style sheet. The browsing style sheet language could also make it possible to use the first two or three (or generally, n) words of the element, possibly followed with a sign such as an arrow, as an anchor for the element hidden in the hyperspace.

Style sheet languages such as CSS and XSL can easily be conservatively enhanced so as to enable a hyperlink on a certain element.

4. Linkbase Processing

Context adaptation is likely to be especially useful in rendering documents or collections of documents having a complex structure of links, involving not only simple links à la HTML but possibly also complex links (that is, links associating more than two ressources, inbound and third-party links). Complex link structures are better specified using linkbases (cf. XLink). Therefore, the processing of linkbases is likely to become soon an essential practical aspect of the development of context adaptive web contents.

There are several manners for a browser to process linkbases, a topic which is not covered by the current XLink standard. It is worth to distinguish between the set of hyperlinks that are defined in each document (or in the linkbases it refers to) and the hyperlinks that the browser has knowledge about, what we refer to as a browser's internal linkbase. A browser's internal linkbase contains not only those links defined in the document (or in the linkbases this document refers to) it currently renders. A browser's internal linkbase also contains those links collected from previoulsy loaded linkbases, for example from those linkbases refered to by formerly rendered documents. The issue is to specify what the browser's internal linkbase should be at each point of time.

A closed world linkbase processing scenario assumes that it is possible to have knowledge about all the hyperlinks relevant to the application, even if not all of them are referenced by the document currently being displayed. If this scenario is applicable, then the browser's internal linkbase might consist at any time of all the hyperlinks relevant to the application. While this scenario is surely not applicable to the open world wide web, it makes sense for many applications such as electronic books, technical documentation, and some information systems.

In contrast, an open world linkbase processing scenario assumes that it is not possible to have knowledge of all the hyperlinks relevant to the application. This assumption applies for example to the World Wide Web. It applies also to those information systems with contents referring to resources outside the information system such as for example university web pages.

Under the open world linkbase processing assumption, two different approaches can be retained: inflationary linkbase management, in which case the browser's internal link base continously grows during a session, and conservative linkbase management. The first approach has the drawback of possibly yielding different renderings of the same web page at different times of a same session (if a page visited after this page has added new hyperlinks or hyperlink arcs to or from this page). A possible drawbachk of the second approach is to preclude forward hyperlink references, thus confining applications to hierachically definable hyperlink structures.

Obviously, the scenarii defined above, closed world linkbase processing, open world linkbase processing with inflationary linkbase management, and open world linkbase processing with conservative linkbase management, specify the border cases of a large space of mixed possibilities: it surely might make sense for some application to treat some links according to the closed world assumption, other links according to the open world assumption under inflationary management, and links of a third kind according to the open world assumption under conservative management. Also, the linkbase processing retained might be context-dependent. Clearly, it could make sense for some application to choose a link restrictive linkbase processing if the rendering is to be done on the small screen of a PDA.

The development of context-dependent application makes it necessary to develop means for a context-dependent specification of various forms of linkbase processing.

The proposals above require a substantial (conservative) extension of XLink and minimal extensions of style sheet languages (so as to accomodate among other hyperlink disabling and enabling).

Acknowledgement

The authors are thankful to Norbert Eisinger for useful suggestions.

References

[BRU96]
P. Brusilovsky: Methods and techniques of adaptive hypermedia. User Modeling and User-Adapted Interaction 6 (2-3), 87-129. http://www.contrib.andrew.cmu.edu/~plb/UMUAI.ps
[BK02]
F. Bry, M. Kraus: Adaptive Hypermedia made simple using HTML/XML Style Sheet Selectors. http://www.pms.informatik.uni-muenchen.de/publikationen/index.html#PMS-FB-2002-1
[HY97]
International Standard ISO/IEC 10744: Information technology - Hypermedia/Time-based Structuring Language (HyTime). Second edition 1997-08-01. http://www.ornl.gov/sgml/wg8/docs/n1920/html/n1920.html
[BHK92]
P. De Bra, G.J. Houben, Y. Kornatzky: An Extensible Data Model for Hyperdocuments. 4th ACM Conference on Hypertext, Milano, pp 222-231, 1992. http://wwwis.win.tue.nl/~debra/echt92/final.ps
[BHK94]
P. De Bra, G.J. Houben, Y. Kornatzky: A Formal Approach to Analyzing the Browsing Semantics of Hypertext. Proc. CSN-94, Utrecht, 1994. http://wwwis.win.tue.nl/~debra/csn94/csn94.ps
[HS94]
F. Halasz, M. Schwartz: The Dexter Hypertext Reference Model. Communications of the ACM, 37(2):30-39, 1994.