XML and Hypermedia Applications - CiteSeerX

6 downloads 334 Views 158KB Size Report
This is the case with and ... links: (1) simple, similar to HTML links, pointing to a single resource1 and (2) extended, which associates.
XML and Hypermedia Applications Denilson Barbosa - CSC2524S 2000 Project Abstract There has been a lot of criticism on the World Wide Web and its incapacity of properly representing hypermedia content. On the other hand, new standardization efforts are being carried out by the WWW Consortium to enrich the semantics of the Web and provide better hypermedia and structure awareness. Notably, the Extensible Markup Language (XML) has received considerable attention from both researchers and application developers. In this paper we present an example of a Web site developed in XML and point out some advantages of using this new technology. We focus our attention in authoring Web sites and in data integration applications. We point out the main problems faced by hypermedia authors using current HTML technology and how those problems are addressed in the XML framework. We also outline briefly how traditional hypermedia design methods can be tailored to use XML as underlying markup language.

1

Introduction

The World Wide Web (the Web, for short) was designed to support the creation of and access to hypertext content, independently of computing platforms [BCL+94]. This would be accomplished by the use of a common language for hypertext encoding, the Hypertext Markup Language (HTML). The motivation for this effort was to enable a group of scientist and engineers to exchange data as they advanced in their research. A decade later, the Web has turned out to be the most popular application and the driving force on top of the biggest computer network ever built. The Web is now an independent entity, it has its own standards, protocols, applications and etiquette. It has also evolved from a pure hypertext nature to provide access to multimedia content, even live streaming media. The Web has changed the way people use computers. They no longer need calculators. Instead, they need to communicate. Open Hypermedia Systems (OHS) has been an active research field for some time. The main goal being to provide hypermedia facilities to a variety of applications in the same computing environment. The Web meets most of the requirements of such systems and is considered, by some, to be the most successful and obvious example of a hypermedia system [WN99]. This opinion is not shared by all researchers in the field, however. It is also argued that the Web is not even a hypermedia system, leave alone an OHS. Although there is evidence that OHS can be integrated with the Web [And97], there is still work to be done for properly unifying these technologies. Researchers in these areas simply have different interpretation on what is hypermedia [NA99]. Two main criticisms to the HTML language are the lack of extensibility and its incapacity of representing structured content. Therefore authors are tied to a fixed set of tags – with pre-defined semantics – and cannot represent structured content appropriately. This is a severe drawback when compared with OHS, in which structure is as important as data, or even more important [NLS97]. Also, links in the Web are rather limited when compared to the original concept earlier defined by hypermedia researchers. Those limitations have been the major obstacles in unifying the efforts endured by both communities. Recently, a new standardization effort was started by the World Wide Web Consortium [W3C], which is the body that dictates what the Web is and will be. The goal is to provide a set of standards to alleviate the problems outlined above. The first step was to define a new markup language – the Extensible Markup Language (XML) [BPS98] – to allow users to define their own tags in the document. Then, other languages were created (using XML) to standardize other applications and operations over XML content. Examples are XSL (Extensible Stylesheet Language), used to define the rendering of documents on screen, and XLink, used to specify links in XML documents. One good introductory reference on XML, its uses and the rationale behind it can be found in [Bos97].

1

(a) members of the group (people.xml)

(a) seminars sponsored (seminars.xml)

Figure 1 – The Example Web site implemented. XML documents can have fairly complex structures also. In fact, XML has been used as a medium for data exchange among database applications due to its ability to represented structured data. A more recent effort from the W3C XML Working Group is to enable rich data manipulation in XML content, much like as can be done in traditional databases. Given the greater structural awareness provided, traditional hypermedia design methodologies can be applied with XML as underlying data format. For many individual reasons, one can consider XML a step forward in closing the gap between Web and OHS technologies. In this work we show, trough a simple example, how XML is used in practice to develop a Web site. Since XML is still in its infancy, many of its features are not yet supported by the current generation of browsers and could not be implemented in this small prototype. This article is organized as follows. Section 2 describes the prototype implemented, Section 3 discusses the main aspects of the XML technology, including some currently under development standards. A discussion on how XML relates to OHS is presented in Section 4. Section 5 briefly outlines how current design methodologies can be modified to use XML and, finally, our conclusions together with some suggestions for future work are presented in Section 6.

