+ Except Casio PA-2400 Cassiopeia 420x240

Communication. Beside the characteristics of the mobile device itself, restrictions in the communication infrastructure are quite important. Table 2 gives a general overview of different options for wireless communication and their characteristics. Information to be delivered to mobile devices may have to be adapted to bandwidth availability and transmission cost.

Table 2. Communication Properties

The above consideration of constraints that apply to information delivery to mobile devices shows the need for adaptation to more than one parameter. For example, web content may have to be adapted regarding the choice of media, the layout of pages, and the overall volume of data, depending on computing power, display properties and available bandwidth.

The remainder of this paper is structured as follows. In the next section, we will discuss two common approaches for adaptation of information, more specifically web content, to mobile platforms. In section 3, we will propose a new approach based on an object-oriented framework for content adaptation. Section 3 also introduces an XML-based markup language based on WebComposition, an object-oriented model for web applications. Finally, section 3 illustrates an example-application applying the framework

In the remainder of the paper, we discuss information access from mobile devices in the context of the World-Wide Web as primary information medium. The World-Wide Web as such has a very simple model for content delivery to clients and does not provide for adaptation to different clients or to clients on mobile platforms in particular. HTML as dominant document type does only support the adaptation of image resolution to low-resolution browsers. For further adaptation of web content, in particular with respect to clients on mobile platforms, two different approaches are common:

• Automated conversion

• Explicit specification of adapted content

Automated Conversion. This approach is based on the use of filters for conversion of web content to a presentation suited for mobile devices. PocketWeb, the first PDA browser for the WWW presented in 1994 at WWW-2 was based on this approach, for example to convert images to bitmap in adaptation to the capabilities of the first Newton MessagePad [4]. In PocketWeb, adaptation is primarily based on display properties. In contrast, MobileWWW and MobileODBC [1] adapt the transmitted content volume automatically to the available bandwidth, based on measuring the QoS of the available network and comparing it to the user preferences regarding download-time and maximal costs. According to these preferences the content was compressed with loss for audio, video and pictures and then transferred.

Automated conversion and adaptation of content is quite advantageous for creators of applications or content, because in an optimal case no additional effort has to be taken to adapt content for mobile devices. The disadvantage of the approach is that the semantics of the content is not taken into account. While automated conversion may yield acceptable results in many cases, it is not reliable and can lead to delivery of content that is not useful anymore. For example, compression can lead to unreadable output of graphics that are indispensable for the understanding of displayed content. In addition, after automated conversion, content media may be scaled appropriately but still the content layout may prove awkward, for example forcing the user to scroll on the small display.

Specification of Adapted Content. As automated conversion is often unacceptable, it is quite common to explicitly specify adapted content for mobile devices. For example, in ESPRIT project MILLION, mobile information access to a web-based application was realised by specifying HTML documents following style guidelines for HTML delivery to a PDA [7]. Instead of style guidelines, specific description languages have been proposed for content delivery to small mobile devices. These efforts are driven by large consortia, for example the WAP forum proposing the Wireless Markup Language (WML) [9], and the W3C consortium suggesting Compact HTML (CHTML) [10]. With a language like WML or CHTML, content can be designed in a way optimised for mobile devices. This is a good solution for content and applications created exclusively for one class of mobile devices. The solution degrades though, if the goal is to gain access from heterogeneous platforms, for example from desktop browsers and different kinds of mobile browsers, because then all content has to be build several times (for each type of browser, and in addition maybe even for different communication bandwidth).

Both proposed methods, automated conversion and special language, have their trade-offs regarding content development for heterogeneous mobile platforms. In the following section, we propose to use object-oriented techniques for specification of adapted content, aimed at reduced effort for building and maintaining content for heterogeneous platforms.

While it is straightforward to devise an object-oriented model or framework for the given problem, it is unfortunately not easily applied to web-based information delivery. The Web implementation model is based on the notion of resources, which have a unique address, and which are delivered on request to clients, where they can be rendered in a browser. Resources can be static and file-based, or dynamically generated from a script. They are meant to capture specific rather self-contained chunks of information. While the simplicity of this web implementation model largely contributed to the phenomenal success of the Web as information medium, it is very limiting from a software engineering perspective. It does especially not provide support for basic engineering concerns such as composition, reuse, and modifiability. Resources are both too coarse-grained and too specific to facilitate the construction of frameworks like the one suggested above. The coarse granularity of resources makes it impossible to implement a separation of concerns, for instance to separate content from layout. The inherent specificity of resources implies that there is no support for generalisation and hence no support for reuse-by-inheritance.

Fig. 1. Object-oriented framework for content adaptation to different platforms

