See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/2459165
`
`Web Content Delivery to Heterogeneous Mobile Platforms
`
`Article  in  Lecture Notes in Computer Science August 2000
`
`READS
`133
`
`Michael Beigl
`Karlsruhe Institute of Technology
`
`402 PUBLICATIONS   7,342 CITATIONS   
`
`SEE PROFILE
`
`Source: CiteSeer
`
`CITATIONS
`38
`
`4 authors, including:
`
`Martin Gaedke
`Technische Universität Chemnitz
`
`264 PUBLICATIONS   2,930 CITATIONS   
`
`SEE PROFILE
`
`Hans Gellersen
`Lancaster University
`
`274 PUBLICATIONS   12,503 CITATIONS   
`
`SEE PROFILE
`
`Some of the authors of this publication are also working on these related projects:
`
`Fundamentals of AI methods application in HCI engineering View project
`
`Linked Enterprise Data Services View project
`
`All content following this page was uploaded by Michael Beigl on 25 April 2013.
`
`The user has requested enhancement of the downloaded file.
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 1 of 14
`
`

`

`Web Content Delivery to Heterogeneous Mobile
`Platforms
`
`
`
`Martin Gaedke, Michael Beigl, Hans-Werner Gellersen, Christian Segor
`
`Telecooperation Office (TecO), University of Karlsruhe
`Vincenz-Prießnitz-Str. 1, 76131 Karlsruhe, GERMANY
`Ph. +49 (721) 6902-79, Fax +49 (721) 6902-16
`
`{gaedke, michael, hwg, segor}@teco.edu
`
`Abstract. It is widely acknowledged that information such as web content
`should be adapted for mobile platforms to account for restrictions in mobile
`environments. As emerging mobile platforms such as different kinds of
`Personal Digital Assistant (PDA) tend to vary largely in their capabilities, we
`suggest that adaptation should be platform-specific. Common approaches for
`content adaptation are automated conversion and explicit specification of
`adapted content, with a trade-off between quality and development/maintenance
`effort. As alternative avoiding this trade-off, we propose a simple object-
`oriented framework for content adaptation. To facilitate the use of this
`framework in the Web, we base our approach on the object-oriented
`WebComposition model and its XML-based implementation WCML. We apply
`our object-oriented approach to an example application to demonstrate how
`object-oriented
`specification
`of
`platform-adapted
`content
`reduces
`development/maintenance effort.
`
`Information Access from Mobile Devices
`
`Information access from mobile devices has to take a range of restrictions into
`account, which exists in mobile computing environments in comparison to desktop
`environments. Both, properties of wireless networks and of mobile devices have to be
`considered. Regarding mobile devices, most notably screen real estate, computing
`power and power consumption are relevant. In this article, we refer to Personal
`Digital Assistants (PDA) with their largely varying properties to motivate the need to
`adapt information for delivery to mobile devices. The proposed solution though does
`not merely apply to PDAs but to heterogeneous mobile devices in general.
`
`Several restrictions influence whether and how information can be presented on PDA
`devices. Each of these restrictions has to be taken into account when building content
`that should be delivered to and viewed on a PDA, or other mobile devices. Below, the
`most important restrictions are discussed.
`
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 2 of 14
`
`

`