2

The Example Web Site

We implemented some parts of the University of Toronto Database Group Web page in XML to have an experience in authoring sites using this technology. We chose this site due to its relative complexity and uniformity in its content. This site contains an initial page, describing briefly the group, and four pages listing the people involved in the group, the projects, the courses offered and seminars sponsored by the group and, finally, a page with database research related links. We chose not to implement the introductory and the links pages, since they contain few structured data. We decided to use the layout of the original page, since our main interest is on authoring and not in presentation issues. Thus, also used very simple rendering instructions. Figure 1 shows two screenshots of the site. Figure 1(a) shows the members of the database group. We kept the same structure in the original site and listed all members in a single page. The document is divided into sections, according to the type of member being listed (e.g. faculty, student, etc). Figure 1(b) shows the page listing the seminars sponsored by the database group. This page also has a simple formatting, slightly different than the original HTML version. It is easy to notice the lack of uniformity in the formatting of the original page. This happens because the author has to repeat the same markup instructions for each individual entity in the page. In

2

XML, the rendering instructions are specified only once (this process will be explained in Section 3.3), therefore the formatting is much more uniform. In the new version we added also a “Table of Contents” section. The original HTML Web site can found at http://www.cs.toronto.edu/db and the XML version at http://www.cs.toronto.edu/~dmb/xml/dbpage/. From this directory, there is a HTML front-end (just to draw the frame structure) called dbpage.html. From this folder is possible to access the XML files (in the xml directory), the DTDs (in the dtd directory) and the rendering instructions (in the style directory). As previously mentioned, current generation of Web browsers do not provide adequate support to XML technology. When developing this project we used the Microsoft Internet Explorer 5.0, which implements a substantial subset of the standards.

3

XML Technology

One of the main criticisms to HTML is the use of a pre-defined and limited set of tags for describing the documents. This limits the authors to map the original content of their documents to the available tags. There are two main drawbacks to this approach: (1) it is difficult for authors to isolate the content from the presentation markup and (2) data interchange among applications is very difficult. Isolating the content from the presentation is a very important issue since it allows the same content to be accessed in different presentation formats (e.g. different typesetting). Another problem with current technology is that changes in the formatting of the documents may require the whole site to be rewritten, clearly, an undesirable requirement. The Web has become the preferred channel for information dissemination. However, with the vast amount of data available online, it is imperative that applications be capable of exchanging information in a controlled and unambiguous way. Today, applications that read data from the Web must contain a “screen scrapping” component (a wrapper) that extracts the data from the HTML documents. This ad-hoc extraction can be very complex and error prone, depending on the source. Moreover, different Web sites require different wrappers. Changes in a particular source require the corresponding wrapper to be modified accordingly. Figure 2(a) shows an HTML code fragment describing a faculty member in our example Web site. Faculty data is shown in a table, one member per row. For each member, a link to his/her webpage (the name is the link marker) in the first cell and a short paragraph describing his/her research interests in the next cell. From an authoring point of view, this approach is bad because the author is forced to fit the content within the table definition markup. If, for instance, the authors decides to present the same data in a bulleted list, instead of the table, then he may be forced to restructure all documents in the site. ... ...
Anthony J. Bonner Database systems, information systems, knowledge base systems, database theory, logic programming, computational biology, genome mapping and sequencing, genome databases.


Anthony J. Bonner Database systems, information systems, knowledge base systems, database theory, logic programming, computational biology, genome mapping and sequencing, genome databases http://www.cs.toronto.edu/~bonner ...

(a) HTML encoding

(b) XML encoding

Figure 2 – HTML and XML encodings of a faculty member.

3



people

faculty

...

student

...

name name

webpage ... “Periklis Andritsos”

research “Anthony Bonner”

“http://...” “Database Systems...”

(a) DTD for people.xml

(b) people.xml

Figure 3 – Tree structure of an XML document.

