Prototyping Web Applications

Prototyping Web Applications Mario Bochicchio, Roberto Paiano SET-Lab, Software Engineering and Telemedia Laboratory Department of Innovation Engineering, University of Lecce, Italy tel. +39 0832 320216, +39 0832 320296

Email:{bomal, rpaiano}@ingle01.unile.it ABSTRACT Design of large WWW sites can be a very complex task if not supported by a suitable theoretical model. A good structural design model, in fact, is able to precisely define the information structures of this kind of multimedia applications and the related navigation patterns. Moreover, through a good design model the designer is able to precisely formulate his/her ideas, discuss them and revise them, without actually starting any implementation. The modeling activity necessarily implies rough initial ideas, revisions, versions, etc. For these reasons a design-supporting environment, allowing the modeler to be effective and precise, is essential. Moreover the site prototyping, starting from the structural design model, is very helpful for at least three reasons: non-expert “readers” can’t fully grasp what the designed application is about, unless they can see it. The second reason is that even expert designer, once the design is pretty mature, may need to visualize the outcome of the design itself, before going to actual implementation. The third reason is that “visual designers” need also to step in their own idea, to develop it and try it, before completing the design process. In this paper we do not discuss design models, which are a research field on its own. The paper discusses, instead, a design/prototyping environment and presents the relevant features of JWeb, a design/prototyping environment being developed as a joint effort from Politecnico di Milano and Università di Lecce, in Italy.

Keywords Hypermedia Design Model, prototyping of Web applications.

1. INTRODUCTION AND BACKGROUND The design of Hypermedia application has been a concern since the very beginning of the development of Hypertext. In fact the focus of research was more, at the beginning, on the authoring environments, rather than on the conceptual aspects of design. The Dexter Model [13], HyDev [24], HyTime [22], AHM [1416], SMIL [17], HDM [6-11,25] and other models, took into serious consideration the conceptual problem of designing complex hypermedia applications, borrowing many concepts from

Data Base Design and introducing concepts specific to hypermedia modeling. As "side effect", since the very beginning it was clear that, with a good design model at hand, a number of activities can be supported and automated. Following this idea, several projects, such as HYTEA[18], MINERS [21] and HIFI [20], have built up supporting systems. More recent projects, such as CMIF [16], RMM [19], Autoweb [5] and Araneus [20], have a similar goal. One feature common to all the above projects is that they blend together design and development environment. In other words the design support is conceived and implemented as part of a larger environment, aiming at the actual development of the application. The underlying goal is to speed up the development process, and this is particularly relevant when large amount of (more or less) rapidly changing information must be managed, and therefore a supporting database is needed. In the following of the paper the main concern is the definition of JWeb, an environment to support design and prototyping of complex WWW sites. It is not the purpose of this paper to discuss the specific aspects of each model, but, in our opinion, HDM [6-11], OOHDM [25], RMM [19], HDMlite [5], Araneus [20] and other similar models, based on the separation of the structural and navigational aspects from the visual aspects, are particularly effective and expressive. Among others, HDM is very well documented referring to a number of complex projects, such as HYTEA[18], MINERS [21] and HIFI [4], all of them partially funded by the European Commission. For these reasons HDM is the model we selected for the implementation of JWeb. Referring to the previous HDM-based projects [4,18,21], JWeb is innovative for two main reasons: it is reusable over different application fields1 and it supports the complete range of HDM primitives and constructs, so that high quality visual interfaces based on sophisticated HDM features can be implemented. The general guidelines on which JWeb is based are illustrated in section 2. In section 3 we describe the main features and the overall architecture of the development part of JWeb; in section 4 we examine the runtime engine for the dynamic page generation; in section 5 we shortly examine an application for which JWeb is currently being used; in section 6 conclusions and future work are described; in section 7, finally, the bibliography is presented.

2. AUTOMATIC IMPLEMENTATION AND DESIGN/PROTOTYPING: GENERAL PROBLEMS Since the development of WWW technology, the goal of improving the development process has become more and more 1

At now JWeb as been successfully used for fashion e-catalogs, for cultural applications, for tourism applications and for E-Business.

