The PlumbingXJ Approach for Fast Prototyping of Web Applications

1 Introduction

The use of markup technologies to develop hypermedia applications, and more specifically to develop hypermedia Web applications, is not new. The most successful language for the development of hypermedia Web applications has been HTML (W3C 1999a), an SGML-based (ISO 1986) language. HTML is the most commonly used markup language probably due to its simplicity. But this simplicity is also responsible for the lack of structure of the informational content of most Web sites (Sperberg-McQueen and Goldstein 1994), one of the major shortcomings of HTML. This shortcoming has prompted the appearance of several markup-based languages in the Web domain.

Hypermedia/Time-based Structuring Language (HyTime) (ISO 1992) is a powerful SGML-based standard for the characterisation of hypermedia applications. However, the lack of a clear semantics in all its modules, and its huge size, handicapped the success of HyTime. Synchronized Multimedia Integration Language (SMIL) (W3C 2001a) is a markup language mainly centred on the multimedia domain. SMIL is a powerful language for the description of multimedia applications, but it forces the definition of the links of the application within the description of the user interface of the application. This characteristic could lead to reusability problems with the contents and their navigational interpretation. Notwithstanding this, SMIL is simpler and semantically clearer than HyTime because it has been built using the semantics of the Amsterdam Hypermedia Model (Hardman et al. 1994). The Web Modeling Language (WebML) (Ceri et al. 2000) is a successful language for Web development. WebML provides a model based on the work of Garzotto et al. (1993), Isakowitz et al. (1995), Schwabe et al. (1996) and, like SMIL, an XML (W3C 2004) representation of the primitives of this model provides access to the data stored in a relational database. Although valuable in relational domains, as in the case of approaches such as RMM (Isakowitz et al. 1995), this characteristic makes the use of WebML difficult in domains with irregular structure where the application is focused on relations (or links) established between heterogeneous pieces of information (Thüring et al. 1995).

The XML Linking Language (XLink) (W3C 2001b), and the XML Pointer Language (XPointer) (W3C 2001c) are also standards used in Web development, but they are not powerful enough to describe a hypermedia application entirely. Finally, other approaches like User Interface Markup Language (UIML) (UIML 2002) and the XML-based User interface Language (XUL) (Deakin 2003) are centred on the description of graphical user interfaces (GUIs) of generic applications, requiring a serious effort to apply them in the hypermedia domain.

Our approach tries to combine some of the key benefits of these markup technologies while avoiding most of their shortcomings. Moreover, our approach is strictly centred on the prototyping stage, and not on the development stage, as with the approaches described above. We know that most of these markup technologies are broadly used, and our approach does not try to replace them. It provides another solution to the problem of developing a hypermedia Web application.

This paper presents our work, driven by the Pipe model. We introduce the Fraternali/Ginige-Lowe process model, the basis of Plumbing, our general approach for the development of hypermedia applications. Later we present PlumbingXJ, the process model that uses XML and Java to build prototypes of hypermedia Web applications. We also present an example to illustrate the main concepts.

2 The Pipe model

The Pipe model uses three diagrams to characterize hypermedia applications:

• The contents graph models the contents and semantic relationships of the application, totally independently of its navigational treatment. Note that these semantic relationships are the basis of the links of the applications. Consequently, throughout the paper we also call them content links.

• The navigational schema models the elements of the GUI and the navigational relationships established among them.

• The canalisation functions relate the contents graph and the navigational schema.

Although these diagrams have a mathematical formalisation (Navarro et al. 2004), this paper omits such a formalisation and focuses only on the visual presentation of Pipe.

2.1 Contents graph diagram

The Pipe model uses the elements shown in Figure 1 to represent the contents and relationships in hypermedia applications.

Figure 2 depicts the contents graph diagram inspired in part by the contents of Galatea, an educational hypermedia application for the comprehension of Romance languages (Fernández-Valmayor et al. 1999). Figure 2 shows part of the Pipe characterisation of the contents graph for the Galatea contextual dictionary, in which the learner can select any sentence from a text to check the contextual meaning of any word in that sentence, including the relationships with surrounding words. In addition, the text is also linked to a short description of the text. This short description is linked to an extended description. Both descriptions are linked to the original text. For the sake of conciseness, the example is focussed on a text from the dictionary, specifically, an article about a fire in an apartment.