`206
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`• Power Consumption. Many researchers have indicated that battery live and power
`consumption are an essential constraint that mobile devices struggle with; special
`care has to be taken that applications save these important resource. For example,
`power consuming output methods such as audio should be avoided on mobile
`devices.
`• Computing Power. Mobile devices usually have less computing power than
`stationary computers; computing power also varies largely among PDAs or more
`generally among mobile devices. Therefore, content requiring a lot of computing
`power, for example compressed video, is usually not suited for display on PDAs.
`• Display Properties. PDAs and other mobile devices have very little screen real
`estate compared to desktop computers. Furthermore, display properties among
`different PDAs vary too a large extent. Table 1 shows a comparison of resolution,
`size and colour depth supported by different PDAs. This table indicates clearly a
`quite impressive difference of the display possibilities of different devices: the
`resolution ranges from 160x98 to 640x480 (factor 20), the size from 3,3x2,1 cm to
`13x8 cm (factor 15), and the colour depth from 1 bit grey scale displays to TFT
`with 16 Millions of colours.
`
`Table 1. Display Properties
`
`Display resolution Display Size
`160x98
`3,3x2,1 cm
`160x160
`6x6 cm
`640x200
`11,43x3,6 cm
`
`640x240
`240x320+
`
`5,1x13,5 cm
`Ca. 8x6 cm
`
`Device
`Franklin Rex
`3Com PalmPilot
`Nokia
`Communicator
`Psion 5
`WindowsCE
`PalmPC
`Windows
`Handheld
`Apple
`2000
`6,1’’
`640x480
`Toshiba Libretto
`+ Except Casio PA-2400 Cassiopeia 420x240
`
`CE
`
`640x240
`
`Ca. 16x6 cm
`
`Newton
`
`480x320
`
`12,98x8,32 cm
`
`Capability
`2 grey scale
`2 grey scale
`8 grey scale
`
`16 grey scale
`Grey scale
`
`or
`
`scale
`
`Grey
`colour
`16 grey scale
`
`16,7 Mio colours
`
` 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
`
`Type of Communication Connection Cost
`I/R Communication
`-
`Radio Communication
`-
`GSM Modem/Phone
`1,20$/60sec (in Germany)
`
`Bandwidth
`115 kbit
`2 Mbit
`9,6 kbit
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 3 of 14
`
`

`

`
`
`207
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`
`
`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 4 illustrates an example-application applying the
`framework
`
`Approaches to Web Content Adaptation for Mobile Platforms
`
`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
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 4 of 14
`
`

`

`208
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`
`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.
`
`
`Object-Oriented Development of Web Content
`
`An Object-Oriented Framework for Content Adaptation
`
`We propose an object-oriented approach to provide information for heterogeneous
`browser platforms. The approach aims at provision of content adapted to specific
`browsers but uses object-oriented concepts to avoid replicated content definition. The
`idea is based on the well-known model-view concept (or Observer pattern [2]) to
`maintain different views of the same content. In this case, different views being
`content presentations are adapted to specific browser platforms. Besides model-view,
`the idea is to capture commonalties among different views in generalised views, and
`to apply object-oriented inheritance to derive specific views.
`
`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
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 5 of 14
`
`

`

`
`
`209
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`
`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.
`
`
`Page
`{abstract}
`
`Body
`{abstract}
`
`*
`
`Content
`Element
`
`SpecificPage
`
`SpecificBody
`
`....
`
`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 see [3]. Following this, an
`XML-based implementation is introduced.
`
`The WebComposition Model
`
`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 itself 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 that page; and a component modelling a
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 6 of 14
`
`

`

`210
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`
`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 act 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.
`
`General WebComposition Implementation Concepts
`
`the web
`from
`is an abstraction
`The WebComposition component model
`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
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 7 of 14
`
`

`

`
`
`211
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`
`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.
`
`An XML-based Implementation of WebComposition
`
`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. Furthermore, 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
`[11]. 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).
`
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 8 of 14
`
`

`

`212
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`
`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.
`
`WebComposition Markup Language
`
`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:
`<wcml>
` <component uuid=’CVersion’>
` <property name=’content’>Version 1.122.58</property>
` </component>
`
`<component uuid=’CVersionNice’>
` <property name=’fontstyle’ value=’B’/>
` <property name=’content’>
` < <refprop name=’ fontstyle ’/> >
` <refprop name=’content’ from=’Cversion’/>
` </ <refprop name=’ fontstyle ’/> >
` </property>
`</component>
`
`...
`
`</wcml>
`
`Each component is identified by a universally unique identifier (UUID); in our
`example the UUIDs CVersion and CVersionNice. The current state of 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".
`
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 9 of 14
`
`