relevant, therefore it is understandable why all the above projects aimed, and still aim, at tackling the actual implementation aspects. In this paper, however, we advocate the advantage of having tools to support just design and prototyping, leaving aside, for a while, implementation issues (with the term "prototyping" we mean a fast, cheap and reliable development of a mockup of the final application). There are several reasons why an environment supporting design/prototyping, and not necessarily implying implementation, is useful: (a) Support in the early stage Design needs to be checked, tested, discussed and revised several times before it is completed. Design must therefore be supported in an early stage of the development, when several details are still unclear or missing. Actual development, instead, requires all the design details to be laid down. (b) Multidelivery More and more it happens that the same content must be delivered in several different ways: off-line, on-line, with different levels of depth and completeness, etc.2 If this is the situation, it is clear that design must be completed independently from any implementation, that, afterward, can proceed in several different ways. (c) Technological flexibility More and more delivery environments for the web are emerging; mostly for the multimedia aspects, for the graphic, for the interface etc, so that new possibilities are open every day. Given this situation having to choose a specific delivery environment, or be cut out from new exciting possibilities, as it would inevitably happen in a full scale development environment, is not advisable. In addition many (large) organizations have specific delivery constraints, obliging the implementation to choose not the best possible technology (assuming that such a dream exists), but rather a technology compatible with their organization, compatible with their Information System, compatible with previously chosen technologies, compatible with their cultural background, etc. (d) Design advanced options Sophisticated applications requires advanced design features, for which fully automated implementation could not be devised. It would be negative to not include those features in the design, just because automatic implementation could not support them. (e) Design incompleteness For advanced applications, there are specific features, which can’t be described by even the best design model. These features are therefore not modeled in the schema, but they are rather described through words, diagrams and ad-hoc means. It is clear that these features will be left out by any automatic implementation based on the design model. (f) Visual Communication bandwidth One of the biggest problems for deriving an actual implementation from a design, is the need to implement, for sophisticated applications, high visual communication bandwidth, consisting of complex graphical objects, special 2

In a project that the Politecnico di Milano together with Centro Volta (a research center) is carrying on for RAI (the Italian public TV network), the same content (i.e. multimedia material about ancient and modern philosophy) must be delivered on two CD-ROM’s, one Web-site, and other ways in the future.

effect, animations, local interactions, etc. These advanced communication features can be (relatively) easily implemented with modern graphic interface tools3, but they are hard to be automatically derived from design. Finally, we believe that fast prototyping is an additional important feature of a design environment; fast prototyping means that the application somehow gets implemented, more or less directly from design, but in a fashion not binding for the final implementation, and not necessarily in an efficient manner.

3. THE FEATURES AND THE OVERALL ARCHITECTURE OF JWEB Before describing the actual architecture of the JWeb design and prototyping environment, a few words about the design model and the methodology are needed. In a nutshell, the HDM methodology [23] requires that after a requirement analysis4, a schema of the application is defined. The schema is organized in two different parts: the hyperbase schema describes the basic navigational capabilities offered by the application, while the access schema describes the organizations of the access structures (collections in the HDM terminology). An hyperbase schema is organized into entity types, defining the structure of the objects managed by the application, and link types, defining the basic navigation capabilities5. An access schema defines, instead, the basic indexes (possibly hierarchically organized), guided tours, etc., that allow one to start browsing within the application. Both for the hyperbase schema and the access schema there is a sharp distinction between design in-the-large, where the general features of the design are defined, and design in-the-small, where the details are provided. This distinction is useful in methodological sense for a number of different reasons [7,8], and also it plays an important role in terms of shaping up the supporting environment. The hyperbase schema, on its own, can be examined, discussed and revised. Moreover, starting from this schema, it is possible to develop a sample of actual data, to “visualize” the outcome of the design being developed. At this stage different options are possible: ™ In terms of visual communication (interface), a “functional” interface (i.e. an interface simply holding the different information items, the buttons, etc, without any pretense of visual impact) could be developed, leaving for the future the development of an actual interface. Another possibility is to plug in the prototype and to test several different high quality interfaces options. ™ In terms of access structures and hyperbase, different alternatives could be tried, in order to compare different solutions, and to choose the most appropriate ones. ™ In terms of detailed design, the individual information items could be completely identified, or they could be just sketched, leaving their specification to a later stage. The combination of the different options actually defines a number of different scenarios; we are convinced that an effective supporting environment should not enforce a specific way of proceeding, assuming that the “best practice” exists, but rather it 3

