## 5 Extending the Mediator-Wrapper Architecture
### On the Implementation of a Mask
Such data transformations can only be achieved through processes, so in a general sense, it is more sensical to discuss the mask in terms of processes and the data that flow between them. To achieve a more detailed elaboration of the mask, building upon the model from Figure 10, a data flow diagram is constructed as displayed in Figure 11. Figure 11 displays the recognized processes as circles, outer entities as rectangles (users and mediator), data storage as open rectangles, and flowing data as named arrows. On the right-hand side of Figure 11, the schema translator of Figure 10 is decomposed as two processes: schema loading and schema translation. The schema loading process is concerned with the acquisition of a system schema from a connected mediator. This schema is also stored for other usage, besides schema translation, but it should be reacquired frequently to maintain an up-to-date schema. For this reason, schema loading is considered a separate and independent process. The schema translation process uses the currently acquired system schema and schema mapping rules from a separate storage to create a masked schema. This masked schema is presented to the user. The querying process in Figure 11 is a complex process that concerns itself with querying over a mediator. It is closely tied with processes of query translation and result translation. These processes are effectively subprocesses of querying but have been extracted due to their importance and correlation with components in Figure 10.  
The query translation process translates a masked query into a system formatted query. It requires data about the current system schema and schema mapping rules to determine the way in which they are reflected onto the current query. This must be considered, as the schema translation might change the resources' names or change their schematic, so it becomes important to reverse those translations when constructing a system query. The query translation process also requires query mapping rules. As a general example, and for the moment setting a simplified generic model for a query--these rules might explain how a projection or selection in a query is to be translated. Figure 10: A conceptual model of the mask’s functional components. The result translation process also requires data about the current system schema and schema mapping rules, as it is also concerned with translating a small view-like portion of the schema with the addition of holding result data that can also go through some masking transformations. Just like in other translational cases, result data translation also requires some mapping rules for data results. There is also a very interesting feature of the diagram in Figure 11 regarding all the mapping (rules) data storage. The result mapping, schema mapping, and result mapping data storage do not have any data inflows. These mappings are, in the context of this diagram, then clearly provided by some other undefined source. In fact, these mappings can only be provided by the developers of a certain mask component. These mappings are the exact point at which the system can no longer be designed as generic or abstract, and some concrete implementation or empirical data describing the masking of the system is required. Considering the mentioned findings, a conceptual component design for a mask is proposed and shown in the diagram of Figure 12. The goal is to also to think of the mask's component design without reducing generality to avoid prescribing any concrete programming paradigms, languages, or specific design patterns. Figure 12 illustrates the recognized components of a mask as white rectangles (cylinder in the case of a metadata database), required implementations for a mask kind as gray rectangles (implementation indicated by arrows with empty arrow-heads), and data flow as arrows with black arrow-heads. Figure 11: Dataflow diagram following the mask’s functionalities.