Building and Managing XML/XSL-powered Web Sites: an Experience Report

Transcription

1 Building and Managing XML/XSL-powered Web Sites: an Experience Report Clemens Kerer, Engin Kirda, Mehdi Jazayeri and Roman Kurmanowytsch Distributed Systems Group Technical University of Vienna Argentinierstrasse 8/184-1 A-1040 Vienna, Austria C.Kerer, E.Kirda, M.Jazayeri, Abstract The World Wide Web Consortium s extensible Markup Language (XML) and the extensible Stylesheet Language (XSL) are standards defined in the interest of multipurpose publishing and content reuse. XML and XSL have been gaining popularity rapidly both in industry and in academia. Although much has been written on XML/XSLbased solutions, there exists a gap between theory and practice. In this paper, we report our experiences in deploying XML/XSL in the implementation of two industry Web sites and summarize nine lessons we drew from our experiences. Keywords: XML, XSL, Web Engineering, Web Site Development 1. Introduction The Web is a dynamic, constantly changing medium. Millions of Web sites exist today and the Web is the largest growing area of the Internet. There has been an explosion in the number of Web-based applications, solutions and services. The Web s Hypertext Markup Language (HTML) was originally created because scientists at CERN were looking for ways to share information and documents over the Internet [1]. It was never expected to gain popularity this fast and it was not designed for the requirements we see in Web sites today: Web sites need to be manageable, flexible for changes, and need to provide dynamic functionality for interaction with users. Hence, to set up a single service, the typical Web development environment usually needs a combination of different technologies, tools and architectures. Furthermore, one of the recent shortcomings of HTML has turned out to be its poor support for deviceindependence. Users may not only want to access the Web from their personal computers, but may also access it using mobile devices with varying display sizes and characteristics. HTML, with its tables, fonts, forms, etc., adequately supports only the display of a personal computer. Further HTML drawbacks are the inflexibility to easily incorporate layout design changes and the inability to reuse and extract content. In order to eliminate HTML s shortcomings and to define flexible, extensible standards that address current Web requirements, the World Wide Web Consortium (W3C) defined the extensible Markup Language (XML) [16] and the extensible Stylesheet Language (XSL) [17]. XML and XSL have gained popularity fast both in industry and in academia. Much has been written on XML-based solutions and ideas for the Web, but there has not been many experience reports about the deployment of these technologies in real Web sites where requirements may change on a daily basis. In our XML/XSL projects, we observed that there exists a significant gap between theory and practice. In this paper, we share our experiences in deploying XML/XSL in the implementation of two industry Web sites and summarize nine lessons we drew from our experiences. The paper is structured as follows: The next Section defines the terminology used and discusses XML/XSL concepts. Section 3 gives a brief overview of the case studies. Section 4 presents our experiences and lessons we learned. Section 5 summarizes the paper. 2. XML, XSL and Layout-Content (LC) Separation 2.1. Terminology The content of a Web site is the information that is offered to the visitor of the site. The layout, is the information that is used for the visual rendering of the content. For example, the price of a ticket would be content whereas the color the price is presented in would be layout information. The business logic, on the other hand, is the functionality