Such as Macromedia Director-Shockwave, for example. For which the W5 methodology has been defined. 5 As an example, the fact that from a “Fabric”, it is possible to navigate to the description of the “Material”, which the Fabric is made of, it is a typical entry of an hyperbase schema. 4

should allows a great level of flexibility. It is our experience, in fact, that in different situations, for different projects, we have used different strategies and different tactics.

MODELING

The JWeb system is a design environment with fast prototyping capabilities, based upon the HDM methodology, with the following features: ‰ it supports design of the hyperbase and of the access structures; ‰ it supports a clean separation between design in-the-large and design in-the-small; ‰ it allows to build an environment repository, based on a relational DB to hold the multimedia contents; ‰ it allows to try several configurations, both for the hyperbase and the access structures; ‰ it allows the use of a purely functional interface, but it is also possible to test several high quality pre-defined interfaces; ‰ it allows to “execute” the application (using a small example of actual data, or fictitious data) in order to “visualize” the implications of the design. The overall picture of JWeb is shown in Fig. 1. • JWEdit: allows to designer to define the HDM schema of the application, providing design in-the-large, and providing a full design in-the-small, if felt necessary, or just a sketch, if full details are felt not necessary; • JWData (in-the-small mapper): it translates the detailed design into a relational Data base schema; • JWFeed: it allows the insertion of a sample of actual data, or of a simplified version of them, in order to create an instance of the application; • JWXdef: it allows a number of “alterations” of the original schema in order to test possible different “hyperviews” of the

•

•

application originally designed; its output is an “executable” schema and an “executable” data Base, obtained by “filtering” and reorganizing the original Data Base. JWXport: it creates a runtime DB, if necessary, physically building the hyperview to have better performance for online application (with few changes during the time) or for off-line application. JWEngine: it allows to plug-in different high quality templates for the interface.

The overall environment is modular and flexible. The designer, therefore, does not need to use all the available features. If the different design alternatives are not needed, the Configurator (JWXdef) does not need to be used. One of the relevant features of the JWeb environment, in order to keep modular and flexible, is that all the exchange of information among the different tools is based upon XML [26]. XML is used to exchange schemas, parameters and also instance data. This technical choice allows a very easy strategy of enhancement, addition, substitution or replacement of all the different tools. It could be also envisioned the exchange of information (export and import) with other design and development environments. From the technical point of view, JWEdit, the JWData, the JWFeed, the JWXdef and JWXport has been designed using UML[3]. They share the same internal structure and the same classes: the main class, named Project, manages data structure and the user interface. The principal inner class of Project is ProjectElement, that represents the abstract HDM design element, while a number of concrete classes: Entity, Application Link, Access Structure, Collection etc., implement each specific modeling elements. The XML parser is another important inner class of Project, common to the various tools, it is able to parse

Schem a R e p o s i to r y

J W E d it c r e a te / m o d i f y

E n v ir o n m e n t Schem a

R e p o s i to r y I n te rfa c e

J W D a ta

DEVELOPMENT

c r e a te / m o d i f y

JW Feed

E n v ir o n m e n t R e p o s i to r y

m e d ia o b je c ts p r e s e n t a t io n o b je c ts

i n s e r t /e d i t/ d e l e t e

re a d /m o d ify

J W X p o rt

JW Xdef

im p o r t /e x p o r t

A p p l ic a ti o n r e p o s i to r y

DELIVERY

A p p l ic a ti o n sch em a

R u n -T im e R e p o s i to r y

J W E n g in e

F ig u r e 1 – J W e b e n v ir o n m e n t

USERS

and to select the XML structures defined in the HDM DTD, extracting the parameters related to the various tags; moreover it performs the validation of the current XML model. The development of the various components was performed in Java.

4. THE RUNTIME SOLUTION OF JWEB AND THE DESIGN “IN-THE-SMALL” Figure 2 shows the runtime structure of the prototyping part of JWeb. The runtime support basically consists of an HDM Interpreter able to perform the dynamic page generation. The heart of the system is the Main Server Engine (MSE), a JAVA Servlet application, that support the interaction between client and server. MSE communicates with Navigation Engine (NE) that supports the in-the-large navigation through the application described by the Schema. At each user request the NE performs the evaluation of the “next step” of the navigation, as a function of the “current step”, by applying the HDM navigation rules to the Schema. The DB Engine (DBE) implements the unified interface of the HDM Interpreter toward the DBMS. It is responsible to send the right SQL commands to the DBMS, to get the results, and to format them for the required purpose6. It sends the results to MSE in XML format. After the NE has decided the needed slots (information items), and DBE has retrieved them from the Hyperbase, the MSE arranges them according to the proper layout template (retrieved from the Layout repository), using the Layout Class Library (LCL) The client-side part of the HDM Interpreter is subdivided into three more components: the Event Manager has the role to capture the user input transforming it in a request suitable for the NE; the Session Manager controls the session parameters (language, sound volume, skill level, …); the History Manager performs the recording of a user session, to support the history navigation. Moreover it implements a simple form of "second level authoring" [12] based on the "history editing". JWeb