In order to facilitate the use of the above-described framework, we build our approach on WebComposition, an object-oriented model for web applications. In the following subsection, the model is described briefly, for more detail cf. [3]. Following this, an XML-based implementation is introduced.

WebComposition defines an object-oriented component model, which abstracts from the web implementation model. The Component Model is based on components as a uniform concept for modelling web entities at arbitrary granularity and level of abstraction. In contrast to resources, components are not fixed to a certain grain size but designed to capture design artefacts at their natural granularity. For example, in contrast to resources, components can capture a content unit as design artefact independent of a web page, which is a separate design artefact. Support of arbitrary grain-size means that components may model web entities as small as individual links or layout resource fragments. Of course, a component may also be associated with a complete resource, for instance an HTML document or a script generating a web document.

Components can reference other components to model aggregation (has-part) or specialisation (inherits-from). For example, a component modelling a page can reference components modelling parts of the page; and a component modelling a navigation structure can reference the components that model the involved links and anchors. By means of a special reference type, components can reference so-called prototypes components from which they inherit state and behaviour. Any component can function as prototype, following the prototype-instance model as opposed to a class-based object-oriented model. In the prototype-instance model, there is no distinction between instances and classes, and hence no distinction between the relationships is-instance-of and is-subtype-of [8]. We find the prototype-instance model naturally suited for web application modelling, because many web entities, namely those modelling content, are rather unique, and because prototyping reflects the copy-and-modify type of reuse typically applied in web development. Components may be abstract, i.e. function only as prototype for specific components. Abstract components are one mechanism to realise code sharing among objects. Another mechanism for code sharing is to allow multiple references on the same component, e.g. for a component modelling an HTML fragment that is replicated in multiple HTML pages. Sharing is fundamental for reuse but also for maintainability as it helps keeping modifications local.

Components have state and behaviour. The state is defined by a list of typed properties (name-value-pairs). For example, a component modelling an HTML element has properties relating to that element's attributes. The behaviour can be influenced by a set of services. All components have to provide at least a persistency service and an implementation service. The persistency service allows the component state to read from and to write to persistent storage. The implementation service is responsible for mapping the component state to a representation in the Web, for instance a mapping to HTML code or to script code.

The WebComposition component model is an abstraction from the web implementation model, facilitating the object-oriented description of web applications or frameworks in terms of components. The implementation of the model is based on two concepts: a component store for persistent storage of the model to enable lifecycle-spanning maintenance of components, and automated resource generation from the component model. Both concepts are supported by the principle that each component has to provide a persistency service and an implementation service, as described above.

Component Store. The component store can be implemented in a standard RDBMS, as the prototype-instance model can be mapped in a straightforward way to tables and relationships. Access to stored components is implemented in a transaction-oriented protocol supporting checkin, checkout, lock, unlock, set and get operations. Stored components are uniquely identified through a UUID and a version number. Access to stored components would typically be through engineering tools such as property editors and GUI builders.

Resource Generator. The resource generator creates resources from the component model of a web application. The mapping is facilitated by the components’ implementation service. Starting from a root component, the implementation service is invoked top-down from composite components to atomic components. The resource generator can perform both a complete installation and an incremental update of a web application. For a complete installation, the resource generator proceeds top-down through the component hierarchy, top-down making directories, opening files and filling files with code. For incremental code generation, the resource generator makes use of the component store's revision control. In this process, it generates those resources that contain components that have been modified. As resources themselves are represented by components, component dependencies can be evaluated to identify dependent resources.

In this section, we describe an open implementation based on the object-oriented WebComposition approach. Our main goal is to provide a possibility, that enables component developer to describe and even exchange components whatever type of component store is in use. Further, by making available a system-independent description language for WebComposition components mobile-device companies could support a well-known set of layout components that ideally solve display limitations of their devices.

Fig. 2. Generating Components

This goal is achieved by using the eXtended Markup Language (XML) developed by the Standard Generalized Markup Language (SGML) working group of the W3C [W3C]. XML allows the definition for a tag-based textual format for semantic mark-up of documents or data. Parsers are widely available for almost any important platform, like Unix and WindowsNT, providing the web application or the content. Beside the fact, that we prefer the Web as application platform, the semantic mark-up enables a resource generator to create content even for non HTML-enabled devices (e.g. Mobile Phones may receive SMS messages).

Turning back to the WebComposition approach we can say that a set of components described in an XML-based language is equivalent to the "component store". This idea is shown in figure 2.

A resource generator accesses a component store by an URI and retrieves a description of the components that need to be transformed into the implementation model of the target system (the Web implementation model). The components and their states represented by their properties are described in an XML-based Language, called WebComposition Markup Language. This view on the WebComposition approach doesn't assume a client-server content delivery model, as shown in the above figure.

