Data flow of Event Processing

There are two directions of dataflow in MDPA,

• Event transmission: This pertains to the path taken by a user event captured in the MCL stage. This user event traverses the data pipeline until the event is processed. Each stage evaluates the user event, modifies it as necessary, and passed it to the next stage.

• Presentation Generation: This pertains to the path taken by the user presentation generated by the event processing. The user presentation is delivered to a user device. Stages that the presentation visits filter the presentation and pass the output on to next stage.

Event transmitting and presentation generating traverse in opposite directions along the data pipeline direction in their dataflow. The MCL stage is the first stage along the event transmission path, while it is the last stage for the presentation generation.

The process of adapting content is bi-directional along the pipeline and performed during both the dataflows. During the session of a service, the user event is captured in the user display environment customized for a specific user device. Since the presentation is filtered, information regarding the presentation cannot be applied to the original data object directly. Therefore, the event transmission also requires adjusting information pertaining to the user event. We call this “back channel communication”.

DAT CTL DTX PCL MCL <?xml vers <!DOCTYPE <!--local DT <svg width= <desc>This

User Event Transmission

SVG document with the original size of 1200 x 2000

DOM tree of SVG document

Rendered Image with CSS for PDAs

(resolution of 160 x 160)

SVG browser

for PDAs Actual Displayon PDA

Generating Presentation View

Figure 3.3 Event processing in MDPA with an example of SVG

As an example, we illustrate the Scalable Vector Graphics (SVG) [Ferraiolo+01] browser with a MDPA architecture. SVG is the W3C 2D graphic standard language in XML. SVG supports vector graphic shapes, image, and text. Graphical objects can be grouped, styled, transformed and composed into previously rendered objects. To browse a SVG image, users require a SVG browser, which parses the document, styles and renders the image. Figure 3.3 depicts the event processing in our SVG example. Let’s consider an example: drawing an arrow on a map illustrated with SVG documents. The display that the PDA user is seeing currently is a customized view for a PDA at a resolution of 160 x 160. The user points to (80, 80), the center of the presentation in his PDA screen, with the stylus. The event with the information of (80, 80) should be mapped to the position that denotes the center of the SVG image, based on the original coordinate system. Otherwise, the pointed position is not correct in different customized presentation views as depicted in Figure 3.4. Although the user wants to point to the center of the SVG document, the position pointed by PDA client is only a corner of that SVG image in the user presentation of the conventional desktop device. Moreover, when the user changes the resolution, and one user is looking at a different view of the presentation with others, we also cannot expect that the pointed position means the same the actual position in SVG image as shown in Figure 3.4-(b) and (c).

User presentation for PDA with resolution customization (80, 80) (80, 80) (80, 80) User presentation for Desktop PC with zoomed image

User presentation for Desktop PC with original resolution (a)

(b)

(c)

Figure 3.4 Event Transformation for Heterogeneous Customization of User Presentations

(a) Pointing the center of user presentation (80, 80) in the customized user presentation for the PDA

(b) Pointed user presentation for PCs with same position as (a) without filtering the event

(c) Pointed user presentation for PCs with same position as (a) without filtering event when the user zoomed the image.

Therefore, each stage should provide event filtering processing to map the event from the customized environment to the original environments. The most popular method is to keep track of history. For every pipeline, the activities are stored in a history buffer (a file). For simple processing, this strategy is very useful. In the SVG example, this can be used easily to recalculate the previous object based on the history.

However, there are some sophisticated tasks for which it complicated to get to the previous object. If the data is compressed to conserve network bandwidth, it needs specific reverse functions called “decompress” or “defrost” for accessing the previous object. Unfortunately, not all transcoding methods provide a reverse function. Since current transcoding methods, such as CCS or codecs, do not consider reverse functionality, this approach is rather difficult to implement. Therefore, we realized that

this is one of the major problems of the document object modeling in collaborative and interactive information systems.

In the SVG example, pointing at the (80, 80) event should be filtered to enable processing in the PCL stage. For instance, captured event (80, 80) is captured as the stylus clicking at the position (80, 80) on the PDA screen. This event is filtered to clicking (x, y) in an image displayed via the browser in the PCL stage. The event with position (x, y) is passed to the DTX stage and the DTX stage maps (x, y) to (x’, y’) which no longer corresponds to the PDA coordinates. Finally, the event arrives in the CTL stage with the actual coordinate (x’, y’) of the original image. The CTL stage filters the event to a semantically meaningful command, such as svgTest.addelement(arrow,

x’, y’). MCL stage PCL stage EFMCL(e) EFPCL(EFMCL(e)) EFDTX(EFPCL(EFMCL(e)) )

EFCTL(EFDAT(EFDTX(EFMCL(EFMCL(e))))) = eDAT

EPCTL(eDAT) PFDTX(EPCTL(eDAT)) PFPCL(PFDTX(EPCTL(eDAT))) PFMCL(PFPCL(PFDTX(EPCTL(eDAT))))

User event e

DAT stage CTL stage DTX stage

EFi : Event filtering function in Stage i

EPi : Event Processing function in Stage i

PFi : Presentation filtering function in Stage i

Figure 3.5 Data flow of SVG example

The event svgTest.addelement(arrow, x’, y’) is processed by event processing in the CTL stage, and the user presentation is generated as an output of the event processing. The output from the CTL stage is passed to the DTX stage for filtering the user presentation. Also the output of the DTX stage is delivered to the PCL stage, filtered and passed to the MCL stage. Finally, the MCL stage provides the actual user display depicted with the bitmap information. Figure 3.5 shows the data flow for the steps involved in the SVG event example.

We define the functions, event filtering, event processing, and presentation filtering for stage I, as EFi, EPi, PFi. The result of each function performing the event processing

feeds each other as input or output. Figure 3.5 illustrates how each function passes its output as input for the next stage in the dataflow.

As seen in the example, this event processing does not traverse all the stages of MDPA. User events in MDPA may or may not traverse all the stages in MDPA. We classify existing events with this traversing pattern, and describe it in section 3.2.2.