From a data integration perspective, this approach is not good either. When this document is rendered in a user browser it is clear (to the human viewer) that the paragraph at the right of the name describes the research interests of the faculty member. However, for a program reading this HTML fragment, the only visible structures are cells, rows and a table. The only association between the faculty member and his research interests is that they are presented in adjacent cells in the same table row. The same problem applies to the link. We know the marker of the link, but we don’t know its semantics (e.g. a personal page, an email address, etc.). A wrapper to this piece of data will have to map this tabular structure into the desired format using the extra semantic knowledge, provided by a human reader when coding the extraction program. In Figure 2(b) we show the XML counterpart for this example. Note the new tags defined. Now, we have clearly specified that a member has a , interests and a . It is easy for a program to uniquely interpret this document. For authors, this approach is also interesting since there is no need to worry about presentation details when writing the documents.

3.1

Specifying the Structure of the Documents

The structure of any XML document is a tree, and, as outlined above, documents can have user-defined tags, including nested tags. In the example of Figure 2(b), the root element is . HTML documents also have a tree structure, the tag being the root element. Since there is no fixed set of tags (nor nesting rules), we need some mechanism to define the structure and check the validity of documents. A Document Type Definition (DTD) is a context-free grammar that defines the structure of a class of documents. Once we have a DTD, it is easy to verify whether a given document is well formed or not. A simple parsing of the document can do this checking. Figure 3(a) shows the DTD used in the example for representing the people original page. Note there can be only one element, inside which there can be zero or many (denoted by the * symbol) elements, followed by zero or many elements, and so on. The order of the elements in a document is relevant. Figure 3(b) sketches the people.xml document in its tree structure. We can also define elements that are optional (denoted by the ? symbol). This is the case with and elements for . We specify elements which content is text with the reserved keyword #PCDATA (parsed character data). Elements can also have attributes, normally used to qualify an element (e.g. a currency attribute in a price element). Attributes can be used to uniquely identify elements within the document. This is done by defining the attribute as of ID type (see the id attribute of elements). There are also IDREF and

4

xlink:href="projects.xml" xlink:role="projectlist" xlink:title="Project List"> Current Projects



(a) simple link to another document

(b) extended link with a faculty member and his students

Figure 4 – Representing links with XLink and XPointer. attributes, used to reference, respectively, an element and a list of elements in the same document. For more on XML data model, refer to [ABS99].

IDREFS

3.2

Representing Links

Many hypermedia researchers criticize the way HTML links are defined. One problem with HTML links is that they are unidirectional. This is a severe restriction when compared with the original concept of link as defined by previous research. Another problem is that links in HTML are not first-class citizens, thus cannot be referenced by other links or stored in a database, for instance. With the links stored in a database, it is easy to check for link consistency. This is not possible with the current Web technology. The XLink standard [DMO+00] is intended to solve both problems listed above. It defines two kinds of links: (1) simple, similar to HTML links, pointing to a single resource1 and (2) extended, which associates an arbitrary number of resources. Linked resources may be remote or local to the document in which the link is specified. Links are specified as elements inside the XML document, and, like any other element, they can be referenced, accessed and even pointed to by another link. It is also possible to have an independent document specifying all the links of a given application. In this case, link integrity can be checked in a straightforward manner. Figure 4(a) shows a simple (unidirectional) link in XLink. There are very few differences from HTML links to simple links in XLink. In this example, the link has two possible markers: “Current Projects”, which is the content of the element, and “Project List”, provided via the title attribute. It is up to the rendering application to choose which one is presented, according to the processing instructions given by the author. The extended link in Figure 4(b) is more interesting. In this link, three locators2 are defined: one pointing to a faculty member and the remaining two pointing to his students. Those links use the XPointer language for navigating inside XML documents and point to particular elements. For example, the markup #xpointer(id, ‘bonner’) tells the application to navigate the people.xml document and find the element that has ‘bonner’ as ID attribute, which we know is unique. The definition of the extended link in this example specifies only the resources that are associated. Different link markers for this link can be inserted in different documents (e.g. in each member’s web

1

An individual piece of data (e.g. a document, an element inside a document, an image, etc.).

2

Identify uniquely a resource in the Web.

5

Database Group Members

People



Faculty

NameResearch Topic Homepage