JWeb

Browser Client Side Browser

Server Side XML Application Schema

Navigation Engine

Main Server Engine - Servlet Application-

Session Manager

Event Manager History Manager

Hyperbase

DB Engine

Layout

Figure 2 - JWeb: internal structure According to the HDM model, the design in-the-small provides the detailed description of the media objects (slots in HDM terminology) in the hyperbase. Each slot could be as simple as a number or a string, or could be a scrolling text, a video, a number of still pictures synchronized with an audio, an animation, etc. 6

The DBMS we use for stand-alone applications is Microsoft Access 97 through JDBC; for Intranet applications however, we use a Sun SPARC Station running Oracle 7.3 and Oracle Web Server 2.1 under Solaris 2.5.1. Oracle is accessed through JDBC

Slots can be combined into aggregates (frames, in the HDM terminology) and sub-aggregates. Given this situation, two prototyping approaches are possible: ♦ to use a single database to represent all the information both related to "in the large" and "in the small" design ♦ to separate the details into a different DB The first approach, adopted by Autoweb [5], Araneus [20] and RMM [19], is more accurate in terms of information modeling, but it suffers from a number of drawbacks: a) The multimedia items can’t be actually stored in the database, since no DBMS actually supports all the needed technologies; therefore the actual pieces of content are stored in separate files, and the Data Base records only stores the “names” of those files. b) Arranging the multimedia items in an ergonomic, appealing, usable interface is a difficult job that very often requires the use of ad-hoc tools. In addition, for the uses envisioned by JWeb, specific precise decisions about the interface are premature (it may take a long time before completing the interface design for high quality applications). c) In order to keep the same design valid across similar applications (e.g. the same catalogue structure for different companies of the same business sector), the details should not be modeled. d) The detailed design of nodes is not performed by the same people doing the "in the large" structuring of hyperbase. While information designers take upon the second job, the first job, on the details of the content and upon the interface organization, requires “content specialist” and also graphic designers. For all the above reason JWeb has decided to clearly separate the implementation of what there is within a node (in-the-small) from the overall organization of the nodes and the navigation across them (in-the-large). JWeb provides, therefore, two options for the designer: ♦ To treat it each node as a whole, without modeling its actual content; the prototype will still be executable, by simply introducing mockup, ad-hoc developed content. This option is good for testing the design in-the-large, without bothering with the specification of the detailed information. ♦ To use a separate tool that interprets the detailed design to generate the corresponding nodes. This operation can be performed off-line (suitable for off-line applications or Intranet applications) or on the fly for normal on-line application. In technical terms a node, treated by the HDM-interpreter [2] as a single piece of information can be implemented with different technologies: e.g. an HTML page, a Java applet, a Shockwave page, XSL, etc. For the time being we have focused upon Shockwave10, that easily ensures an excellent control over the interface and also an excellent control over multimedia items. It should be noted, however, that the HDM-interpreter is basically independent from the technology used for the node implementation, allowing therefore a great deal of flexibility. 10 Shockwave is a technology defined from Macromedia, and based on the very successful Director authoring environment. It allows the use of highquality multimedia contents on the Web, it is a “de facto” standard, and it supports the development of Web applications using movies, games, animations, sound and audio.

Our choice of using Shockwave pages as visual representative of the application nodes allows the designers, if they wish to do so, to try in the prototype very high quality visual interaction. If they do not wish, instead, they may use very simplified layout (that can in fact be automatically derived from model description). This approach is quite in contrast with the approach taken by most of the environment supporting full development: they oblige the designer to go through a precise phase of visual design (in order to fit all the details in), somehow competing with the facilities offered by advanced tools for interface design.