`

`
`
`213
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`
`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:
`<component uuid=’CversionNice2’>
` <prototype is=’CversionNice’/>
` <property name=’fontstyle’ value=’I’/>
`</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 different operating system. 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 actual Component Store in use. This
`abstraction extends the WebComposition approach by making the actual 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.
`
`Example application
`
`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.
`
`General description for implementing the Login-Screens with WCML
`
`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 flight schedules etc. The use of WCML will only deal with the Login-
`Screen, but the results can easily be adopted for other pages.
`
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 10 of 14
`
`

`

`214
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`
`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
`following code segment gives a component description for the above figure.
`<component uuid=’CDesktopContent’>
` <property name=’image’ value=’tecologo.gif’/>
` <property name=’version’>Version 1.122.58</property>
` <property name=’content’>
` <refprop name=’content’ from=’CLogo’
` prototype=’CDesktopContent’/>
` <refprop name=’content’ from=’CApplicationName’/>
` <refprop name=’content’ from=’CForm’/>
` <refprop name=’content’ from=’CRegister’/>
` <refprop name=’content’ from=’CCopyright’/>
` </property>
`</component>
`
`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
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 11 of 14
`
`

`

`
`
`215
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`
`(Table-tags) to the existing component references. In addition, the image-property
`value is changed to a WindowsCE suitable image filename.
`<component uuid=’CWindowsCEContent’>
` <property name=’image’ value=’tecologo256Color.gif’/>
` <property name=’version’>Version 1.122.58</property>
` <property name=’content’>
` <table border="0" cellspacing="5"><tr><td>
` <refprop name=’content’ from=’CLogo’
` prototype=’CDesktopContent’/>
` </td><td>
` <refprop name=’content’ from="CApplicationName"/>
` </td><td>
` <refprop name=’content’ from="CForm"/>
` </td></tr></table>
` <refprop name=’content’ from="CCopyright"/>
` </property>
`</component>
`
`The result is shown in comparison to the Desktop page in the following figure:
`
`
`Fig. 4. Login-Screen for WindowsCE device
`
`
`
`Extending for low Bandwidth devices
`
`In this last example, we will show how easily the model can be extended using
`existing components as prototypes. In case one needs to provide the WindowsCE
`page
`for access by
`low bandwidth,
`the
`following component uses
`the
`CWindowsCEContent-component as prototype but redefining the image-filename.
`The generator will create the same content (ordered from left to right), but linking to a
`picture of smaller size. The second (for Psion devices) and third (for Pilot devices)
`components also reuse the code by prototyping, but linking to images capable by the
`devices. Due to the small display of the Pilot, the image is cut out of the page.
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 12 of 14
`
`

`

`216
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`<component uuid=’CWindowsCEContentLowBandwidth’>
` <prototype is=’CWindowsCEContent’/>
` <property name=’image’
` value=’tecologoCELowBandwidth.gif’/>
`</component>
`
`<component uuid=’CPsion’>
` <prototype is=’CWindowsCEContent’/>
` <property name=’image’ value=’tecologo16Gray.gif’/>
`</component>
`
`<component uuid=’CPilot’>
` <prototype is=’CWindowsCEContent’/>
` <property name=’image’ value=’’/>
`</component>
`
`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.
`
`Conclusion
`
`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.
`
`Smart Mobile Technologies LLC, Exhibit 2017
`Page 13 of 14
`
`

`

`
`
`217
`Gaedke et al., “Web Content Delivery to Heterogeneous Platforms”
`Lecture Notes in Computer Science (LNCS), Springer Verlag, vol. 1552, 1998
`References
`
`[1] Beigl, M. MODBC - A Middleware for Accessing Databases from Mobile Computers.
`Proceedings of 3rd Cabernet Plenary Workshop, Rennes, France, 1997
`[2] Gamma, E., Helm, R., Johnson, R. and Vlissides, J. Design Patterns Elements of Reusable
`Object-Oriented Software, Addison-Wesley, 1994.
`[3] Gellersen, H.-W., Wicke, R. and M. Gaedke. WebComposition: an object-oriented support
`system for the Web engineering lifecycle. In Computer Networks and ISDN Systems 29
`(1997), Special Issue on the 6th Intl. World-Wide Web Conference, Santa Clara, USA, April
`1997, p. 1429-1437.
`[4] Gessler, S. and Kotulla, A. P