In Galatea, dynamic content and anchors are generated when a student looks up a term up in the general dictionary. Galatea's general dictionary contains all the words and expressions in the static contextual dictionary of each text. The definition of every word is obtained by filtering the definitions and grammatical descriptions of the words that are used in similar frame sentences with the same semantic or functional value. The first page of the general dictionary has an index (in this case static) with all the letters of the alphabet. Every letter is linked to a page that contains all the words beginning with the selected letter in the static index. As we have explained, these pages with the words beginning by the same letter are dynamically generated by processing and filtering all the static contextual dictionaries associated with texts that have been incorporated into the Galatea application up to that moment. Finally, the general meaning of a word appears when such as word is selected. Figure 3 shows the contents graph for the general dictionary.

 Note that the Pipe notation does not reflect the inner structure of the contents (e.g. graphics vs texts). The designers can use their own notations (if any) to characterize the inner structure of the contents. Regarding the formal characterisation of the generation of dynamic contents (Bodner and Chignell 1999), the Pipe model uses the generation function g (Navarro et al. 2004). This function acts as an interface that dynamically builds the information generated after an anchor selection. The Pipe model only defines the signature of the generation function, and every concrete model for a concrete application must provide the definition of this function (in our case, the function that looks up and filters the contextual dictionary of texts). In this way, the generation function acts as an interface in the object-oriented sense: only the description of the behaviour is provided, while the concrete behaviour of the function is defined in every case. A formalism for defining the implementation of this function is not provided by the Pipe model. Standard mechanisms, such as UML interaction diagrams (Booch et al. 1999), can be used.

2.2 Navigational schema diagram

The Pipe navigational schema represents the elements of a basic GUI and the navigational relationships established by and among the elements of such an interface.

The navigation is not exactly the same as the interface, but in the end the navigation has to be represented in a user interface. For example, OOHDM (Schwabe et al. 1996) uses a navigation chart to describe the behaviour of the nodes when a link is traversed. The Pipe navigational schema defines the minimum elements of a user interface, and the canalisation functions relate contents to their navigational access. This is similar to the OOHDM navigation chart. The main difference is that in OOHDM a context schema and context classes are needed because the access between objects may vary depending on the relationships and the classes accessed, and in Pipe the only relationship is the navigational relationship between elements.

Three elements in the Pipe navigational schema represent windows, panes inside these windows, and buttons, also inside these windows. In addition, there are four allowable relationships between these elements. A connection represents an aggregation relationship between a window and its panes and buttons. A synchro connection represents a time-activated connection. A path between two elements of the user interface represents a navigational connection from the source to the destination. A synchro path is a time-activated path.

Figure 4 shows the elements of the notation and the allowable relationships between these elements. Note that in Pipe, the windows are called nexus nodes, the panes are called container nodes ¹ and the buttons are called nexus activator nodes.

 In the example of the contextual dictionary, the article, sentences and words appear in a window (the nexus node x₁), and the descriptions of the article appear in another window (the nexus node x₂). The first window (x₁) has three panes (the container nodes c_1.1, c_1.2 and c_1.3) and two buttons that activate two different buttons (the nexus activators a_1.1 and a_1.2). The first pane c_1.1 has a navigational path (or pipe) with the second one (c_1.2), and the second pane has another navigational path with the last one (c_1.3). The second window has two panes (the container nodes c_2.1 and c_2.2) and two buttons (the nexus activators a_2.1 and a_2.2). Moreover, the first pane of the first window (c_1.1) has a navigational path with the first pane of the second window (c_2.1), and both panes in the second window (c_2.1 and c_2.2) have a navigational path with the first pane of the first window (c_1.1). Finally, the first pane of the second window (c_2.1) has a navigational path with the second pane of the second window (c_2.2). Figure 5 depicts this navigational schema, and Figure 6 shows the actual user interface.

2.3 Canalisation functions

Pipe has two canalisation functions that relate the contents graph and the navigational schema:

• The content assignation function that assigns contents to the container nodes of the navigational schema.

• The canalisation function that assigns content links to navigational paths of the navigational schema. In this way the content links are interpreted in the GUI.