(a) creating the HTML document ... Homepage

Students

...

(b) matches the people element and creates the tables in the HTML document

(c) rendering instructions for a faculty member Figure 5 – XSL processing instructions. page), with different behaviors. For example, traversing this link from a student’s page may open a new window with the supervisor’s page; while doing so from the supervisor’s page may open a window with a list of his students. Evidently, the markers in each page would also be different. Note also that no titles are provided for the locators. This means that the rendering application has to choose how to present the markers (possibly accessing the documents and extracting the names of the members). Unfortunately, XLink and XPointer are not standards yet. Therefore, there is no support from current Web browsers. We could not use those languages in the implementation.

3.3

Document Rendering

An XML document is appropriate for data exchange among applications and may even be readable by humans, but it is clearly inadequate for any end-user application, without proper formatting. This happens because XML was designed to represent content, not presentation. In fact, the document has to be converted into a format that can be rendered by browsers and presented to the user. There are two current technologies to accomplish this task: (1) Cascading Stylesheets or (2) the Extensible Stylesheet Language (XSL) [ABC+00]. Cascading Stylesheets are used in XML in the same way as in HTML. A set of rendering instructions are associated with each tag, allowing the browser to properly render the document. This is somewhat limited, since the presentation is constrained by the structure of the document (e.g. the order of the elements has to be preserved). XSL, on the other hand, is a Turing-complete language, and can do much more involved processing. XSL works by “transforming” the document into another document, usually in HTML (note that an HTML document is also in XML), which can be rendered by browsers in a customary way. As mentioned earlier, XSL is an XML dialect. The instructions for rendering the people.xml document are sketched in Figure 5. The XSL processing is done by pattern matching on the elements with the processing rules. First, the processor applies the rule in Figure 5(a), which pattern (“/”) matches the document as a whole, and creates the basic HTML tags to define de title and start the body of the document. The command tells the XSL processor to recursively match and apply the templates for the elements in the document. Then, the

6

template of Figure 5(b) is applied, because it matches the root element (, in this case). This rule outputs more HTML markup and creates a table for listing the faculty members. The next command processed, , applies only for faculty members. For each one, a table row is created together with an internal anchor (whose label is the ID of the faculty) for document navigation in an HTML-like style, since XLink cannot be used yet. Note that, so far, no actual data has been output by these commands. This is done by the rules presented in Figure 5(c), that shows the processing of the and the elements. The command copies the value of the element (character data in this case) to the output document. For the Webpage of the faculty, the link maker is just “Homepage”, but it could be anything. When all faculty members are rendered, the XSL processor resumes when it left the template in Figure 5(b) and start processing student and other members of the document. These rules also apply for other members that have and elements, thus improving reusability. XSL includes definitions for inheriting and reusing rendering rules, yet not supported by Web browsers. In the examples above, very simple processing is done. But XSL is capable of complex manipulations and transformations in the data. In the database group Web site developed, the list of talks that appears at the beginning of the document was done using simple XSL commands. In this way, XSL can save time from authors, since content can be generated at presentation time. Although current Web sites are able to generate content dynamically (via database queries, for instance), this approach is still interesting, since the rendering processing is done by the client browser – thus alleviating the workload of the server. A few more things are worth mention here. First, the rendering instructions are completely independent from the content of the document. This allows different applications render the same data in different ways, thus, presenting the same content using different structures and abstractions. Also, changes in the presentation of the document are isolated thus diminishing the maintenance complexity of the site. XSL can also be used in an off-line mode. In this case, XSL processors are used to generate an HTML “snapshot” of the documents to be published using any Web server. XSL, like other XML technologies is not standardized yet. However, parts of the standard are supported by current generation of browsers.

3.4

Namespaces

