Defining web schema transformers by example - CiteSeerX

Defining web schema transformers by example Stephan Lechner, Michael Schrefl Department of Information Systems, University of Linz, Austria E-Mail: {lechner | schrefl}@dke.uni-linz.ac.at

Abstract. When defining a scheme of a web application (a web scheme) using a conceptual modelling tool, modelers successively perform design steps by extending or refining the scheme. Each design step is characterized by (i) the scheme to which the design step is applied (input scheme) and (ii) the resulting scheme (output scheme). As modelers apply similar design steps repeatedly, it would be convenient to have schema transformers that, when applied to an input scheme, generate an output scheme. In this paper, we present a way of defining schema transformers by example. A transformer comprises an input and an output template that are parameterized examples of an input and an output scheme, respectively. Therefrom executable code necessary for performing transformations can be generated automatically. A transformer is applied to an input scheme by binding elements of the scheme to parameters. For each such application, a corresponding output scheme is then generated. Our transformers can be introduced in various models/tools for web application modelling. We demonstrate this on the example of WebML.

1

Introduction

Conceptual modelling of web applications usually proceeds stepwise along the axis “content, hypertext, and presentation scheme” [5, 10, 8, 13]. However, as these schemes are not independent and because they all become iteratively more and more detailed, we will subsequently use the term “web scheme” (or simply scheme) as for a web application as a whole. With each design step, the scheme is extended or refined, for example, by adding new scheme elements like page classes and links to existing scheme elements. Therefore, a design step is applied to an input scheme that is thereby extended or refined and leads to an output scheme. Yet typical “patterns” of extending or refining parts of schemes are repeatedly applied. Such “patterns” may be explicitly recommended by the provider of the model/tool in use (e.g. [4, 11, 8]) but may also crystallize from the modeler’s experience. For example, having defined an entity type, often a page for displaying its members is added; this design step, which can be referred to as “create page for entity type”, is likely to be performed similarly for several entity types. This suggests to enable modelers defining and applying schema transformers that can perform design steps such as that described above. Thereby, use and definition of such transformers should be easy as this would facilitate fast production of web application prototypes.

Transformers for particular models have already been introduced [8]. They are defined by specifying a sequence of schema modification operations, e.g. “P.addLink (L)” for adding a link represented by L to a page class represented by P . However, this approach has two disadvantages: (i) definition of transformers requires to understand the schema modification operations available, and (ii) transformers are difficult to use for average modelers as semantics is hidden in code. In this paper, we present a way for defining schema transformers (or simply transformers) by example. Each transformer comprises two parameterized schemes (i.e. templates), whereby parameters are variables that represent scheme elements. Notably, these templates are defined with the same model/tool as used for defining schemes but have annotations, e.g. for identifying parameters. Therefrom a sequence of schema modification operations can be generated automatically such that definition and use of transformers does not require any knowledge about these operations. The two templates of a transformer have the following purposes: (i) the input template is a parameterized example of an input scheme. It declares constraints over parameters and thereby specifies to which input schemes the transformer can be applied. Most of these constraints are expressed implicitly by the graphical arrangement of scheme elements. Explicit constraints, if required, can be annotated. (ii) the output template is a parameterized example of an output scheme. It represents new scheme elements by parameters and specifies derivation of values based on parameters of the input template. Again, this is mostly expressed implicitly by the graphical arrangement of scheme elements. Explicit derivations can be annotated. With our approach, a transformer is easy to define because one has just to define an input scheme and an output scheme and then to annotate them in order to replace some concrete values with parameters. Moreover, these transformers are easy to understand because the templates denote examples of schemes. It is thereby intuitively clear (i) to which input schemes a transformer is applicable, and (ii) which result it will achieve. Once defined, a transformer for a particular design step can be repeatedly applied in order to have the step performed. A transformer is applied to an input scheme by binding elements of the scheme to parameters of the transformer’s input template. Thereby only a small set of parameters must be bound explicitly as the transformer can evaluate other parameter bindings due to constraint satisfaction. Each application then yields a result corresponding to the transformer’s output template. Use-cases for transformers are manyfold, supporting very small design steps as well as large ones. As transformers can be applied quickly, they facilitate everyday modelling tasks like, for example: (i) defining pages displaying the members of entity types; this will be the running example. (ii) adding content management operations like “delete” with corresponding success and error pages; this is shown in [9]. However, they can also capture complex design steps like (iii) generating a whole shopping cart application where users select products within a session.