The canalisation function diagram relates the contents graph and navigational schema diagrams using patterns and colours. Using these visual elements, contents and relationships of the contents graph are assigned to panes and pipes in the navigational schema. In this way, the model provides information about the navigational interpretation of the contents graph.

Continuing with the Galatea static example, the content assignation function states that the content article is the default content (that is, the content shown when the window is activated) for the first pane (c_1.1) of the first window. The sentences selected from this article will appear in the second pane (c_1.2). Hence the canalisation of these content links by the pipe between c_1.1 and c_1.2. The contextual meaning of every word selected from a sentence will appear in the third pane (c_1.3). Hence the canalisation of these content links by the pipe between c_1.2 and c_1.3. When the user selects the short description of the article, it appears in the first pane of the second window (c_2.1). Hence the canalisation of the content link by the pipe between c_1.1 and c_2.1. When the user selects the extended description, it appears in the second pane of the second window (c_2.2). Hence the canalisation of the content link by the pipe that connects (c_2.1) and (c_2.2). Finally if the user selects some of the back links from the descriptions to the article, the article appears in the first pane of the first window (c_1.1). Hence these returning content links are canalised by the pipes that connect the panes in the second window (c_2.1, c_2.2) with the first pane in the first window (c_1.1). Nexus activator nodes provide access to other windows that are not considered here. Figure 7 shows the relationships between the navigational schema and the contents graph (omitting some information).

Note how the colours and patterns denote the canalisation. The patterns denote the assignation of contents to container nodes, while colours provide information about the canalisation of links by pipes. Note that in this example we have chosen the static dictionary, but using of the general dictionary has the same complexity (once some auxiliary functions have been introduced) due to the definition of the Pipe browsing semantics.

The independent characterisation of the application using the contents graph diagram and the navigational schema diagram permits changes in any of the two components of the application without affecting the other; only the canalisation functions diagram must be changed. This is a very important feature in prototyping environments where changes can appear constantly in any component of the application (Nanard et al. 1995). Moreover, note that the representation provided is abstract enough not to impose constraints at the design stage.

2.4 Default browsing semantics

The Browsing Semantics represent the dynamic appearance of the application, according to the interaction with the user. There are two functions

• a is the activation function. This function provides information on the application behaviour after the activation of a nexus node (i.e. a window).

• f is the link activation function. This function is basically for providing information on the application behaviour after the activation of a content link.

These functions act on nodes and anchors providing the state of the application, which is described by the following sets:

• Actives that represents the set of active nodes with their associated timing information.

• Show that represents the contents that every container node shows (or plays) with their associated timing information.

The details regarding the definition of functions a and f are omitted, as we prefer to give an idea of their functionality instead. Function a describes the behaviour of the system after the activation of a nexus node (a window). All the nodes connected to the activated nexus node are triggered according to their attached timing information. Moreover, the container nodes show their default content.

The function f acts on a content and an anchor inside the content that is being displayed in a container node, or on a navigational path in a nexus node, changing the state of the application (i.e., the sets Actives and Show). The definition of the function takes into account four main cases:

• a. Function f is activated by the selection of an anchor that activates a content link. Then, the source is in a container node, and the destination contents are in other container nodes. There are two options depending on whether the source and container nodes are not connected to the same nexus node (i.e. they are panes of different windows) or they are connected to the same nexus node (i.e. they are panes of the same window).

• • a.1. The destination content nodes are in another nexus node. In this case, the nexus node where the link originated is deactivated. Then the nexus node connected to the container nodes, which are the destination of the pipes, is activated. Next, all the container nodes show their default content, except those nodes that are the destination of the pipes. These nodes show the accessed contents by the link.

  • a.2. The destination content nodes are in the same nexus node. In this case, every destination container node of a pipe that canalises an activated link shows the content (static or dynamic) accessed by the link and stops showing the previous content.

• b. Function f is activated by the triggering of a synchro path established between two nexus nodes In this case, the destination nexus node is activated according to the timing information attached, and the source nexus node is deactivated.

• c. Function f is activated by the selection of a nexus activator node belonging to the navigational schema. In this case, the destination nexus node is activated, and the nexus node where the source nexus activator node is placed is deactivated.

• d. In other situations, function f acts as the identity function.