Given the possibility of defining tags in a document, the probability of choosing a tag name that was also chosen by a different application in another context is very high. A typical scenario is when one wants to use external applications inside the document (e.g. multimedia content with SMIL [Hos98], or mathematical equations using MathML [IM99]), that already define tags with conflicting names with the ones being used in the document. Another scenario would be in data integration applications, when different sources use the same tag name with different meanings (e.g. title of a book and title of a person). In such situations, we need to distinguish the tags and their semantics uniquely. This is done in XML with Namespaces [BHL99]. A Namespace defines a set of names semantically correlated. To associate a name with a namespace we add a uniform resource identifier (URI) as a prefix to it. The URI identifies the Namespace and makes the (now qualified) name unique in the whole Web. For example, at the beginning of people.xsl (or any other XSL document), the declaration tells the processor (e.g. a Web browser) that any tag starting with xsl: belongs to the XSL namespace as defined by the W3C. The standard requires every processing instruction to start with this prefix. Therefore, the client application can uniquely interpret those tags, or even select an appropriate external component to do so.

4

XML and OHS

Open Hypermedia Systems are intended to provide hypermedia facilities to a variety of applications and computing platforms. This is achieved by the use of open technologies to enable interaction among applications, coupled with a set of standards that dictate how application interactions take place [WN99]. Currently, researchers are working on defining the structure of an OHS and standards for the interactions. 7

This is not an easy task, since it involves many different interests, interpretations and opinions. The Web is not a less hostile environment either. In this case the situation may be even worse, since the Web has no authoritative entity to decide what is allowed and what is not. Unifying efforts in these communities seems to be a non-trivial task [NA99]. It is argued that the use of established standards and open technologies are adequate solutions to achieving interoperability [PCC+98], which is the ultimate goal in both communities. XML is both a standard and an open technology. It is intended to be the core language of the Web, on top of which other applications are built. In this sense, XML is just a vehicle to enabling interoperability in the Web. Among other alternatives, specification-based interaction is a way of providing interoperability in distributed systems via publishing semantic descriptions of the components available in the system [PCC+98]. In this approach applications read the semantic description of other components to figure out how to proceed the interaction. In some sense, this is provided by Namespaces in XML. When a Namespace is defined, it can include a list of software that can process the data described by the tags registered in the Namespace.

4.1

Cross-Platform Interoperability

Cross-platform interoperability is a requirement for hypermedia systems, and also for Web applications. Today, there is already a high degree of interoperability in the Web, especially in what concerns to end user browsers. In other situations this is not the case (e.g. some streaming media players are not available for Unix workstations, for instance). There are many costs associated with the adoption of a new standard which have to be taken into account by developers. New components may have to be developed, personnel need to be trained and there might be some licensing costs also. For that matter, XML is a license-free, platform-independent family of standards, like other W3C recommendations. Therefore, one can expect it to be adopted by the majority of Web application development companies, in the same way HTML was accepted. Most of the XML software available today is either written in Java or has a Java version, which has a high degree of interoperability and portability itself. Most of this code can be even used under open source licenses, just like Java and other technologies. Also, there are already a number of important companies that are seriously committed with the development and support of XML applications. Examples are IBM (AlphaWorks series), Microsoft and Sun. Many database management systems have already support for XML data (e.g. IBM’s DB2, Oracle). These systems have ports to many platforms, which also increases the overall interoperability. One of the biggest motivations for companies like those above to adhere to XML is data exchange for electronic commerce. Therefore, one can expect many XML-enabled applications to be developed and deployed in the near future and an even bigger number of companies involved in this process. Therefore, cross platform interoperability should not be an issue for XML applications.

5

Using a Design Methodology with XML

Designing a hypermedia application is not an easy task and requires specific methodologies. Among others, the Relationship Management Model [ISB95] is a well-known methodology devised specifically to hypermedia applications design. Although this method was not conceived to develop Web applications, it can be tailored to do so. To accomplish this, it is enough to map the constructs and procedures in RMM to counterparts in the Web framework. In [BBP97] it is reported a port of RMM to a Web context, but using HTML as markup language. In that work, the content (e.g. HTML or PDF documents) is kept in a document management system and the structure of the site is held separately. The main advantage of this approach is that it allows adequate management of the structure and navigation of the site (since HTML is insufficient) while providing the high quality rendering offered by current browser technology. When a new version of the site is to be deployed, the structural definitions are mapped into HTML code and the links to the content are

8