5. AN EXAMPLE APPLICATION: “CASUAL WARE” One of the projects where JWeb is actually being used is “Casual Ware”, a joint effort of a number of different fashion manufacturing companies8, in cooperation with University of Lecce and Politecnico of Milan. The ultimate goal is to create a Web environment to support marketing and sales of items such as jeans, pants, T-shirts, shirts, accessories, etc. The second goal is to offer a family of catalogs, based on Web technology, of the items being offered. The catalogs can be distributed off-line (as a CD-ROM, or DVD-ROM), via Extranet (to points of sales) or via Internet (for final users). Different companies could choose different distribution strategies, and also each company may choose different strategies for different tasks. Our approach to the problem has been to develop a basic Hyperbase schema and a number of initial access structures; for different tasks the company will develop, using the JWXdef, different versions of the basic schema. The same thing will happen for the other companies, that will use the catalogue. The starting design in the large is shown in Fig.3, more details about the application can be found in [1]. The HDM schema of the application consists of seven Entity types: Model, Style, Fabric, Article, Fit, Accessories and: Size Table. The links Model-Fabric and Model-Article are the most important ones, since each model is realized using various specific fabrics and various colors, that a customer could chooses by following this links. The main access structures, initially devised for the application, are: • the list of the items available for Men’s ,Women’s and Unisex; • the list of the items organized by the different product lines (styles); Model Model Info

Article Article Info

Figure 4 - Model BRICO: prototyping layout • • •

the list of the items organized by “Fit” (i.e. “dressing style); two special access structures for T-shirts; Company’s distinctive clothing: i.e. a specific presentation of the characteristic products of the company; • New Products: i.e. a specific presentation (frequently changed) of trendy items. Figure 4 shows a sample of functional layout, directly derived from the model, just to verify the overall soundness and effectiveness of the model. Marketing experts and layout designers, from the involved company, have defined, in parallel, information details and a proper visual interface shown in Fig.5. The prototyping of “Casual Ware” is completed (at end of March 99) with the definitive data using the final layout.

Sizes Table Sizes Table

Measure Table

Figure 5 - Model BRICO: final layout

6. CONCLUSIONS AND FUTURE WORK Style Reference World

Fabric

Fit

Accessories

Fabric Info

Fit Info

Accessories Info

Figure 3 - “Casual Ware”: Hyperbase in the large 8

The leading company is Romano SpA, and is located in Casarano (Lecce, Italy).

In this paper we have tried to put forward the following argumentation: ¾ design of complex Web sites should be engineered, and fully supported by a proper environment; ¾ design can be effectively supported only if a good design model is part of the design methodology; ¾ the design supporting environment should be modular and flexible, i.e. it should not require one to follow strict procedural guidelines;

¾

design support should be independent from automatic development and implementation of the application; ¾ automatic (or semi-automatic) fast prototyping could be conveniently added to design support. In conceptual terms the following improvements are needed to JWeb: • to provide full support for HDM2000, the next very powerful, fully revised, version, of HDM; • to generalize the Configuration activity, providing full support for Hyperviews, using selected attributes attached to the different information structures; • to generalize the algorithm for generating the Instance Data Base, that today can be generated only in simple cases9; • to generalize the interplay between design in-the-small (where all the items are detailed) and design in-the-large (where a node is seen as an atomic object). As far as the implementation is concerned, a number of improvements are foreseen: • Use of XML not just for the schemas, but also for the instances (for describing individual objects). This will make fully modular and flexible the overall environment, allowing also the exchange of “content” over Internet applications. • Transforming the interpretation process of the Navigation engine into a just-in-time compilation process by adding a page cache in the communication path between the HDM Interpreter and the Web Server. This could be useful in order to increase the system throughput, in term of served pages per second. • Adopting Java Servlet techniques as basic technology, for the Server side Engines, in order to improve performances and portability. • Improving the management of complex multimedia objects. • Using XSL style-sheets to implement simple and WEB oriented interfaces In terms of uses, although we advocate prototyping, rather than automatic application development, in a number of cases we have been asked to use the prototype as initial version of the application, to be worked on, in order to build up the final version. We accept the fact that, in simple cases, the prototype could be used as an implementation platform.