We are aware that this browsing semantics (and its mathematical representation) is too complicated to be clearly understood by a broad audience, but this is not our main aim. The Pipe browsing semantics is used to define a tool that can handle a hypermedia application by using Pipe structures. In other words, this browsing semantics is the kernel of a hypermedia system for the development of hypermedia applications.

Regarding some hypermedia-oriented models used for the characterisation of hypermedia applications such as OOHDM, RMM or WebML, the main difference is that Pipe is focused on the descriptions of applications with irregular domains where the application is focused on relations (or links) established between heterogeneous pieces of information (Thüring et al. 1995). In contrast, OOHDM, RMM and WebML are focused on applications with domains easily representable in terms of class/entities and relationships. Moreover, Pipe presents an explicit relationship between contents and user interface and provides a default browsing semantics. For a more in depth comparison between Pipe and these other hypermedia-oriented models see Navarro et al. (2004).

3 Fraternali/Ginige-Lowe process model

The use of software engineering techniques is essential for the development of hypermedia applications (Murugesan et al. 1999). Our process model is primarily based on the Fraternal process model (Fraternali 1999) with a few characteristics of the Ginige-Lowe process model as well (Wills et al. 1998) ² . Figure 8 shows the Fraternali/Ginige-Lowe process model, a process with two loops.

The first loop begins with a requirements analysis, in which developers determine the mission of the software application, identifying prospective users and defining the nature of its information base. Later, in conceptualisation, the application is represented through a set of abstract models that characterize the main features of the application: structure, navigation and presentation. In prototyping and validation the user evaluates reduced versions of the application using a prototype that simplifies the architecture of the solution. The user's evaluation provides valuable information prior to design. In the case of hypermedia applications, the prototyping has more relevance than in traditional software development because the complexity of the contents and the GUI are greater than in other applications and also need to be evaluated in detail by the user. At the design stage, developers transform the abstract schemas provided by the conceptualisation phase into lower-level representations, closer to the demands of the implementation. Also at this point, developers determine the architecture of the solution, for example using patterns like those provided by Rossi et al. (1999b). Developers build the application and provide the contents at the implementation stage. Naturally, the contents must be represented according to the selected architecture. Finally, in evolution and maintenance, developers modify the application in response to changes in software requirements, and solve the bugs and problems that might eventually appear in the application. These changes may force modifications in the structure, navigation or presentation of the application, and for that reason is best managed by a recursive application of the process model.

4 Plumbing

Plumbing

(Navarro et al. 2002) is a specialisation of the Fraternali/Ginige-Lowe process model where the conceptualisation-prototyping loop is guided by the Pipe model. Figure 9 depicts the information generated in the Plumbing process model.

 The description of the Pipe contents graph of the conceptualisation stage is split into two parts at the prototyping stage. The first part, dynamic linking in the application, represents all the contents and links of the application that must be dynamically generated (this dynamic process is represented in Pipe by the generation function g). The second part, contents and links of the application, represents all the static contents and links identified and established by the designers of the application. Note that in a most general and interesting case, both parts are needed to characterise a hypermedia application completely.

4.1 Requirements analysis and conceptualisation

The requirements analysis phase does not differ from Fraternali's, but in Plumbing the conceptualisation stage is totally directed by Pipe. The conceptualisation stage needs mechanisms with the capacity to express the contents, links and navigational schema of a hypermedia application in an abstract way. In our approach, Pipe provides all the mechanisms for representing this information. According to Plumbing, at the conceptualisation stage developers must identify the contents graph of the application. Once the contents and their relationships are defined, developers must specify the navigational schema of the application. After specifying the navigational schema, developers must relate the contents graph to the navigational schema by defining the canalisation functions. They can choose to define these functions at the same stage as the navigational schema, or at an independent stage. Figure 9 depicts them as independent activities in order to obtain a more general approach. Note that at the end of the conceptualisation stage we have a complete Pipe representation of the application.

4.2 Prototyping and validation

At this stage the user must validate the application that is being developed. The idea is to reuse the Pipe representation defined during the previous phase. Therefore several languages or formalisms capable of expressing all the Pipe structures are needed. The first must be capable of structuring the static part of the contents graph. The second must be capable of structuring the dynamic part of the contents graph. The third must be capable of structuring the navigational schema. With these formalisms available, all the contents, links and abstracts features of the application GUI can be described. Finally, another formalism must be used to relate both aspects of the application (as canalisation functions do), obtaining the description of the whole application.