The WebComposition Markup Language (WCML) describes an XML vocabulary for WebComposition that allows the definition of (web-) components, properties, and relationships between these components. The following code shows a typical structure of a WCML document with some components:

Each component is identified by a universally unique identifier (UUID); these are in our example the UUIDs CVersion and CVersionNice. The current state of the CVersion is defined by the value of the 'content'-property. The property is evaluated by the resource generator to create the presentation of the component. It is the representative for the presentation interface/service described in the WebComposition approach. The second component CVersionNice references the CVersion component (by referencing the content-property with the refprop-tag) and adds layout information to the content. In this code-sharing example the generation of the component CVersion would be "Version 1.122.58" and CVersionNice would result in "Version 1.122.58".

Components can be derived from other components based on the prototype-instance model. The description of a prototype-instance relationship is given by the prototype-tag. A component referencing a prototype-component possesses all prototypes and properties of the prototype-component, which may be redefined by the latest declaration of a property. The following code-segment shows a component deriving from the CVersionNice-component:

The CversionNice2 derives the content and the fontstyle property. By declaring an own fontstyle-property, the value of the derived fontstyle-property is redefined. The presentation of the new component would be: "Version 1.122.58". This example shows the difference between class-based and prototype-instance inheritance. Following the prototype-instance model, a component may be an instance (like CVersionNice), but may also serve as prototype describing properties for an inheriting component.

In summary it has be pointed out that an XML-based description language allows to exchange components between operating systems. XML based upon proven SGML technology is rigorous in terms of well-formed and valid documents and therefore it is easy to parse XML-documents, which is important for making good use of WCML. WCML abstracts from the concrete Component Store in use. This abstraction extends the WebComposition approach by making the concrete Component Store unnecessary, giving the WebComposition approach more flexibility.

The following section shows how to use WCML to provide access to a web application for different PDAs.

In this section, we will apply the component model as described in section 0 to support different views to the content of an application. This example will show how to develop an ideally adapted web application for mobile devices. We also demonstrate how prototyping helps extending an application for additional devices.

Mobile device users suffer from display limitations and bandwidth restriction as shown in section 1. The example shows a typical Login-Screen for accessing the TravelAssistant-System, an information system, which supports customers with travel planning like plain-schedules etc. The use of WCML will only deal with the Login-Screen, but the results can easily be adopted for other pages.

The following figure shows the desktop version of the Login-Screen displayed for a 20"-Monitor.

Fig. 3. Login-Screen for 20"-Monitor

The page contains five major elements. The top left element shows an image of the system provider and the applications version number. The middle of the page presents the application name, followed by a form and some text explaining what the user has to do to access the information system. User new to system may register to get instant access. A copyright notice is given at the end of the page.

Following this scenario and reusing some existing components by code sharing the code segment gives a component description for the above figure.

The CDesktopContent-component references the Logo-component, which itself derives the image and version properties from the CDesktopContent-component (prototype element in refprop-tag). The next four tags reuse the content of the existing components by simple code sharing without inheritance.

The following component is used for displaying the Login-page on a WindowsCE device. To avoid scrolling forced by the half size display resolution the important components are reordered from left to right. The possibility to register from a mobile device will not be supported. The ordering is done by adding simple HTML-code (Table-tags) to the existing component references. In addition, the image-property value is changed to a WindowsCE suitable image filename.

The result is shown in comparison to the Desktop page in the following figure:

Fig. 4. Login-Screen for WindowsCE device

This example shows how easily the model of a web application can be extended to support different platforms. The content is reused on basis of inheritance facilitating further maintenance tasks.

In this paper, we have proposed an object-oriented approach to development of web content adapted to mobile platforms. Our approach is based on the observation even seemingly similar devices such as Personal Digital Assistants, vary largely regarding constraints effecting content delivery. Further, it is based on the experience that automated conversion of web content in general does not yield satisfying results. The alternative to automated conversion is development of explicitly adapted content for each platform, which of course imposes, replicated development effort, not to speak of the maintenance problems. To reduce the development and maintenance effort we propose to use an object-oriented framework based on the well-known model-view concept. This framework ensures, that content is only specified once and then referenced by different views which are optimised for the different target platforms.

While the proposed framework as such is straightforward, its application in the Web unfortunately is not, as the web implementation model does not support the required object-oriented concepts such as abstraction, delegation, and inheritance. To close this gap, we have applied the WebComposition model for which we have presented an XML-based implementation, the WebComposition Markup Language. This language enables object-oriented specification of web content that can be deployed to different platforms. For a small example application, we have demonstrated code reuse based on delegation, and extensibility based on inheritance.