materialized. Then, the documents are retrieved from the management system and the site is ready to be put in a server. This methodology could be adapted to XML very easily, just replacing HTML document by their XML counterparts (together with XSL, XLink, etc.). However, this would not take advantage of XML’s ability to represent and manipulate data. XML has a semistructured data model [ABS99], which is very flexible and can represent structured data as well. There is a considerable research effort undergoing now to enable adequate manipulation of XML documents, as in traditional databases. Therefore, instead of using a document management system to store the content, it will be better to use directly XML databases to represent the content and any other metadata required by the site. Note however, that describing a complete adaptation of the RMM to the XML framework is outside the scope of this work. We limit ourselves just to outline how this could be done.

5.1

Data Modeling

The RMM method uses a semantic data model similar to the Entity-Relationship model, very popular in database design methodologies. The model has four modeling primitives (entities, attributes, one-one associative relationships and one-many associative relationships). Entities represent real world objects (like persons) and attributes are atomic pieces of data used to describe individual entities. In an XML framework, one possible representation for entities would be to create a document for each entity in the real world. The attributes could be mapped into elements. Entity types are enforced by DTDs. In the database group site developed, the set of “Person” entities (faculty members, students, etc.) is represented in a single document. Yet another way of doing this would be to have individual documents for each entity type (one for faculty, other for students, etc.). Associative relationship primitives in RMM can be represented by attribute links in XML. There are special attributes used to uniquely identify elements in a document (ID attribute), reference a single element (IDREF attribute) or a list of elements (IDREFS attribute). In this way, one can, for instance, link all the students supervised by a given faculty member by just referencing to his/her ID attribute. Note, however, that possibly the best way of representing these semantic relationships in XML would be to devise a new dialect specifically to do this. The Slice primitive described in the RMM method is similar to a view in a database sense [EN94]. Views are expressed by queries, which determine which data should be included in the view. There are already some languages available for querying XML data [FSW99]. Give the importance to data manipulation, the W3C has just started a new working group to define a standard for querying XML data [FMR00].

5.2

Representing Navigation Aspects

The navigation aspects include the links in the hyperdocument, together with the specification of intended navigation accesses and patterns. As outlined above, links in XML are being designed specifically to allow the representation of complex links, as originally conceived by hypermedia researchers. Also, links are now promoted to “first-class” citizens, allowing a more detailed representation of the site and enabling better link management practices. As in the previous case, defining a new XML dialect for accurately representing the navigation of the site would possibly be the best way of achieving the desired functionality. Such a dialect would be built on top of current technology, therefore benefiting from work already done.

6

Conclusions and Future Work

The World Wide Web and the HTML language were designed to provide hypertext access to a variety of computing platforms. Although the Web and OHS share the same goals in principle, there is a considerable gap between these worlds. This gap is visible both in theory – due to different interpretations on basic hypermedia concepts – and also in practice. Web technologies have been seriously criticized by hypermedia researchers. XML is a simple and powerful language that concentrates the W3C efforts to

9

provide more semantically rich structures to the Web. Consequently, it is a clear advance in many aspects and closes the existing gap from OHS. In this work we showed through a simple example the use of XML technology in Web site development, given the support from current generation of browsers. The main advantages of XML when compared to HTML are presented considering both authoring and data integration applications – two of the most important applications of XML. Finally, we outlined how traditional hypermedia design methodologies could be used in conjunction with XML. Many advantages of such integration are outlined. Although XML is not yet completely formalized, the core of the language is already defined. There is work to be done in many different areas, including in the standardization effort itself. As an interesting future work we outline a full specification of the RMM method in XML, possibly with the definition of new specification languages. We believe this can be done even with the current state of technology. Also, the use of XML in data integration applications is a current research topic and still has many open problems. Finally, there is still the problem of accessing currently available HTML (and other legacy formats) content with XML applications. This is not a trivial problem and is also an active research topic in the database community.

References [ABC+00]

Sharon Adler , Anders Berglund , Jeff Caruso (Bitstream), Stephen Deach, Paul Grosso, Eduardo Gutentag , Alex Milowski, Scott Parnell, Jeremy Richman, Steve Zilles. Extensible Stylesheet Language (XSL) Version 1.0. W3C Working Draft. 27 March, 2000. Available at http://www.w3.org/TR/xsl/