This description of the application must be capable of being processed by a program that implements the Pipe browsing semantics, providing a prototype of the final application. This program should be integrated into a computer-aided software engineering (CASE) tool able to generate the navigational schema and its relationships with the contents graph. Of course, the formalisms used must be in tune with the design and development phase, or must be flexible enough to be employed in a wide range of domains. In any case, a first ultra-fast prototype can be deployed using the Pipe representation of the application. In this prototype the structural information provided by the contents graph can be used as an abstract representation of the actual contents of the application. This helps in defining the hypermedia structure of the contents and their navigational behaviour.

Customers evaluate the prototype developed at the final stage, and the loop iterates if changes are required. The presence of the Pipe representation and the prototyping engine facilitates the iteration until the prototype needs no further changes. For the prototyping phase, the Plumbing process model does not set any specific structuring language or formalism, and consequently does not imply any technology in the generation of prototypes. Although this is the true nature of a process model, we are going to set up some mechanisms and languages to make the Plumbing process model more functional.

5 PlumbingXJ

PlumbingXJ

(Navarro et al. 2002) is a specialisation of Plumbing where XML and Java are the selected mechanisms for encoding the structure of the contents graph, the navigational schema and the canalisation functions that describe the application, and where a Java tool generates the prototypes automatically (hence the XJ). Figure 10 describes the information generated in PlumbingXJ. Note that the only changes appear at the prototyping stage, and as in Plumbing, PlumbingXJ is mainly centred on the conceptualisation and prototyping stage.

There are several reasons for choosing XML to describe the application at the prototyping stage. Regarding contents (Navarro et al. 2001, Sperberg-McQueen and Goldstein 1994):

1. XML permits the domain to be structured in a human-readable way

2. the documents structured in XML can be reused in several applications

3. XML provides platform independence.

Regarding the user interface (Navarro et al. 2001):

1. the application DTD captures the restrictions in Pipe to create user interfaces (i.e. a pane cannot be inside a button) in a human readable way

2. provides platform independence

Regarding the dynamic linking and the computational machinery described in Plumbing, Java is a powerful and platform-independent language (Gosling and McGilton 1996).

In relation to the available XML schema languages (van der Vlist 2001), XML DTDs (W3C 1999b) and XML Schemas (W3C 2000) are the standard ³ schemas from the World Wide Web Consortium. In PlumbingXJ we have used XML DTDs instead of XML schemas because DTDs are simpler than schemas (Vlist 2001), and this feature leads to better readability. Consequently, contents DTDs are simpler to define and to use, and an application DTD is simpler to use. Note that in any application that makes uses of XML documents, the presence of XML DTDs or XML schemas does not affect the use of the generated documents according to these schema languages beyond the document validation.

5.1 Contents DTD and g-class

The contents DTD defines the markup language that structures the informational contents and links of a specific hypermedia application: it structures the static linking in the Pipe contents graph. Due to the heterogeneous structure of the contents that can appear in a hypermedia application, the DTD is specific to each case.

The contents document is an instance of the contents DTD and represents the contents and links of the hypermedia application (i.e. it encodes the static linking in the Pipe contents graph). It can include text and non-XML data like images or subordinate processes. Subordinate processes are small applications running inside the hypermedia application without affecting the navigation. Subordinate processes implement a specific Java interface that allows the hypermedia applications to load them dynamically when referenced.

Regarding the Galatea example, Figure 11 shows part of the instance of the contents document for the Galatea contextual dictionary. This document has been generated taking into account the linking information provided by the Pipe contents graph of Figure 2. In XML, the linking is made explicit using href/id attributes.

 In this example, the element with href="s1" refers to the element with id="s1". We have chosen href attributes to define the destination of a source anchor. Although similar to links in HTML, this choice is not relevant to our approach. Indeed, the inline inclusion of the anchors is an implementation decision that can be (effortlessly) replaced by external XLink links. Note that although in the contents DTD there are no restrictions in the structure of the contents document, some selected attributes need to be included to specify the processing of this document in order to generate the hypermedia application (e.g. the href attribute).

