Server and proxy based Architecture The proxy-based architecture is a very suitable for the context change support. In this case, the proxy is the entity responsible of retrieving client contexts and looking for the eventual changes that may occur. These changes are therefore transparent for the content server. The proxy can transform existing multimedia content and thus the content server is not directly involved in the adaptation. At this stage, the client profile is always stored in the same location as the user context module. At any moment, the profile can be changed by selecting another profile. 

Context in source publication

Context 1

... applied mainly following two ways: 1- Variant selection : consists to choose the best variant of the server content on behalf the user agent. The selection is applied on the available variant list and based on variants description and the user requirements. Selection parameters include the language, the media type, the char-set, etc. The decision of the selection can be determined using an algorithm that handles the different situations [12][8]. Unfortunately, variant selection is not enough flexible and dependents on the variants availability. requirements can be described as a set of constraints that need to be solved. The concept of constraints takes a high importance in the practical application of the content negotiation. In this context, we define a constraint as: “ an atomic final delivered content will be used ”. In practice, the architecture can take into account the constraints collection of more than one element. In our approach, the resolution strategy starts from the assumption that the original content is accepted and continues by adding the constraints progressively. Finally, it ends with a solution that determines the content to be delivered. Possible solutions include an empty content in the case where the constraints can not be solved. In this case, the server sends a negative reply to the client. In order to achieve an efficient content negotiation solution, the environment constraints must be well expressed in order to reflect the picture of the delivery context. Constraints syntax must: 1- Provide enough expressiveness, in order to allow the description of what is required. 2- Offer an easy analysis for resolution strategies. 3- Avoid ambiguity: constraints must result in a unique solution. Example : Let’s assume that we have in the server side an original content in the form of XML document written in English. Let’s have the two following constraints expressed in the natural language: C 1 ={the preferred language is French}, C 2 ={the only supported language is French}. In a situation where the global context is represented by the first constraint C 1 , the content of the server can be delivered directly to the client. This case is equivalent to having no constraints at all. In a situation where we have C 2 as environment constraint, the original content can’t be delivered directly to the client because the content doesn’t respect the environment constraints. In our approach, the client constraints that depend on capabilities are extracted directly from the HardwarePlatform, SoftwarePlatform and BrowserUA components from the UPS client profiles. In the RDF bags: OnlySupportedResources, PreferredSupportedResource and NonSupportedResources, we extract additional constraints related to the content in terms of capabilities and preferences. During the negotiation matching, the client profile and the document instance profile of the requested content are parsed and the set of included constraints are stored in memory according to their types. The server makes the reference to the document instance profile. According to its content, the server can retrieve using the exchange protocol- the client resource profile [11] that corresponds to the resource used by the requested content. For example, the server retrieves the client resource profile of the WBMP images if the original requested document uses WBMP images. The server checks then if the resource (media or document) is supported by the client or not. In the positive case the resource is sent directly to the client without any modifications. In the negative case the server checks if there is any other version that can respond to the client requirements. Links to the list of versions related to the resource are included in the document instance profile or the client resource profile [11]. If the server succeeds to find a variant that responds to the client requirements, the original resource is substituted by the variant resource; otherwise the server tries to adapt the original resource. To achieve this operation, the server compares the original resource description (using its profile) and the set of the input requirements of each available adaptation methods included in the RDF bag: InputRequirements of the adaptation method profile [11]. If the resource description matches the input requirements of an adaptation method, the server checks if the output description of this method (included in the RDF bag OutputDescription of the adaptation method profile) matches the client requirements. If yes, the server applies this adaptation method on the original resource and delivers the created resource to the client. In the negative case, i.e. no adaptation method can be applied, the server sends a negative reply concerning the requested resource in order to avoid the client blocking. The negotiation exchange protocol and the content negotiation and adaptation strategies have been implemented within a proxy-based and server-based architecture (Figure 6). In both architectures, the used network is based on two infrastructure types: an 802.11 wireless LAN and a wired network. Three kinds of devices are used to access content: a personal device assistant (iPAQ 3600) running under Windows CE and connected through the wireless network, a laptop computer using both the wired connection and the wireless one and a personal computer that uses the wired network. In the proxy-based architecture a negotiation module is added to the communication proxy in order to retrieve and request the different client profiles. The same module is integrated to the content server in the server-based architecture. The difference between the two architectures is that in the case where we use an intermediate proxy, we can not experiment all the aspects of the content negotiation and adaptation strategy. In this case, tasks like evaluating the available content variants and content substitutions can not be performed correctly due to the lack of control on the content. An adaptation method M is applied on a resource R , if the UPS description of R matches the UPS input requirement of M , and the UPS output description of M matches the client requirements. To avoid developing static adaptation methods for each kind of resources adaptation, it’s preferable that the server has methods that provedes many outputs depending to the context of their application. This is called dynamic adaptation. A dynamic adaptation is the one that interacts with the current client context. Taking into account the client context by an adaptation method can be achieved at two locations: the client or the server (or proxy). In the general case, the client content adaptation is achieved using scripts and rendering styles which are sent inside the content and evaluated during the rendering according to the capability of the user device. Unfortunately, this kind of adaptation has many disadvantages and depends widely on the client processing power. Dynamic adaptation on the server represents a best alternative to deal with the variety of client contexts. It allows the delivery of adapted content directly. In our system, we consider two kinds of adaptations: the structural adaptation (transformation) and the media adaptation. Structural transformations are based on XSLT [19] which allows transforming XML document into other XML documents. Media adaptations use specific applications. Providing XSLT style sheets that handles client profiles is seems interesting since the server can obtain adapted content by applying the generated style sheet to content. It is also possible to concatenate the original service with the user agent context (or profile) and then apply the style sheet. In practice, this is very complicated to achieve using XSLT templates. The two parts of the input tree (the constraints profile and the original content, see Figure 7) are separated and requires intensive processing to achieve the cooperation between them. The scheme that we propose here consists to define a generic style sheet that admits as input the client profile and generates as output a style sheet. scenarios executions. Figure 9 represents the generic XSLT style sheet used for filtering. The style sheet of the figure 10 is generated automatically following the proposed approach and it can be used to transform SMIL content according to the user constraints given in the client profile. This kind of adaptation concerns media resources such as images, videos, etc. A context is considered as a set of variables that reflect the state of the client capabilities and preferences. Consequently, a context change is equivalent to a values change of these parameters. The new values of the context are taken as input and the corresponding adaptation methods are applied. Here are some experimental results concerning the dynamic adaptation used within the exchange protocol. In each application, a user is associated with as a set of variables used in the adaptation. Application 1 : Image generation using structural transformation (Figure 11): XML to SVG [17]. The client context about the requested content includes the following set: {wanted_text="Structural Transformation", image_width = 400, image_height = 60, preferred_font_color = "blue", preferred_font_size = 30, preferred background color = "red", preferred text position=40}. In the current internet, providing adaptable content delivery is crucial. This becomes even more important when considering multimedia content which requires the handling of resource intensive media. As stated in the paper, defining a complete adaptable content delivery system is not an easy task. It introduces many challenges at different levels of the current infrastructure. One of such challenges is the definition of a model for describing the environment or the environment constraints that have to be taken into account. UPS was proposed as a flexible model for describing not only the client but also the ...