One has just to define entity types representing concrete products and users. A series of other scheme elements can then be generated, for example: an entity type “shopping cart” representing selected products, pages enabling users to select products and to view the shopping cart, as well as content management operations for adding/removing products and submitting an order. Semantics of transformers is not specified based on schema modification operations of a particular model used for design such as WebML directly. Instead, we define a logical representation of such models that allows for precise definition of semantics and for a straight-forward implementation using a deductive engine such as FLORID [6]. Thus, transformers and the schemes to which they shall be applied are defined using a particular model/tool, yet they are mapped to logical representation before interpretation and execution. The result is then mapped back to the model in use. Our approach can therefore be applied to various models/tools in the same way. In this paper, use of transformers is demonstrated with a small subset of WebML [5], though we could have supported full extent of WebML or other approaches like OO-H [7] or Araneus [10] as well. WebML has been chosen because it is available as commercial tool, WebRatio [1], which we prototypically extended by transformers. The remainder of this paper is organized as follows. Section 2 introduces a small subset of WebML and motivates our transformers. Section 3 then defines the logical representation of this subset of WebML. Section 4 formally defines definition and application of transformers. In Sect. 5, related work is discussed before Sect. 6 concludes the paper.

2

Using a simple transformer in WebML

This section first defines a simple design step leading from a data scheme to a hypertext scheme. Thereby a subset of WebML, as far as required for this paper, is introduced informally. Then, we motivate how this design step could be performed by a transformer that will be the running example of this paper. 2.1

A simple design step in WebML

We start with defining a WebML data scheme comprising entity types and relationships as depicted in Fig. 1(a) (please ignore the gray shaded part for the moment). It describes information about artists (entity type Artist with attribute name) and albums (entity type Album with attributes title and published). The undirected relationship between artists and albums is represented by a pair of directed relationships referred to as (relationship-) roles. Roles Artist2Album (0..N) and Album2Artist (1..1) state that an artist may author any number of albums and that an album is authored by exactly one artist, respectively. The values in parentheses (e.g. (ent1)) denote IDs for model elements like entity types, attributes, etc. and are generated by WebML. Though these IDs are usually shown in separate forms, we have included them directly in the graphical representation for conciseness.

(ent1) Artist (att1) name

1..1 (rel1) Album2Artist Annotation: apply “CreateSimpleAccess” with: ↓$role2Res=rel1

(ent2) Album (att2) title (att3) published

0..N (rel2) Artist2Album

ent1 : E att3 : A name : N Album2Artist : N att1 : A rel1 : R Album : N 1..1 : Mul ent2 : E rel2 : R title : N Artist2Album : N att2 : A Artist : N published : N 0..N : Mul name (ent1) = Artist mul (rel1) = 1:1 name (att1) = name from (rel1) = ent2 definedAt (att1) = ent1 to (rel1) = ent1 name (ent2) = Album inverse (rel1) = rel2 name (att2) = title name (rel2) = Artist2Album name (att3) = published mul (rel2) = 0:N definedAt (att2) = ent2 from (rel2) = ent1 definedAt (att3) = ent2 to (rel2) = ent2 name (rel1) = Album2Artist inverse (rel2) = rel1

(a) Data scheme of album example

(c) logical representation of (a)

(page1) AlbumPage

page1 : P dau1 : U ln1 : L

(dau1) Album

(ent2) Album

(page2) ArtistPage (ln1)

(dau2) Artist

(ent1) Artist [(rel1)Album2Artist]

(b) Hypertext scheme of album example

page2 : P dau2 : U

name (page1) = AlbumPage name (dau1) = Album definedAt (dau1) = page1 source (dau1) = ent2 from (ln1) = dau1 to (ln1) = dau2

AlbumPage : N ArtistPage : N Artist : N Album : N Album2Artist : N name (page2) = ArtistPage name (dau2) = Artist definedAt (dau2) = page2 source (dau2) = ent1 selCond (dau2) = rel1