In PlumbingXJ the dynamic linking is implemented according to the Pipe model. This dynamic generation of contents and links is implemented by the g-class, a precompiled Java class that implements a predefined Java interface, the g-class interface. Thanks to the Pipe characterisation identified at the conceptualisation stage, the g-class can provide the dynamic linking of the application (i.e. the g-class encodes the dynamic part of the Pipe contents graph, represented in the conceptualisation stage by the Pipe generation function g). In this way the anchors in the contents document do not include any reference to any function. Consequently, the anchors that activate the dynamic linking must identify univocally their treatment by the g-class. In other words, in Pipe the anchors are the input of a function, i.e. the same anchor cannot have two different interpretations. PlumbingXJ follows this philosophy that permits changes in the dynamic linking of the application without changes in the contents document.

Figure 12 shows part of the instance of the contents document for the Galatea general dictionary. This document has been generated taking into account the linking information provided by the Pipe contents graph of Figure 3.

In this case the value of the href attribute in the letterIndex does not reference to any ID attribute in the contents document. These anchors are processed by the g-class, which looks up and filters the contextual dictionary of texts and generates the results. Note that in this way the dynamic linking in the application can be changed without modifying the contents document. Only the g-class has to be changed.

5.2 Application DTD

The application DTD defines the language that describes and structures the GUI of hypermedia applications, and therefore it structures the Pipe navigational schema. Using the XML structural description of the application DTDs, the Pipe structural constraints can be described (i.e. it is not possible to have a pane inside a button). The application DTD is unique for every application and uses a terminology more closely related to GUI terminology than to the Pipe vocabulary. This approach is similar to the one presented in Deakin (2003) and UIML (2002), but restricted to the hypermedia domain and to the Pipe browsing semantics. Consequently there is no need to express the behaviour of the application explicitly beyond the anchor selection, which is encoded in the Java engine that builds the prototypes.

The application document is an instance of this DTD and provides not only the elements of the GUI and their navigational relationships, but also encodes the canalisation functions that relate these GUI elements to the contents of the hypermedia application (i.e. it represents the Pipe navigational schema and Pipe canalisation functions). The overmarkup technique and several element attributes that implement canalisation are responsible for establishing the relationship between the application document and the contents document. In this way Pipe canalisation functions are implemented in PlumbingXJ.

The key idea behind overmarkup is quite simple and extremely useful. The actual contents of the XML elements of the application document are XPath (W3C 1999b) references to the contents document. These references select the contents that must appear in every pane. Figure 13 depicts a fragment of the applications document for the Galatea contextual dictionary (bold text represents overmarkup). Regarding canalisation, the value of the href attribute in the contents document (Figure 11) represents the destination content (in the source anchor) of the content link, while the element linksDestination in the application document (in italics in Figure 13) canalises the content links into the navigational level. This canalisation provides information about the pane in which the destination of a content link must appear (i.e. this is similar to the HTML attribute target of the HTML element a, but in our approach the information is defined only at the navigational level). In this way, if the user selects the anchor with href="s1" in the article (Figure 11), the destination of this link (the sentence with id="s1") will appear in the pane with id="p1.2", because the article (a GIF file) appears in the pane with id="p1.1" (Figure 13), and the content links of the article are canalised by the pipe defined by the linksDestination element between the pane with id="p1.1" and the pane with id="p1.2".

In this case, the application document of Figure 13 is the PlumbingXJ representation of the Pipe navigational schema of Figure 5, and Pipe canalisation functions of Figure 7. Note that instead of using the terms nexus nodes and container nodes, in PlumbingXJ the terms windows and panes are used instead.

The Java application Automatic Prototypes Generator (APG) processes the application document, the contents documents and the Java g-class and produces the desired prototype shown in Figure 14. The navigational schema of the application is generated by the APG from the application document. This schema is a Java Swing skeleton that supports the GUI of the application. The contents that appear in this Java Swing skeleton are HTML pages generated by the APG from the contents document and the XPath expressions that appear in the application document. An XSLT transformation (W3C 1999c) produces the transition from XML to HTML. This transformation is always the same and uses the hypermedia structure encoded in the contents document via several selected attributes (e.g. the href attribute). In this way the contents document can be structured in any desired way because the XSLT transformation only needs a few attributes to produce the HTML pages. This is similar to the concept of Architectural Form processing presented by HyTime. Finally, the behaviour of the application is provided by an event controller that implements Pipe browsing semantics via a Java Swing HyperlinkListener  taking into account the g-class (if necessary). Naturally non-XML data, like figures and subordinate processes, can be referenced from the contents document. In particular, subordinate processes are implemented by Java classes that are dynamically loaded by the application.