7. REFERENCES [1] Bochicchio M.A., Paiano R. and Paolini P., "JWeb: an HDM Environment for fast Development of Web Applications", Proceedings of IEEE Conference on Multimedia Computing and Systems 1999 (ICMCS '99, Firenze, Italy), 2, 809-813. [2] Bochicchio M. A. and Paolini P., "An HDM Interpreter for On-Line Tutorials", Proceedings of MultiMedia Modeling 1998 (MMM ’98,Ed. N. Magnenat-Thalmann and D. Thalman, IEEE Comp. Soc, Losanne 1998), 184-190. [3] Booch G., Rumbaugh J. and Jacobson I., "UML User Guide", Addison Wesley, 1999. [4] Cavallaro U., Garzotto F., Paolini P. and Totaro D., “HIFI: Hypertext Interface for Information Systems”, IEEE Software 10, 6 (Nov. 1993), 48-51. [5] Fraternali P. and Paolini P., “The Autoweb System”, submitted for publication ([email protected]).

9 We know in advance that, in the most general case, a semiautomatic algorithm is needed.

[6] Fraternali P. and Paolini P., “A Conceptual Model and a Tool Environment for Developing More Scalable, Dynamic, and Customizable Web Applications”, EDBT 1998: 421-435. [7] Garzotto F., Paolini P. and Schwabe D., “HDM - A Model Based Approach to Hypermedia Application Design”, ACM Transactions on Information Systems, 11, 1 (Jan. ‘93), 1-26. [8] Garzotto F., Mainetti L. and Paolini P., “Hypermedia Application Design: A Structured Approach”, In J.W.Schuler, N.Hannemann and N.Streitz Eds., “Designing User Interfaces for Hypermedia”, Springer Verlag, 1995. [9] Garzotto F., Mainetti L., Paolini P., “Adding Multimedia Collections to the Dexter Model”, ECHT 1994: 70-80. [10] Garzotto F., Mainetti L. and Paolini P., “Navigation in Hypermedia Applications: Modeling and Semantics”, Journal of Organizational Computing, in press. [11] Garzotto F., Mainetti L. and Paolini P., “Designing Modal Hypermedia Applications”, Hypertext 1997: 38-47. [12] Garzotto F., Mainetti L. and Paolini P., "Information Reuse in Hypermedia Applications", Proc. HT'96- ACM International Conference on Hypermedia, Boston (Ma, USA), March 1996, ACM Press. [13] Halasz F. and Swartz M., "The Dexter Hypertext reference Model", Communications of ACM 37, 2 Feb. 1994. [14] Hardman L., "Modeling and Authoring Hypermedia Documents", PhD Thesis, Amsterdam, 1998. [15] Hardman L., Bulterman D. and van Rossum G., "The Amsterdam Hypermedia Model: Extending Hypertext to Support Real Multimedia", Hypermedia Journal 5(1), July ‘93, 47-69. [16] Hardman L., Bulterman D. and van Rossum G., "Authoring Multimedia in the CMIF environment", Visual presentation at InterCHI ‘93, Apr. ’93. [17] Hoschaka P., "Synchronized Multimedia Integration Language 1.0 Spec.", W3C Recommendation 15 June ’98. [18] Hytea Projects reports, available from Politecnico di Milano ([email protected]) and from Siemens corporate research center (Munich, Germany). [19] Isakowitz T., Stohr E.A. and Balasubramanian P.: "RMM: a methodology for structured hypermedia design", Communications of the ACM 38 (8), Aug. 1995, 33-44. [20] Mecca G., Atzeni P., Masci A., Merialdo P., Sindoni G.: "The Araneus Web-Base Management System", SIGMOD Conference 1998. Pp. 544-546. [21] MINERS Projects reports, available from Politecnico di Milano ([email protected]) and from EDS-Italy Corporate Research Center (Rome, Italy). [22] Newcomb S.R., Kipp N.A. and Newcomb V.T., "HyTime: The Hypermedia/Time based Document Structuring Language", Communications of ACM, 34(11), 67-83, 1991. [23] Paolini P., "Lectures Notes on Hypermedia Design", unpublished ([email protected]). [24] Pausen P. and Voss J., "The HyDev Approach to Model Based Development of Hypermedia Applications", 1st International Workshop on Hypermedia Development, held in conjunction with ACM Hypertext '98. [25] Rossi G. and Schwabe D., “The Object-Oriented Hypermedia Design Model”, Communications of the ACM, 38(8), 45-46. [26] XML Spec., http://www.w3.org/TR/REC-xmll.