(d) logical representation of (b)

Fig. 1. Left: (a)WebML data scheme, enhanced by (b)hypertext scheme, for albums example; Right: corresponding logical representations (c) and (d), resp.

In our simple design step, the two connected entity types of the data scheme are complemented by linked pages in the hypertext scheme. The resulting hypertext scheme is depicted in Fig. 1(b) and comprises two pages AlbumPage and ArtistPage. These pages contain data units that define how to publish members of an entity type serving as source, whereby a data unit displays one member at a time. The source of unit Album is entity type Album, represented by ID ent2, and the source of unit Artist is entity type Artist, represented by ID ent1. Units may further define selectors (conditions) that identify the member that shall be displayed. This will be explained below. Units are linked for navigation. Link ln1 from unit Album to unit Artist specifies navigation from an album page to the page of its artist1 . Which particular artist will be displayed depends on the album-object displayed in unit Album at the time the link is traversed. This is referred to as a contextual link that works as follows: the current album is passed as parameter along link ln1. Unit Artist uses this parameter for evaluating its selection condition in order to determine the artist that shall be displayed. This will be the album’s artist as the selection condition refers to relationship role rel1 (i.e. Album2Artist). The next design step would then define a presentation scheme which specifies the arrangement of pages’ content and the styles to use. However, because of lim1

To keep the example simple, we abandoned an index of albums and subsequently a link to the album page.

ited space and because WebML emphasizes content and hypertext schemes [4], we will focus on these schemes as described so far, too. 2.2

An example for using a transformer

Design steps as the one explained above, leading from a scheme with two entity types connected by a 1..1 relationship role to a scheme containing two pages with linked units that refer to the entity types, will probably arise many times. It would therefore be convenient to have them performed by a transformer. For example, a transformer “CreateSimpleAccess” could be defined that automatically generates a scheme like that of Fig. 1(b) when applied to a scheme like that of Fig. 1(a). To get an impression of how a transformer is defined with our approach, the left hand side of Fig. 2 shows definition of transformer “CreateSimpleAccess”. The input template shown in Fig. 2(a) looks quite the same as the scheme in Fig. 1(a). However, the template contains annotations like the $- and the ↓$-symbols denoting implicit and explicit parameters, respectively. Further, it abstracts from whether an entity type has attributes as well as from the name of the relationship role and its inverse role. These elements are not relevant for generating the pages and linked units as required. Analogously, the output template shown in Fig. 2(b) looks quite the same as the design step’s result which is shown in Fig. 1(b). The ↑$-symbols denote scheme element construction. Transformer “CreateSimpleAccess” is applied to a scheme by properly binding elements to explicit parameters as shown in the gray shaded area of Fig. 1(a). The relationship role to be resolved, rel1, is bound to parameter ↓ $role2Res. Note that ↓ $role2Res is the only parameter that has to be bound explicitly. All other parameters are bound implicitly by the transformer. For example, parameter $tgtEnt will be bound to ent1 (i.e. entity type Artist) as this is the only entity type that is attached to the ”to”-end of relationship role rel1. The result of this application will then be the scheme of Fig. 1(b).

3

Logical representation of WebML schemes

This section defines the logical representation of WebML schemes what will be the basis for defining transformers. Note that the formalization of a subset of WebML is required for demonstration but is not the focus of this paper. In general, the logical representation of WebML-schemes comprises a set of universes Ub of scheme elements and a set of single-valued functions Fb denoting relationships among scheme elements (sets of universes or functions are marked by a b-symbol). Scheme elements are distinguished into literals and into tokens, i.e. IDs of scheme elements representing them. Correspondingly, the set of unib of token universes and a set Lit c of literal universes, verses is divided into a set E c = Ub \ E. b Each token universe E ∈ E b defines function new(E) for generating Lit new instances. For literal universes, a value stands for an instance.