The separation of layers allows for fast generation of prototypes where modular changes can be made in the navigational schema, in the content level or in the dynamic behaviour of the application. The construction of the navigational schema and its relationships with the contents can be done manually, or via a CASE tool. At the last stage, the customers evaluate the prototype. When the hypermedia structure is stable enough, the design stage begins. The use of XML in structuring the document offers an easy transition to HTML (or another format) using XSLT transformations. This approach is preferable to the direct use of HTML in prototyping due to the flexibility and structuring power provided by XML (Sperberg-McQueen and Goldstein 1994).

5.3 Galatea example

There are no specific implementation techniques tied to PlumbingXJ, so any method that uses the XML encoded information can be applied. For example, Sierra et al. (2003) present a natural implementation technique. This is not the case for Galatea because there was an original implementation designed for CD-ROM deployment. This version was based on markup technologies (Fernández-Valmayor et al. 1999), and we are currently working on its Web translation. Figure 15 shows the final application corresponding to the prototype automatically generated in Figure 14.

The existence of the Pipe representation of the application, and the prototypes previously generated, simplified the development of this application, as the Fraternali/Ginige-Lowe process model had anticipated. Of course there were final changes, but the main hypermedia structure remained unchanged.

Regarding lessons learned during the development of Galatea, the presence of the contextual dictionary in XML eased the interaction between the team of philologists responsible for the contents of the application and the team of developers. The fast prototyping capabilities provided by the application DTD made rapid testing of several user interfaces in Galatea possible. The encoding of the dynamic linking using the g-class could only be partially reused in the Javascript version for the Web, but the design of the dynamic behaviour was almost reused in its entirety. Finally, constant changes in the contents (required by the team of philologists) were the most frequent problem, but the iterative nature of Pipe, the presence of these contents in XML and the use of software configuration management made it possible to deal with these changes.

We have applied PlumbingXJ to the development of several e-learning applications with a strong hypermedia component (Navarro et al. 2001 ⁴ , Navarro et al. 2002, Fernández-Manjón and Sancho 2002, Fernández-Valmayor et al. 2003, Navarro et al. 2004). The lessons learned in these projects do not differ a great deal, we think, from those learned during the development of Galatea. At present we are involved in the design and development of the Virtual Campus for the Universidad Complutense de Madrid (VirtualUCM 2004). This is an extensive project ⁵ , and in some modules is closer to a computational hypermedia application (Rossi et al. 1999a) than to a hypermedia application. Taking into account the expected results of applying PlumbingXJ to the hypermedia component of the Virtual Campus, we expect to receive important feedback about the use of PlumbingXJ in a very large-scale project.

6 Conclusions and future work

The application of markup technologies for Web development is very popular nowadays. Our work offers another solution in an increasing array of markup technologies for hypermedia Web development, and more specifically for fast prototyping of complex Web applications.

One of the most important benefits of our approach is the specialisation of a well-known process model using the Pipe model. The presence of a process model assures a systematic way for application development, while the conception of the Pipe model allows for the changes in one of the main aspects of hypermedia applications (contents, GUI or dynamic behaviour) without affecting the others. XML is a high-level language appropriate for the prototyping of hypermedia Web applications, and its use at the prototyping stage adds legibility. Note that all the markup technologies analysed in this paper increase the level of abstraction in the development of Web applications, constraining the flexibility of direct coding using a general purpose programming language (e.g. Java), and our approach is no exception. Finally, both XML and Java provide valuable platform independence.

The PlumbingXJ approach has been used in several projects, and we are working on finalising the APG in order to deal with the full expressive power of Pipe. The APG is the kernel of the PlumbingMatic application. This tool will help us apply PlumbingXJ to the development of several applications that we are creating. Finally, we will apply PlumbingXJ extensively to confirm the viability of using our techniques of conceptualisation and prototyping in design and development, obtaining a specific methodology similar to the application of the SMIL language and the Amsterdam model.