2 that is necessary for providing the dynamic interaction with users (e.g., the program code that looks up if there are available tickets). Further, we define a flexible Web site (or service) as a site that is easy to extend and maintain. Thus, layout flexibility denotes layout information that is easy to modify and redefine XML and XSL XML is a syntactic meta-language for defining other languages. The interpretation of XML documents is application dependent. XML is highly versatile and can be used to describe virtually anything. A Document Type Definition (DTD) [19] (or more recently, XML Schemas [18]) is part of the XML specification and is used to describe the syntax of an XML language. XSL was proposed and designed because XML by itself does not contain any layout semantics. XSL is divided into two parts: transformations (XSLT) and formatting objects (XSL:FO). XSL:FO is a language for describing 2D layout of text in both digital and printed media. XSLT, on the other hand, is a language for transforming one XML document into another document format such as HTML or WML for mobile devices. By describing the content in XML and the layout in XSL, a complete layout-content (LC) separation can be achieved. Hence, the content and the layout can be reused independently. Furthermore, arbitrary layouts can be applied on the content enabling layout flexibility MyXML template engine MyXML is an XML/XSL-based template engine for the development of flexible, dynamic Web services. Besides the separation of layout and content using XML/XSL, MyXML enables the business logic of Web applications to be separated as well. A separation of the business logic increases the flexibility of dynamic Web services. We have been using our MyXML technology in the case studies. A detailed description of MyXML is beyond the scope of this paper. More information can be found in [4, 5, 6]. 3. Case Studies In this section, we give a brief overview of the case studies. In both case studies, we used XML/XSL, and MyXML for generating static and dynamic HTML pages The Vienna International Festival (VIF) Our group has been building and managing the Web presence of the famous Vienna International Festival (VIF- Wiener Festwochen) since In the past, the VIF site has often been a case study for our Web development tools and methods (e.g., [13, 15]). The VIF is the major cultural event in Vienna. This annual festival usually lasts five weeks over a period in May and June. The festivities take place in various theater locations and concert halls and consist of operas, plays, concerts, musicals and exhibitions. Often, famous international directors, performers and ensembles are guests. The VIF attracts many visitors around the globe, but most of the international visitors come from neighboring countries such as Germany, Italy and Switzerland. Since its first presence on the Web, the VIF has been changing its look-and-feel every year. In October, the new layout is given to us and in December the new Web site with the modified graphical look is presented at a press conference. The implementation work usually takes place in October, November and December. The services the site provides also vary annually. Information such as event locations, current programme, an archive of earlier performances since 1995, news updates and press reports are usually provided to visitors. One of the key services of the site is the online ticket ordering. Users can choose and buy tickets online using a shopping-basket application. The content in the site is fully bilingual. Every German page in the site has a corresponding English page and vice versa. The offered services are adapted according to the Web server log statistics and received user input. Hence, the service requirements and the layout of the site change frequently before, during, or after the festivities. The site consists of hundreds of static and dynamic pages. Until this year, we had been using our HTML-based technologies for building and managing the VIF Web presence. These template-based tools enabled us to achieve some flexibility, but we were not able to have a strict LC separation. This year, we implemented the site using XML/XSL and our MyXML template engine technology. Our aim was to achieve a high level of flexibility in order to decrease the necessary effort in integrating new layout and service requirements The Austrian Academy of Science (AAS) The Austrian Academy of Science (AAS- Österr. Akademie der Wissenschaften) is the oldest scientific institution in Austria. The academy has about 90 employees and thousands of members. The organization consists of a number of independent departments and institutes. Changes in the internal structure of the organization are frequent. Organizational units may be closed and new units created based on need and research trends.