The logical representation of WebML’s content model consists of following universes and functions: Entity types, their attributes, and relationship roles are represented by universes E, A, and R, respectively. The names (literal universe N ) of these elements are defined by function name : (E ∪ A ∪ R) → N . Each attribute belongs to an entity type (function definedAt : A → E) and relationship roles are attached to a source and a target entity type (functions from : R → E, to : R → E). An undirected relationship is represented by a pair of directed relationship roles that refer to one another (function inverse : R → R). Further, each role has a multiplicity (literal universe Mul = {0..1, 1..1, 0..N, 1..N} and function mul : R → Mul). The logical representation of WebML’s hypertext model consists of following universes and functions: Pages, units, and links are represented by universes P, U, and L, respectively. These elements have names (function name : (P ∪ U ∪ L) → N ). Units are components of pages (function definedAt : U → P), and links connect one unit to another unit (functions from : L → U and to : L → U). Each unit refers to its source entity type (function source : U → E) and may have a selection condition in form of a relationship role attached (function selCond : U → R). Example 1. Fig. 1(c) and (d) show the logical representations of the schemes in Fig. 1(a) and (b), respectively. A member m of a universe u is denoted as m : u. A function f relates its domain value x to its range value y and is denoted as f (x) = y. For example, function name(ent1)=Artist defines the name of entity type ent1. As WebML IDs represent scheme elements like entity types, they are directly used as tokens, e.g. ent1 : E. b F) b is represented by a set of In these terms, each WebML scheme S = (U, b c b c b universes U = Lit ∪ E with Lit = {N , Mul}, E = {E, A, R, P, L, U}, and a set of functions Fb = {name, definedAt, from, to, inverse, mul , source, selCond }. For convenience, as we often use several schemes in different contexts, e.g. a scheme denoting an input scheme, we denote the particular context as x and the bx ∪ Lit c x) scheme as Sx . We then assume corresponding sets of universes Ubx = (E and functions Fbx as defined.

4

Defining and applying transformers

This section formally defines transformers based on logical representations of schemes. We first specify how they are defined before we explain how they behave when applied to schemes. 4.1

Defining transformers

A transformer is a parameterized description of (i) a scheme to which it may be applied, and (ii) how this scheme is extended or refined by new elements that are connected to existing or new elements. The first and the second property are specified by a transformer’s input and output template, respectively.

Each template has, as usual for templates, a set of constant elements C as well as a set of variables V . Each variable represents a scheme element and denotes a parameter. Functions in templates are therefore defined over constant elements and variables. However, the semantics of constants, variables, and functions in an input template is different from that in an output template. Both templates will be explained now. An input template SIT of a transformer trans is a parameterized scheme and defines to which schemes trans can be applied. This is expressed by constraints over parameters (represented by variables) and constant elements. An input template is therefore defined with respect to a scheme Si to which the transformer will later be applied and comprises following parts: 1. a set of explicit parameters Vexpl ⊆ V , each being bound to an element of some universe u ∈ Ubi , denoted as ↓ $ : u, 2. a set of implicit parameters Vimpl = V \ Vexpl , each ranging over a universe u ∈ Ubi , denoted as $ : u, and 3. a set of constraints over variables and constant elements denoted either (i) as v1 op (v2 | c), whereby | denotes a BNF-symbol separating alternatives, op ∈ {=, 6=}, v1 , v2 ∈ V , and c ∈ C, or (ii) as f (x1 , . . . , xn−1 ) = xn , for i = 1..n, xi ∈ (V ∪ C), f ∈ FbIT . Example 2. Fig. 2(c) shows the input template of transformer “CreateSimpleAccess”, illustrated by depicting constraints and members of Vexpl , Vimpl , and C in sections named correspondingly. Constraint name($srcEnt) = $srcEntN restricts bindings of ($srcEnt, $srcEntN) to those pairs of values (e ∈ Ei , n ∈ Ni ) where a function namei (e) = n is defined; constraint $srcEnt 6= $tgtEnt states that the source and the target entity must be different. In WebML, implicit parameters are denoted by symbol $ preceding the scheme element’s ID or literal value, explicit parameters additionally are preceded by symbol ↓. Constraints of the form f (x1 , . . . , xn−1 ) = xn are expressed implicitly by functions defined by the graphical arrangement of elements. Constraints of the form v1 op (v2 | c) are annotated in comment fields and are extracted during the mapping to the logical representation of the template. Example 3. Fig. 2(a) shows an input template and Fig. 2(c) its logical representation. The annotated constraint $srcEnt 6= $tgtEnt has been taken over. The constraint name($srcEnt) = $srcEntN is implicitly defined by treating the corresponding function name($srcEnt) = $srcEntN as constraint. Output Template An output template SOT is a parameterized description of new elements to be generated and of new connections between elements to be established and comprises following parts: bG ∪ Lit c G of universes for generated elements, and a set of 1. a set UbG = E new-element variables Vg ⊆ V for elements of a universe u ∈ UbG , denoted as ↑ $ : u,

($srcEnt) $srcEntN

1..1 (↓$role2Res)

Annotation: $srcEnt ≠ $tgtEnt

($tgtEnt) $tgtEntN

(a) input template of transformer ‘‘CreateSimpleAccess’’ (↑$srcP) ↑$srcPN

(↑$tgtP) ↑$tgtPN

(↑$sdu $srcEntN (↑$ln)

($srcEnt)

(↑$tdu) $tgtEntN

($tgtEnt) [($role2Res)]

Annotations: let ↑$srcPN = $srcEntN + “Page” let ↑$tgtPN = $tgtEntN + “Page” (b) output template of transformer ‘‘CreateSimpleAccess’’

Vexpl

Vimpl

↓$role2Res : R $srcEnt : E $srcEntN : N

C $tgtEnt : E 1..1 : Mul $tgtEntN : N

Constraints name ($srcEnt) = $srcEntN name ($tgtEnt) = $tgtEntN mul (↓$role2Res) = 1:1

from (↓$role2Res) = $tgtEnt to (↓$role2Res) = $srcEnt $srcEnt ≠ $tgtEnt

(c) input template interpretation of (a) Vpar ∪ C

Vg (literals)

Vg (tokens)

let ↑$srcP =new(P) $srcEnt : E let ↑$srcPN = $srcEntN : N strcat ($srcEntN, Page) let ↑$sdu =new(Ud) let ↑$ln =new(L) $tgtEnt : E let ↑$tgtPN = $tgtEntN : N strcat ($tgtEntN, Page) let ↑$tgtP =new(P) let ↑$tdu =new (Ud) Page : N

Assignment statements let name (↑$srcP) = ↑$srcPN let name (↑$sdu) = $srcEntN let definedAt (↑$sdu) = ↑$srcP let source (↑$sdu) = $srcEnt let from (↑$ln) = ↑$sdu let to (↑$ln) = ↑$tdu

let name (↑$tgtP) = ↑$tgtPN let name (↑$tdu) = $tgtEntN let definedAt (↑$tdu) = ↑$tgtP let source (↑$tdu) = $srcEnt let selCond (↑$tdu) = $role2Res

(d) output template interpretation of (b)

Fig. 2. (a) WebML input template and (b) output template for transformer “CreateSimpleAccess”, correspondingly interpreted logical representations (c) and (d), resp.

2. a set of parameters Vpar = V \ Vg representing those explicit and implicit parameters that will be bound by the input template, denoted as $ : u, u ∈ UbOT , 3. a set of construction expressions for assigning values to each new-element bG , the variable vg ∈ Vg . If vg represents an element of some universe u ∈ E expression has the form let vg := new (u). Otherwise, vg represents a literal and the expression has the form let vg := exp(x1 , . . . , xn ), whereby exp denotes an operation defined over particular universes2 and for i = 1..n, xi ∈ (Vpar ∪ C), and 4. a set FbG of generated functions and a set of assignment statements, each defining the range value of a function fg ∈ FbG for a particular domain value. This is denoted as let f (x1 , . . . , xn−1 ) = xn , for i = 1..n, xi ∈ (V ∪ C), f ∈ FbG . Example 4. Fig. 2(d) depicts the output template of transformer “CreateSimpleAccess”. Members of Vpar and C are shown in section “Vpar ∪ C”, literal and element constructions in “Vg (literals)” and “Vg (tokens)”, respectively. Assignment statements are shown in section “Assignment statements”. Literal construction let ↑ $srcPN = strcat($srcEntN, Page) denotes the call of model-dependent operation strcat concatenating two values of sort N . Assign2

Note that we do not provide predefined operations for exp as they are modeldependent. For example, operation strcat(N , N ) : N concatenating two names is defined for WebML in particular.

ment statement let source(↑ $tdu) = $tgtP lets the generated unit ↑ $tdu refer to entity type $tgtP that is provided as parameter by the input template. In WebML, parameters are denoted by symbol $ preceding the scheme element’s ID or literal value, new-element variables additionally are preceded by symbol ↑. For each token element that is represented by a new-element variable, element constructions are denoted implicitly. Assignment statements are again denoted implicitly due to the graphical arrangement of scheme elements. Literal constructions are annotated explicitly. Example 5. Fig. 2(b) depicts the output template of transformer “CreateSimpleAccess” in WebML. It should be self-explanatory as its logical representation is depicted to the right in Fig. 2(d). 4.2

Applying transformers

A transformer trans is applied to a concrete scheme Sc by binding elements ei ∈ Ubc , i = 1..n, to explicit parameters of trans and is denoted as trans(Sc , vexpl 1 = e1 , . . . , vexpl n = en ). Such an application is valid, if (i) each explicit parameter is bound to an element of its type and (ii) a unique binding of implicit parameters exists such that all constraints defined by trans are satisfied. Example 6. If transformer “CreateSimpleAccess” shown in Fig. 2(c) and (d) were applied to the scheme shown in Fig. 1(c) with relationship role rel2 bound to explicit parameter ↓ $role2Res, the application would be invalid as constraint mul (↓ $role2Res) = 1..1 would be violated. In WebML, an application of a transformer is explicitly annotated and specifies the name of the transformer and the explicit parameter bindings. Example 7. The gray shaded area of Fig. 1(a) specifies to apply transformer “CreateSimpeAccess” and binds relationship role rel1 to ↓ $role2Res. This application is valid. Implicit parameter $srcEnt is bound to entity ent2 as this is the only element of universe Ec ∈ Ubc fulfilling constraint from(↓ $role2Res) = $srcEnt. Similarly, by evaluating all constraints, the transformer determines following bindings: $srcEntN = Album, $tgtEnt = ent1, and $tgtEntN = Artist. A valid application of transformer trans to scheme Si generates new elements for each v ∈ Vg and function assignments for each fg ∈ FbG yielding a schemefragment Sg = (Ubg , Fbg ). Merging fragment Sg with Si leads to the resulting scheme So . The merge is defined as follows: (1) for each kind of universe U , Uo := Ui ∪ Ug , and (2) for each kind of model function F , Fo := Fi ∪ Fg . Example 8. Based on example 7, variable ↑ $srcPN is assigned value “AlbumPage”, variable ↑ $srcP is assigned a new element p of universe Pg , and the name of p is defined by function name(p) = AlbumPage. Unifying the set of all new elements and function assignments with the corresponding sets in Si then yields the schemes depicted on the right hand side of Fig. 1. This logical representation then is mapped to the WebML-representation and leads to the schemes depicted on the left hand side of Fig. 1.

5

Related work

This section describes approaches that partly have either motivation or realization common with transformers by example. Approaches closest to our’s are explained first. Transformation rules described in [8] define transformers by specifying a sequence of schema modification operations. This requires to understand operations like, for example, an expression “addAPDPage (p)” for creating a new page. In contrast, our approach is based on parameterized examples from which schema modification operations can be generated. However, iterative element construction as supported by transformation rules of [8] is not yet supported by our approach, although this is a problem of limited space rather than one of limited concept. Therefore, we cannot yet define a transformer that, for example, automatically collects all entity types of a scheme and generates a page class for each of them. Visual query systems (VQS, surveyed in [3]) are graphical interfaces to databases. Some of them, e.g. QBE [14] and GQL [12], denote a query by specifying an example of the desired result. Their motivation is comparable to that of input templates. However, input templates offer (and require) less expressive power than query systems: in contrast to queries which yield a set of result tuples, input templates as described in this paper only yield one tuple, i.e. one unique binding of scheme elements. This allowed for precisely defining transformers’ semantics, whereas a fully fledged query system would have gone beyond the scope of this paper. Generic schema management as described in [2] provides a general and formal framework for specifying schema modification operations, and we could have used this framework for explaining our transformer’s semantics. However, in our logical representation of schemes, there are only two sorts of schema modification operations, i.e. “generate new token” and “generate function instance”. Therefore, for defining our transformer’s semantics, the formal framework would have required much more explanation than reasonable.

6

Conclusion

We have presented a way for defining web schema transformers by example. As they are specified with the same model/tool as used for defining schemes, definition of transformers does not require to understand or define a sequence of various schema modification operations. Instead, a small set of generic constructs, which are denoted by annotating scheme elements, is sufficient to define and apply transformers. Modelers can therefore easily just use a repertoire of transformers, but they can also easily define their own transformers for various modelling tasks they perform repeatedly. This has been demonstrated on a use-case specified in WebML. Semantics of transformers has been defined precisely with a logical representation of schemes independently of a particular model such as WebML. Therefore, enabling transformers in a particular model only requires (i) to define a

universe for each different sort of the model’s elements and (ii) to define a function for each different sort of relations among these elements. This has again been demonstrated with WebML. The paper has focused on transformers for supporting design steps. Beside that, transformers could be beneficially used for generating hypertext views that adapt a base web application for particular front end devices. Similarly, transformers could also be used for generating personalized views for particular user groups on the fly. Describing these topics as well as improving expressive power of transformers to capture iterative construction of scheme elements will be subject of further work.

Acknowledgement We are grateful for many helpful comments from G¨ unter Preuner, Mathias Goller, Anne Hoffmann, and the anonymous referees.

References 1. WebRatio Site Development Studio, Vers. 3.0.7. http://www.webratio.com, 2002. 2. Suad Alagi´c and Philip A. Bernstein. A model theory for generic schema management. Lecture Notes in Computer Science, 2397:228–239, 2002. 3. T. Catarci, M.F. Costabile, S. Levialdi, and C. Batini. Visual query systems for databases: A survey. Journal of Visual Languages and Computing, 8(2), 1997. 4. S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, and M. Matera. Designing Data-Intensive Web Applications. Morgan Kaufmann, 2003. 5. Stefano Ceri, Piero Fraternali, and Aldo Bongio. Web Modeling Language (WebML): a modeling language for designing Web sites. Computer Networks (Amsterdam, Netherlands: 1999), 33(1–6):137–157, 2000. 6. J. Frohn, R. Himmer¨ oder, P. Kandzia, G. Lausen, and C. Schlepphorst. FLORID: A prototype for F-logic. In ICDE’97, pages 583–. IEEE, April 1997. 7. Jaime G´ omez, Cristina Cachero, and Oscar Pastor. Extending a conceptual modelling approach to web application design. In CAiSE’00, pages 79–93, 2000. 8. Jaime G´ omez, Cristina Cachero, and Oscar Pastor. Conceptual modeling of deviceindependent Web applications. IEEE MultiMedia, 8(2):26–39, April 2001. 9. S. Lechner and M. Schrefl. By-example schema transformers for supporting the process of conceptual web application modelling. Technical Report TR0301, University of Linz, Austria, 2003. 10. G. Mecca, P. Atzeni, A. Masci, G. Sindoni, and P. Merialdo. The araneus webbased management system. In ACM SIGMOD’98, pages 544–546, 1998. 11. Marc Nanard, Jocelyne Nanard, and Paul Kahn. Pushing reuse in hypermedia design: golden rules, design patterns and constructive templates. In 9th ACM conference on Hypertext and hypermedia, pages 11–20. ACM Press, 1998. 12. Anthony Papantonakis and Peter J. H. King. Gql, a declarative graphical query language based on the functional data model. In Proceedings of the workshop on Advanced visual interfaces, pages 113–122. ACM Press, 1994. 13. Daniel Schwabe and Gustavo Rossi. An object oriented approach to web-based application design. Theory and Practice of Object Systems, 4(4), 1998. 14. M. M. Zloof. Query-by-example: A database language. IBM System Journal, 16(4):324–343, 1977.