[ABS99]

Serge Abiteboul, Peter Buneman and Dan Suciu. Data on the Web: From relations to semistructured data and XML. Morgan Kaufmann. 1999.

[And97]

Kenneth M.Anderson. Integrating open hypermedia systems with the World Wide Web. Proceedings of the eighth ACM conference on Hypertext, pages 157-166, Southampton United Kingdom, April 6 - 11, 1997.

[BBP97]

V. Balasubramanian, Alf Bashian and Daniel Porcher. A large-scale hypermedia application using document management and Web technologies. Proceedings of the eighth ACM conference on Hypertext, pages 134-145, Southampton United Kingdom, April 6 - 11, 1997.

[BCL+94]

Tim Berners-Lee, Robert Cailliau, Ari Luotonen, Henrik Frystyk Nielsen and Arthur Secret. The World-Wide Web. Communications of the ACM, 37(8): 76-82. 1994.

[BHL99]

Tim Bray, Dave Hollander and Andrew Layman (eds.). Namespaces in XML. W3C Recommendation. 1999. Available at http://www.w3.org/TR/REC-xml-names/

[Bos97]

Jon Bosak. XML, Java, and the future of the Web. World Wide Web Journal, 2(4): 219-227. 1997. Available at http://metalab.unc.edu/pub/sun-info/standards/xml/why/xmlapps.htm

[BPS98]

Tim Bray, Jean Paoli and C. M. Sperberg-McQueen (eds.). Extensible Markup Language (XML) 1.0. W3C Recommendation. 1998. Available at http://www.w3.org/TR/1998/RECxml-19980210

[DMO+00] Steve DeRose, Eve Maler, David Orchard and Ben Trafford (eds.). XML Linking Language (XLink). W3C Working Draft 21-February-2000. [EN94]

Ramez Elmasri and Shamkant B. Navathe. Addison-Wesley Pub Co, 1994.

[FMR00]

Peter Fankhauser, Massimo Marchiori, Jonathan Robie. XML Query Requirements. W3C Working Draft 31 January 2000. Available at http://www.w3.org/TR/xmlquery-req

[FSW99]

mary Fernandez, Jérôme Siméon and Philip Wadler. XML query languages: experiences and exemplars. Available at: http://www.w3.org/1999/09/ql/docs/xquery.html

10

Fundamentals of Database Systems.

[Hos98]

Philipp Hoschka (ed). Synchronized Multimedia Integration Language (SMIL) 1.0 Specification. W3C Recommendation.1998. Available at http://www.w3.org/TR/REC-smil/

[IM99]

Patrick Ion and Robert Miner. Mathematical Markup Language (MathML) 1.01 Specification. W3C Recommendation.1999. Available at http://www.w3.org/TR/RECMathML/

[ISB95]

Tomás Isakowitz, Edward Stohr and P. Balasubramanian. RMM: A methodology for structured hypermedia design. Communications of the ACM, 38(8): 34-44. 1995

[NA99]

Peter J.Nürnberg, and Helen Ashman. What was the question? Reconciling open hypermedia and World Wide Web research. Proceedings of Hypertext '99 on Hypertext and Hypermedia, pages 83-90. , Darmstadt Germany, February 21 - 25, 1999.

[NLS97]

Peter J.Nürnberg, John J.Leggett, and Erich R.Schneider. As we should have thought. Proceedings of the eighth ACM conference on Hypertext, pages 96-101, Southampton United Kingdom, April 6 - 11, 1997.

[PCC+98]

Andreas Paepcke, Chen-Chuan, K. Chang, Héctor García-Molina and Terry Winograd. Interoperability for Digital Libraries Worldwide. Communications of the ACM, 41(4):33-43. 1998

[W3C]

World Wide Web Consortium. http://www.w3c.org

[Wii97]

Uffe Kock Wiil. Open hypermedia: Systems, interoperability and standards. Journal of Digital Information, 1(2), 1997.

[WN99]

Uffe K. Wiil and Peter J. Nürnberg. Evolving hypermedia middleware services: lessons and observations. Proceedings of the 1999 ACM symposium on Applied Computing. September 23 - 26, 1999.

11