3 The academy has been on the Web since Like many other Web sites [9], the Web site started out as a small service managed by a small group of interested people. As the requirements evolved and changed, the site grew in an ad-hoc manner and its management became problematic. Suffering from these typical Web site problems, the organization decided to re-engineer the site. Based on their previous experiences, the AAS formulated a set of key requirements for the new site such as the ability to integrate a new layout, simple update mechanisms for easing the content management task, access control mechanisms for the academy members, and the ability to integrate legacy data stored in external data sources. Since the year 2000, we have been using XML/XSL and MyXML in the implementation of the AAS Web site. 4. Lessons learned in deploying XML and XSL In this Section, we list nine lessons we distilled from our experiences during the development and management of the VIF and AAS Web sites. We discuss problems we faced and solutions we applied Lesson 1: Learning XML and XSL concepts is not easy for the developer HTML has been easy to learn for developers and has quickly become popular. HTML user interfaces are rapidly built and dynamic functionality is easy to provide using scripting languages. Web technologies such as PHP [10] and ASP [11] have been designed with rapid development in mind and support frequently needed functionality such as relational database access. The strict LC separation enforced by XML/XSL, on the other hand, is frequently misunderstood and misused by developers. In our case studies, we observed that some students and developers involved in the implementation were not comfortable with LC separation concepts. They were used to inter-mixing content with layout information. They had been doing this in all programming languages they had learned during their education and the Web development they had done with traditional technologies. The result was that complex solutions were produced and the benefits of a strict LC separation were reduced. For example, there was a general tendency to mark content using XML tags such as left, right, middle, etc. that actually reflected the layout design requirements and did not describe the content. Sometimes, the LC separation advantages were weakened because the developer coded static text information directly into the XSL stylesheet. Thus, we were faced with the problem that multi-lingual support was not possible by reusing the same layout stylesheet and had to redesign these pages. Frustration was often the result as the complexity of an XSLT stylesheet increased with the complexity of the described layout. Often, writing XSLT stylesheets was errorprone and difficult to debug because of the recursive nature of XSLT. For example, some elements were processed twice instead of once and time was lost while figuring out where the extra processing was happening. Successful use of XML/XSL technologies requires a design-oriented approach and more discipline than the earlier code-oriented approach of HTML. Investing time in the design is sometimes discouraging to the developers because the payoff is not immediate and will only be seen during the maintenance phase. The development of high-level, easyto-use XML/XSLT visual Web development tools can ease the problem and make the concepts that these technologies introduce easier to understand Lesson 2: XML and XSL do not provide a direct benefit for building content management interfaces In [5], we reported our experience that content managers responsible for the content of a Web site often lack the basic knowledge and understanding that is necessary for dealing with a dynamic, fast evolving medium like the World Wide Web. Most content managers we worked with had heard of XML and XSL and thought that the technologies were going to make their lives easier by magically providing support for searching, indexing and content management. They were wrong. Even if XML and XSL technologies are deployed, simple-to-use update mechanisms still have to be built. In the past (e.g., [14]), we built database-backed Web update mechanisms to provide support for easy content management. The provided update mechanisms have to allow content managers to add new pages, make minor modifications to the layout and enable them to modify the content. If update mechanisms are not provided and content managers are asked to directly manipulate XML/XSL information, we observed that they preferred to modify the generated HTML files instead. Manipulating the HTML files, it seemed, was often easier and less time consuming for them. Thus, once the site was re-generated from the XML content and the XSL definitions, the modifications were overwritten causing further complications. Because of the current lack of XML repositories and standard XML querying languages, building XML-based update mechanisms is not easy. Thus, traditional relational databases often have to be used for storing part of the content. XML information can then be generated

