Gerald Hübsch, Thomas Springer
Dresden University of Technology
Department of Computer Science,
Institute for System Architecture,
Mommsenstr. 13,
D-01062 Dresden, Germany,
{huebsch, springet}@rn.inf.tu-dresden.de
An inherent challenge in service provisioning in a dynamic heterogeneous environment is the adaptation of the service and its content to the current context conditions. Context-aware adaptation may be generic or application-specific and may span user-interface, network, and application layers. The context-dependent selection of content depending on specific properties of a client device (such as its support for certain media types such as images or sound, its display size and supported markup elements such as frames), dialog pagination, adaptive dialog flow control, and the adjustment of the functional complexity of an application to its current context of use are examples for context-aware semantic adaptation in the scope of adaptive web applications. Common to all these examples is the necessity to manually supply semantic meta-information through semantic annotations to control adaptation. These annotations must be editable for the developer at design time and machine-readable to allow for their runtime evaluation. In the following, we present concepts for semantic annotations in a single-source markup language for authoring device-independent web applications. The approaches presented here have been successfully implemented in a research project.
This section gives an overview over semantic annotations and the related adaptation concepts implemented in the Dialog Description Language.
The Dialog Description Language (DDL) is a language based on the Single Source Authoring approach that allows for the device-independent representation of both static and dynamic web application UIs. It enables the separation of structure, presentation, and content of web application dialogs and supports meta-data concepts for semantic adaptation. We refer to the process of mapping a semantically adapted dialog into a target markup as Syntactic Adaptation. The DDL is based on a simple XML meta-language model consisting of four basic elements: <ddl>, <dialog>, <part> and <property>. The <ddl> element is the document root element of any DDL dialog, <dialog> encloses the content section of a DDL document. The <part> element represents an arbitrary dialog element. It is utilized to generically describe element types (e.g. input fields, frames, tables etc.), i.e. the element semantics, using a set of properties. It can be nested to allow for ancestor-child relationship modelling. Properties are assigned to parts using the <property> element. A type property defines the type of each part. All other properties are type-specific, e.g. for describing the URL of a hyperlink element or the size of a text input field. Figure 1 depicts the DDL syntax diagram. Part types are shown in bold type, part properties are listed below.
An Adaptation Engine (AE) is responsible for performing all semantic and syntactic adaptation operations on a given DDL dialog at runtime. AE operations are invoked by HTTP requests for DDL documents received from a client device. The response sent to the client contains the fully adapted presentation of the requested dialog. In DDL, information about dialog semantics is manually added at authoring time by means of semantic annotations. DDL supports the adaptation concepts of selective content and dialog pagination. Selective content eliminates or selects alternative content, e.g. to avoid the delivery of long explanatory texts to a small screen device. Dialog pagination is the process of splitting up complex dialog structures into less complex substructures and their sequential delivery to the client while maintaining the logical structure of the dialog. By dialog pagination, we meet constraints imposed by mobile devices such as display size, datagram and memory size limitations, and usability constraints. As opposed to the delivery of large, complex pages, pagination reduces the need for extensive scrolling and reduces transfer and rendering times for the single fragments. Additionally, pagination generates specific target-markup constructs for presentation control, e.g. for content distribution over several WML Cards within a single WML Deck.
Figure 1 - DDL Part types
In DDL, the concept of selective content is implemented by context queries over context profiles available to the AE. These context queries can be attached to any part and property element through a test attribute. We do not utilize external annotations for selective content because a separation of content and annotations yields the risk of inconsistencies. A DDL context query must be evaluated to a Boolean value. If the query condition is fulfilled, the respective element is left in the dialog, otherwise it is removed. Figure 2 shows a sample DDL dialog snippet with context queries. The logo image is shown on graphics-capable clients, a short text is displayed on other clients.
<part test="/client/display='graphical'"> <property name="type">image</property> <property name="src">logo.jpg</property> </part> <part test="not(/client/display='graphical')"> <property name="type">label</property> <property name="content">ACME Corp.</property> </part> |
Figure 2 - Semantic Annotations for Selective Content in DDL
For processing within the DDL AE, HTTP requests are augmented with a context information profile created by a dedicated runtime component that we refer to as Client Recognizer. All adaptive algorithms implemented within the AE utilize the information conveyed in this context profile to access the context parameters required for their operations. The minimum set of context data contained in a DDL AE context profile includes the client's markup language type, the dimension of the client's display in pixels, its display type, the maximum transferable dialog size in Byte, and the device class according to our underlying device classification schema. The internal context profile representation used by the AE is based on a well-formed XML document. To provide a maximum of flexibility towards application-specific profile extensions, we do not require the context profile to be valid in terms of a DTD conformance. Thus, an application requiring additional context attributes to be available for selective content processing can be supported by simply adding these values to the context profile at runtime by an accordingly modified Client Recognizer.
DDL context queries are simply formulated in XPath. From our point of view, XPath provides a simple but powerful and flexible way to formulate both simple and complex queries. While simple queries only refer to one context parameter, complex queries utilize the Boolean operators supported by XPath to link sub-query results. Furthermore, we successfully make use of the Numeric and String comparison operators provided by XPath that can directly operate on parameter values in the context profile. Although our approach is very flexible and straight-forward, it requires the content author to be familiar with XPath. This fact may be considered as a drawback for a practical deployment of this solution.
This section present two approaches for dialog pagination in DDL. For both approaches, the DDL language semantic annotation concepts and the pagination algorithms controlled by these annotations are presented.
To control dialog pagination, the DDL's Atoms and Molecules approach provides means to define logical dialog units (DDL Atoms). DDL Atoms group dialog elements that have a semantic relationship and thus must not be separated by dialog pagination.
<part>
<property name="type">container</property>
<property name="atom">true</property>
<part>
<property name="type">label</property>
<property name="content">Password:</property>
</part>
<part name="passwd">
<property name="type">textinput</property>
</part>
</part>
|
Figure 3 - DDL Atom
Syntactically, the grouping of arbitrary parts (except frames and frame sets) in DDL is achieved by the container part type (cf. 1). To construct a semantic grouping, the DDL atom property must be added to a DDL container. If the property value is set 'true', the respective container is converted into a DDL Atom. It will not be split by dialog pagination. A DDL container without this property might be paginated at any valid pagination point. Pagination points are implicitly defined by part boundaries of DDL Atoms. Parts without descendant part nodes are DDL Atoms by default. Likewise, form controls composed of nested parts (radiogroup and select, cf. 1) are treated as DDL Atoms. Figure 3 depicts a DDL code snippet that groups a text input field with its caption using an atomic DDL container to prevent their separation by dialog pagination.
The Atoms and Molecules pagination algorithm described in the following is responsible for the dialog pagination at runtime. First, the algorithm fully splits up a dialog into atomic parts. It determines the weight (i.e. size in transfer encoding, display space required on the client device) for every atomic component. These atoms are assembled to fragments of maximum size (DDL Molecules) w.r.t. their weight and client constraints. Finally, they are interlinked to allow for user navigation.
As opposed to content control, the developer has no direct control over the result of the pagination process since the split may be placed at any valid pagination point. Split placement solely depends on the strategy implemented by the pagination algorithm. This drawback can be avoided by the direct manual definition of static pagination points (see sect. 2.3.2).
The idea of the static pagination algorithm is to supplement DDL dialogs with pagination points at authoring time. Pagination points are utilized as predetermined breaking points for dialog pagination. Thus, they represent meta-information that controls the pagination process. In DDL, static pagination points are represented by the fragment element. The fragment element is empty. To define a pagination point, it is placed between two arbitrary DDL parts contained in a DDL container (cf. 4). In order to further enhance the developer's control over the pagination result, it is necessary to define different pagination levels. This is achieved by adding a level attribute to the fragment element (cf. 4). The level attribute is a positive Integer value that determines the priority of the related pagination point. Pagination level 1 has the highest priority. In combination with the pagination algorithm described below, pagination levels provide a simple way to control the pagination result.
<part>
<property name="type">container</property>
<part>
<property name="type">image</property>
<property name="src">logo.jpg</property>
</part>
<fragment level="1"/>
<part>
<property name="type">label</property>
<property name="content">Password:</property>
</part>
<part name="passwd">
<property name="type">textinput</property>
</part>
</part>
|
Figure 4 - DDL Dialog with Pagination Point
If dialog pagination is necessary (the DDL dialog does not meet the constraints imposed by the client), the static pagination algorithm starts by splitting the dialog at all pagination points with the highest priority. It determines the weight (i.e. size in transfer encoding, display space required on the client device) of all resulting dialog fragments. Fragments that do not meet the client constraints on the current pagination level are re-paginated using the next pagination level. Figure 5 depicts the static pagination algorithm in pseudo-code notation.
While the static pagination approach provides better control over the pagination points, coarse-grained pagination point placement or a lack of pagination levels may yield a suboptimal pagination result for some clients.
d = { DDL dialog to be paginated }
x = max. fragment size (usability and size constraints imposed by client)
split_level = 1
static_pagination (d, split_level, x) {
S = paginate_at_level(d, split_level)
foreach { e | e ? S ¸ e.weighted() > x } do begin
S = S \ e
T = static_pagination(e, split_level+1, x)
S = T ^ S
end
return S;
}
|
Figure 5 - Static DDL Pagination Algorithm in Pseudo-Code Notation
The concepts briefly presented in this Position Paper were developed in a project aimed at the definition of a device-independent dialog description language and related adaptation technologies. While the concepts and solutions described here have shown to be sufficient in prototypical evaluations, we assume them to be extendible in different aspects. Thus, we hope to discuss the advantages and drawbacks of our solution with other researchers working in the area of device-independent content description languages and content adaptation.
Attending the W3C Workshop on Metadata for Content Adaptation we would furthermore like to learn and discuss about the current and future activities of W3C in that area and influence it by presenting our experience in the area of adaptive and device independent web applications.