4 from the database and formatted with XSL. Unlike HTML, XML/XSL technologies appear to be too sophisticated for many content managers to appreciate. The development of user-friendly update mechanisms should have high priority in XML/XSL-based Web development. In our case studies, we provided relational database-backed online Web forms for content management and hid the XML/XSL technology from the content managers Lesson 3: Graphical design companies are slow to pick up XML/XSL know-how Although the graphical design companies we worked with were interested in the new XML/XSL technologies, they did not have any experience in the area. The demand for XML/XSL was not large and the focus was on rapid development. Hence, issues such as maintenance, flexibility and scalability were frequently ignored. Furthermore, the business processes they had developed in the past and the tools they used did not support special XML/XSL development requirements. For example, Dreamweaver [7] was a popular tool choice for designing the layout and the look-and-feel of the pages. Ideally, we should have given them a DTD that described the content and they should have given us a layout definition in XSLT. But they only had know-how in HTML development and were only able to deliver the graphical look as HTML templates. The HTML templates the design tools generated were not always easy to read and sometimes contained automatically generated redundant code. The lack of know-how on the graphical designer s side complicated our implementation tasks. We first had to analyze the HTML code and write XSL stylesheets that represented it. Changes on the graphical design meant that we had to reproduce XSL stylesheets to keep up with the changes. The reluctance of many design companies to work with XSLT will probably disappear once XML and XSL firmly establish themselves as Web standards. The integration of XML/XSL support in Web browsers may also speed up the demand for XSLT code. The wide acceptance of HTML and the large number of available HTML tools is an indication that HTML will not disappear soon Lesson 4: XML/XSL deployment needs more data organization planning In traditional Web service development, a single file may contain the content, the layout and sometimes program logic. The LC separation enabled by XML/XSL technologies on the other hand means that the content, the layout and sometimes program logic have to be stored in different files. Thus, the data organization overhead increases. Data organization is an old issue in Web site maintenance. A frequent problem is that as the site grows, content managers lose track of the files and resources in the site. The results are often broken (or dangling) links, a growing need for extra storage space and files that are forgotten [12]. If XML/XSL technologies are deployed, data organization problems may worsen because the number of involved files and their dependencies increases. In a typical site, for example, an XML file may reference a DTD, import other XML files and point to a stylesheet that, yet again, imports other stylesheets. According to our experience, it is important to decide on and to keep to consistent file naming conventions and directory structures. In our projects, we have adapted the Web project directory structures defined within Sun Microsystem s Java 2 Enterprise Edition (J2EE) [3]. The data organization involves a separation of content files, layout styles, DTD definitions, program sources, configuration files and resources such as pictures. These files are used to generate HTML files that are then copied to their specific locations on the Web server Lesson 5: LC separation through XML/XSL provides high layout flexibility In the VIF case study, we reused a single stylesheet for generating more than 50 detailed event pages (see Figure 1). Layout flexibility increased since it was easier to make changes to the layout or the structure of the pages. For example, we once had to move the actor information on all the pages from the right column to the middle column. We only had to modify the corresponding stylesheet to meet the new layout requirement and could re-generate the event pages with ease. Since the same stylesheet was also used for both the German and English pages, the modification of a single stylesheet solved the problem. If we had used pure HTML, such a modification would have required a manual adaptation of all the English and German pages. The LC separation advocated by the W3C indeed facilitates reuse of existing stylesheets and provides layout flexibility Lesson 6: XML/XSL provide support for flexible, consistent navigational structures One of the frequent problems of medium to large Web sites is the integration and management of a consistent navigational structure. Such a structure usually consists of a navigation bar placed on the top, or on the sides of a page. The navigational structure mainly serves two purposes:

5 Figure 1. Screenshot of a VIF event page. It contains navigational information and prevents the user from getting lost. It provides links and pointers to other parts of the site. In pure HTML-based Web sites, the management and implementation of such a navigational structure may be difficult. For example, if a single hyper-link in the navigation bar has to be modified, this results in all HTML pages having to be modified. In sites containing thousands of pages, this may cost time and money. XML/XSL facilitate the generation and management of consistent navigational structures: The navigation bar can be defined once in an XML file and a corresponding XSL stylesheet can be used for the visual rendering. This navigation XML file can then be imported from all other pages. Thus, if modifications are necessary, only one file needs to be adapted. Furthermore, XSL enables the building of arbitrarily complex navigational structures. Logic can be embedded into the navigational structure using XSLT commands so that the navigational bar is rendered according to the user s position within the site. For example, position highlighting (e.g., You are in the main page of section Teaching ) and hierarchical navigational information (e.g., You are in page Courses under section Teaching ) can be embedded into the structure. Figure 2 depicts the navigational elements of the AAS Web site. A hierarchical navigation bar is shown on the left side and a list box containing shortcut links to different parts of the site is shown at the bottom of the page. The nav-

6 igational elements were created from the same XML file. The application of different stylesheets made it possible to generate two different navigation structures with differing levels of detail Lesson 7: XML/XSL enable multi-lingual Web sites As the Web has become more international since its early days, representing the content of a Web site in multiple languages has become an important requirement for many Web sites. In our VIF case study, implementing support for two languages involved a considerable effort in the past. With HTML-based development, not only the content had to be provided in two languages, but also the layout had to be implemented again. We copied every existing page and replaced the content either directly, or by adapting the database. The current VIF and AAS Web sites do not suffer from such drawbacks since XML/XSL facilitate reuse of DTDs and layout information. We only had to store the translated information in appropriate XML files or in the database. Then, we applied the already existing stylesheets and generated a new version of the Web site in the new supported language. Integrating multi-language support into XML/XSLpowered Web sites involves a certain overhead, though. In our first attempt to integrate multi-language support, we were not successful because we had not considered all the design issues. One problem was the design of the navigation between the different language versions of the Web site. We were asked to provide support for enabling the user to switch to the same page in different languages anywhere in the site. This requirement was especially challenging for automatically generated dynamic pages such as the VIF shopping cart. The user s exact position within the process of ticket ordering and the contents of her shopping cart had to be mirrored in the alternate language. The correct handling of images involved significant design effort as well. Some images were language-specific (e.g., those that contained text in German) and these requirements had to be considered in the design of the DTD Lesson 8: Even if XML/XSL are deployed, changing requirements are not always easy to integrate Just as in software engineering [2], requirements change frequently in Web development during and after implementation [5]. Thus, the DTDs of a Web site will also change frequently. A stable DTD probably only exists in a few cases. Even the most careful and detailed design phase will not help against such changes. In the AAS Web site, for example, late in the development process, a DTD for a list of entries had to be redesigned. The definitions for news items and current events had to be modified because the content providers discovered that they could not come up with a thumbnail image for every entry as was planned. Thus, the graphical designers had to provide a new list layout template and the structure of the content files had to be adapted accordingly. We ended up with approximately 30 different kinds of pages as opposed to 10 planned in the analysis phase. This caused a considerable amount of extra effort. Parts of the Web site had to be redefined and re-implemented. According to our experience, even if XML/XSL are deployed, changing requirements are not always easy to meet. This is especially true if DTD changes are necessary. The Web developer can try to ease this problem by making a DTD definition as flexible as possible. Care should be taken, for example, not to encode any layout-specific information in a DTD. A good requirements collection will also help in anticipating and preparing for future requirements. Probably the most useful asset, though, is previous experience with the site. Past requirements can give a good hint as to what future requirements might be. Switching to XML/XSL from an HTML-based approach in the VIF site was less problematic than building the AAS site because we had extensive prior experience with the VIF Lesson 9: Specifications and tools will change At the time being, XML/XSL-based tools and specifications are evolving at a high pace. The release dates in Table 1 illustrate the rapid development rate of the Apache Xerces XML parser [8] used in our case studies. When working with new technologies such as XML and XSL, the decision to switch to a new version of a tool, or specification has to be considered carefully. Such decisions are frequent in Web development as new versions of tools and specifications appear often. Because our Web development tools were based on technologies provided by third parties, we observed that the deployment of a newer version of a tool sometimes meant that problems caused by a buggy implementation would disappear. On the other hand, newer versions sometimes contained new bugs as well as new features and were not always compatible with older versions. When using XML/XSL for Web development, the required functionality should be identified clearly. Upgrades should only be considered if missing functionality is provided by the new version.

7 Figure 2. Screenshot of the AAS Web site. Table 1. The development cycles of the Apache Xerces XML parser. November 9, 1999 January 5, 2000 May 9, 2000 May 19, 2000 June 5, 2000 June 21, 2000 July 26, 2000 July 26, 2000 August 28, 2000 October 19, 2000 November 27, 2000 December 6, 2000 December 7, 2000 January 31, 2001 Xerces v1.0.0 Xerces v1.0.1 Xerces v1.0.4 Xerces v1.1.0 Xerces v1.1.1 Xerces v1.1.2 Xerces v1.1.3 Xerces v1.1.3 Xerces v1.2.0 Xerces v1.2.1 Xerces v1.2.2 Xerces v1.2.3 Xerces v2.0.0-alpha Xerces v1.3.0 In one of our case studies, the beta release of an XML parser turned out to be problematic. We had to invest a considerable amount of development time in tracing down and fixing a software bug in the parser. We take a conservative approach to upgrading to new versions. We only switch versions after the release is stable and only if it offers functionality that we need and was lacking in the current version. 5. Conclusion In our projects, we were able to confirm that XML/XSL deployment indeed increases layout flexibility and provides multi-language and navigation support. Although a strict LC separation achieved through XML/XSL has many advantages, a considerable effort is involved in using these technologies. The lack of experience in LC separation concepts and XML/XSL can be a major cause for the extra effort. We observed a significant gap between XML/XSL

8 theory and practice. Most Web development companies are still reluctant to deploy XML/XSL in their projects. In order to highlight the benefits of these technologies, there is a need for Web developers to report their practical XML/XSL experiences in real-world conditions. Furthermore, there is a great need for proven, easy-to-use XML/XSL Web development tools and methodologies. XML and XSL in Web development can contribute to creating highly flexible, device-independent Web services, but they will not remedy all problems found in Web sites. The advantages provided by XML/XSL may not be apparent during the implementation phase, but the extra deployment effort will pay off once requirements start to change, the site has to be re-engineered, or there is a need for supporting mobile devices Acknowledgements The authors thank the Vienna International Festival and the Austrian Academy of Science for their financial support during the development of MyXML. This work was also supported in part by the European Commission under contract IST (EASYCOMP). References [1] T. Berners-Lee, R. Cailliau, A. Loutonen, H. F. Nielsen, and A. Secret. The World-Wide Web. Communications of the ACM, 37(8), August [2] C. Ghezzi, M. Jazayeri, and D. Mandrioli. Fundamentals of Software Engineering. Prentice-Hall, Englewood Cliffs, NJ, [3] Javasoft. J2ee [4] C. Kerer and E. Kirda. Layout, Content and Logic Separation in Web Engineering. In 9th International World Wide Web Conference, 3rd Web Engineering Workshop, Amsterdam, Netherlands, May 2000, number 2016 in Lecture Notes in Computer Science, pages Springer Verlag, [5] E. Kirda, M. Jazayeri, C. Kerer, and M. Schranz. Experiences in Engineering Flexible Web Services. IEEE Multimedia, January - March [6] E. Kirda and C. Kerer. MyXML Home Page, [7] Macromedia. Dreamweaver [8] T. A. X. Project. Xerces [9] C. A. Quinn. From Grass Roots to Corporate Image - The Maturation of the Web. In Proceedings of the 2nd International World Wide Web Conference, Chicago, Illinois, USA, October 1994, October [10] H. Rawat, S. Schumann, C. Scollo, J. M. Castagnetto, and D. T. Valiath. Professional PHP Programming. Wrox Press. Incorporated ISBN: , [11] R. H. Richard Anderson, Alex Homer and D. Sussman. A Preview of Active Server Pages+. Wrox Press, [12] L. Rosenfeld and P. Morville. Information Architecture for the World Wide Web. O Reilly & Associates, February [13] M. Schranz. Vienna International Festival (Wiener Festwochen) 1996 managing culture on the WWW. In Proceedings of Museums and the Web: An International Conference, Los Angeles, California, March [14] M. W. Schranz. Engineering Flexible World Wide Web Services. In Proceedings of Symposium on Applied Computing (SAC), Atlanta, Georgia, February 1998, page 80, February [15] M. W. Schranz. Management process of WWW services: an Experience Report. In Proceedings of the 9 International Conference on Software Engineering and Knowledge Engineering (SEKE 97), Madrid, Spain, pages Knowledge Systems Institute, June [16] W3C. Extensible Markup Language (XML) 1.0 Recommendation Technical report, Feb [17] W3C. extensible Stylesheet Language 1.0 Recommendation Technical report, Jan [18] W3C. XML Schema Part I and II working groups and Technical report, Sep [19] W3C. XML Specification DTD htm. Technical report, Sep