Department of Computer Science
Central Washington University
400 East University Way
Ellensburg, WA 98926-7520

Technical Report

Using XML and SVG to Generate Dynamic UML Diagrams

Authors: Justin Elsberry and Nicholas Elsberry

Faculty Advisor: Dr. Ed Gellenbeck

March 2003

Department of Computer Science
Central Washington University

Abstract

This report documents research conducted to demonstrate the power of the Extensible Markup Language (XML) to create dynamic Unified Modeling Language (UML) diagrams. The components of the UML design are represented as XML data and then transformed into UML diagrams represented as dynamic Scalable Vector Graphic (SVG) images. The project included the creation of a web-based tool to allow users the ability to create and manipulate these diagrams without any knowledge of XML or SVG.

Introduction

This technical report documents research that documents the power of the Extensible Markup Language (XML). This is demonstrated through the dynamic modeling of software using the Unified Modeling Language (UML).

Work on this project began in September of 2002 in preparation for a poster presentation at the 2002 Fourth Annual Consortium for Computing Sciences in Colleges Northwest Regional Conference. Work began under the supervision of Dr. Ed Gellenbeck with two students: Justin Elsberry and Nicholas Elsberry. Preliminary results were presented in a student poster session at the conference. Work continued during the next two quarters as a CS 496 independent study course and with the addition of another student, Tammie Correll.

The content of this report begins with an introduction to the key technologies used throughout the project. The next section outlines the process used to generate dynamic UML diagrams. Following that is a section describing the results of the project. The document then concludes with a description of the benefits from this technology and a look at possible future work in this area.

Technologies Used

The Unified Modeling Language (UML)

The Unified Modeling Language (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the design and structure of software systems. It simplifies the process of software engineering by providing a blueprint for construction. Modeling is an essential process, especially for complex software systems, that ensures the completeness and correctness of a system [3].

History

In 1994, James Rumbaugh joined Grady Booch at Rational Software and they began work merging the two very popular Booch and OMT methods together. Later, in 1995, Ivar Jacobson joined them and they continued unifying their methods into the UML. Rational submitted their UML to the Object Management Group (OMG) as a proposal for standardization in 1997. Soon after submission, the OMG adopted the UML as an official standard for modeling software systems [2].

UML Diagrams

The UML specification defines twelve diagrams divided into three categories: structural, behavioral, and model management diagrams. This research focused mainly on representing two diagrams, use case and class diagrams.

Use Case Diagram
Figure 1: Sample Use Case Diagram

Use case diagrams (Figure 1) are classified as behavioral diagrams. They describe a sequence of events that are performed by external actors to accomplish a given task within the system. The use case diagram is used in determining system requirements. Developing a use case diagram involves identifying the people (or other systems) that will be interacting with the system, known as actors. After identifying the actors, use cases are created to identify how actors interact with the system.

Scenarios are often an important part of developing use cases; however, scenarios are not currently in the official OMG UML standard. Scenarios describe the flow of events when executing a use case. A normal flow of events is developed that describes the flow if execution performs exactly as desired. Any exceptions to the normal flow of events are described in alternate scenarios [1].

Class Diagram
Figure 2: Sample Class Diagram

From the structural diagram category, class diagrams (Figure 2) represent the static structure of a system in terms of collections of objects known as classes. Since class diagrams are static, they do not describe any behavior in the system. Classes contain attributes and operations. Attributes describe the structure of a class, and operations provide the behavior of the class. Relationships represent the communication between classes in the system.

Extensible Markup Language (XML)

Tim Berners-Lee, inventor of the World Wide Web, envisioned a web where information could be meaningfully manipulated by machines rather than humans. This “web of tomorrow” will enable machines to carry out complex tasks for the user automatically, creating a more useful and universally accessible web. A foundation for the Semantic Web has already been laid with the help of the Extensible Markup Language (XML) [4].

Overview

The World Wide Web Consortium (W3C) defines XML as a subset of the Standard Generalized Markup Language (SGML) whose goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML. [5] SGML (ISO 8879) has been an international standard since 1986 and is a meta language for specifying how to describe the structure or markup of a language. XML is a much simpler subset of SGML yet it still maintains its power and flexibility while adding ease of use which SGML lacks [6].

The development of XML began at the W3C in 1996 and became a formal W3C recommendation in February of 1998. Version 1.0 of the specification was amended in November of 2002 and version 1.1 is currently a candidate recommendation of the W3C.

XML is similar to HTML in that they both use tags and attributes. Tags in XML are just words surrounded by < > brackets that describe the structure of the document. Attributes are name/value pairs that are contained within the start tag. In XML, an element is everything from the start tag until the end tag including the data contained within. HTML has predefined tags and attributes; whereas XML is extensible - you can define as many tags and attributes as you wish. With XML, content and presentation are separate, XML tags only describe the content with which they hold and not how to display them as is the case with HTML.

In order for an XML document to be valid it must be well-formed, it must satisfy four main conditions: (1) each document must consist of a unique root tag, (2) start and end tags must match, (3) elements cannot overlap, and (4) tags are case-sensitive.

    1   <?xml version="1.0"?>
    2   <library>
    3     <book>
    4        <title>Learning XML</title>
    5        <subject>XML</subject>
    6        <author>Erik T. Ray</author>
    7        <author>Christopher R. Maden</author>
    8        <isbn>0596000464</isbn>
    9      </book>
    10  </library>

Figure 3: Simple well-formed XML document

Figure 3 above is an example of a simple XML document for a library catalog system. It is well-formed because it contains only one root tag, the <library> tag, all of the start and end tags match, the case is consistent and there are no overlapping elements. You may have as many of the other elements as you need, for example, you would most likely have more than one book in your library or as in the case above more than one author for a specific book.

XML Schemas

“XML Schemas express shared vocabularies and allow machines to carry out rules made by people. They provide a means for defining the structure, content and semantics of XML documents” [7]. XML documents are validated against the schema to check for the correct structure and to verify that they are well-formed. Figure 4 below is a sample schema for our hypothetical library catalog system.


1  <?xml version="1.0"?>
2  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
3    <xs:element name="library">
4        <xs:complexType>
5            <xs:sequence>
6                <xs:element name="book" type="bookType" minOccurs="1" maxOccurs="unbounded" />
7            </xs:sequence>
8       </xs:complexType>
9    </xs:element>
10   <xs:complexType name="bookType">    
11     <xs:sequence>
12       <xs:element name="title" type="xs:string" minOccurs="1"  />
13       <xs:element name="subject" type="xs:string" minOccurs="0" maxOccurs="unbounded" 14/>
15       <xs:element name="author" type="xs:string" minOccurs="1" maxOccurs="unbounded" />
16       <xs:element name="isbn" type="xs:decimal" minOccurs="1"  />
17     </xs:sequence>
18   </xs:complexType>
19  </xs:schema>

Figure 4: Simple XML Schema

As you can see, the root library tag is an element consisting of one or more books; each book consists of a single title, zero or more subjects, one or more authors and a single ISBN number.

Extensible Stylesheet Language Transformation (XSLT)

Since content and presentation are separate in XML, it is possible to display the same data in a variety of formats, for example, XHTML, SVG, PDF, etc. This is achieved through the use of Extensible Stylesheet Language Transformations (XSLT). An XML document is transformed by matching elements from the XML file to patterns and then associating those patterns with templates defined in the XSLT file.

1  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
2                                                 xmlns="http://www.w3.org/1999/xhtml">
3  <xsl:output method="xml" indent="yes" omit-xml-declaration="no"
4                   doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
5                   doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN" />
6   <xsl:template match="/">
7        <html>
8           <head><title>Sample Library Catalog System</title></head>
9           <body>
10               <table border="1" summary="List of books in the library"> <thead>
11                       <tr><th>Title</th><th>Author(s)</th><th>Subject(s)</th><th>ISBN</th></tr></thead>
12                   <tbody>
13                       <xsl:for-each select="/library/book"><xsl:apply-templates select="." /></xsl:for-each>
14                  </tbody></table>
15           </body>
16        </html>
17    </xsl:template>
18    <xsl:template match="book">
19        <tr><td><strong><xsl:value-of select="title" /></strong></td>
20        <td><xsl:for-each select="author"><xsl:value-of select="." /><br /></xsl:for-each></td>
21        <td><xsl:for-each select="subject"><xsl:value-of select="." /><br /> </xsl:for-each></td>
22        <td><xsl:value-of select="isbn" /></td></tr>
23    </xsl:template>
24  </xsl:stylesheet>

Figure 5: Simple XSLT file

The first template in Figure 5 above (line 6) matches the root node, and creates the head and body sections of the XHTML page along with a table for all of the books. Next the for-each loop creates a new row in the table for each book found. The next template (line 20) matches the book element and creates columns for the title, author(s), subject(s) and the ISBN number.

Scalable Vector Graphics

Scalable Vector Graphics (SVG) is a child language of XML that allows for the visual representation of textual data. Much like Hypertext Markup Language (HTML), SVG has beginning, ending, and nested tags that define how data is displayed. For example, Figure 6 contains the SVG code required to create the simple circles shown in Figure 7.

1  <svg xmlns="http://www.w3.org/2000/svg">
2   <circle cx="100" cy="100" r="50" fill="black" />
3   <circle cx="210" cy="100" r="50" fill="white" stroke="black" />
4  </svg>

Figure 6: Simple SVG code

Circles
Figure 7: Simple SVG circles

SVG is not limited to static images. “SVG drawings can be interactive and dynamic. Animations can be defined and triggered either declaratively (i.e., by embedding SVG animation elements in SVG content) or via scripting” [10]. Using JavaScript with the SVG Document Object Model (SVG DOM) we were to create interactive diagrams where the user can layout the diagram as they desire.

SVG was selected as the method for visual representation because XML data can be easily transformed into SVG code. SVG code is displayed using vectors, which makes SVG powerful in that it can be zoomed in and out without any loss of clarity or pixilation as would occur in a bitmap or jpeg image. In addition, SVG being represented as text, has a small file size making it appropriate for delivery over the Internet.

The Process Used to Generate UML Diagrams

The development of use case and class diagrams followed the same general process. This process included developing an (1) XML Schema, a (2) sample XML data file and the (3) transformation stylesheet. The execution of the transformation also followed a general process (Figure 10), which included validating the XML data file against the XML Schema for the diagram, the validated data is then transformed using the stylesheet and displayed to the user through SVG and any other format necessary.

process diagram
Figure 8: The process

The Schema

In developing a schema for a specific UML diagram, the structure of each element in the diagram is detailed. For example, use case diagrams include a system, actors, use cases and relationships. Each of these elements has specific requirements, such as an actor (Figure 11) consists of a name, and the use cases with which they interact. To assist in the automatic generation of the diagram, an actor ID uniquely identifies each actor in the system and a summary of the actor is provided.

1  <xs:complexType name="actorType">
2    <xs:sequence>
3      <xs:element name="name" type="xs:string" minOccurs="1"  />
4      <xs:element name="summary" type="xs:string" minOccurs="0 " />
5       <xs:element name="initiates" type="xs:IDREF" minOccurs="0" maxOccurs="unbounded" />
6    </xs:sequence>
7    <xs:attribute name="actorID" type="xs:ID" use="required" />
8  </xs:complexType>

Figure 9: Use case actor schema element

The schema ensures that translation to the display format is correct by specifying where an element may occur, what type it may be, and how many of that element may be present. For example, an actor must include a name, so the element is defined as required whereas the summary is not a required element and therefore is defined as optional.

The Sample XML Data File

Having sample XML data at this stage is important to test the schema and the provide input during development of the stylesheet. After the schema is completed, it is used to construct a sample XML data file. A UML diagram is broken down into its composite elements and described using the newly created XML grammar. For example, following the ATM diagram example provided in Appendix A, an entry for the customer actor is created. This actor is named customer, has a summary of Bank ATM customer, and indicates that it initiates the withdrawMoney use case. Based on this information, the stylesheet will know how to display the customer actor and the relationship between this actor and the withdrawMoney use case it initiates.

1  <actor actorID="customer">
2    <name>Customer</name>
3    <summary>Bank ATM customer</summary>
4    <initiates>withdrawMoney</initiates>
5  </actor>

Figure 10 - Sample XML data

Once created, the sample file is validated against the schema to ensure well-formedness and grammatical validity. If any of the elements appear out of sequence or required elements or attributes are not specified, the XML file will not validate against the schema.

XSL Transformations

To utilize the power of XML we were able to use XSL Transformations to generate dynamic XHTML and SVG code from an XML document. For the most part, the same techniques were employed in the creation of both UML Use Case diagrams and Class Diagrams. For the purpose of this discussion I will focus primarily on the creation of Class Diagrams because they are more complex and detailed than the Use Case diagrams.

The Class Diagrams are generated dynamically through the use of XSL Transformations. The XSLT file specifies patterns that when matched in the XML document, are associated to templates in the XSLT file. For example, every time the XSLT were to encounter a class tag in the XML document it would generate the code from the class template as shown in Figure 13. The template is passed three parameters: the name of the class, the position of the class on the x-axis and the position of the class on the y-axis. The two position parameters are calculated based on the position of each class in the XML document.

1  <xsl:for-each select="/uml/classDiagram/class">
2      <xsl:apply-templates select=".">
3          <xsl:with-param name="className" select="name" />
4          <xsl:with-param name="xOffset" select="(position() mod 3) * 250 + 130" />
5           <xsl:with-param name="yOffset"
6                                    select="format-number(((position()+1) div 3), '#') * 350 - 350 + 10" />
7      </xsl:apply-templates>
8  </xsl:for-each> 

Figure 11: XSLT loop for UML Class tag

The class template contains the SVG markup to display each class when the template is invoked. Additional matching of child element is done in the class template as well. Figure 14 contains a portion of the code from the class template. A group element is positioned around the entire class so that it may be moved as one item. The x and y attributes of both the rectangles and the path, is dynamic from the parameters we passed to the template as shown earlier in Figure 13.

1  <g id="{@classID}" onmousedown="mouseDown()">
2    <rect x="{$xOffset}" y="{$yOffset}" width="200" height="30" fill="#336699" stroke="#000000"
3              stroke-width="2px" />
4    <path id="be-{@classID}" d="M {$xOffset} {$yOffset + 30} L {$xOffset + 200} {$yOffset + 30}" /> 
5    <text text-anchor="middle" font-family="Verdana" font-size="12" fill="#FFFFFF" stroke="none">
6        <textPath xlink:href="#be-{@classID}" startOffset="50%" dy="-10">
7            <xsl:value-of select="@classID" />
8        </textPath>
9     </text>
10    <rect id="rec-{@classID}" x="{$xOffset}" y="{$yOffset + 30}" width="200" height="{$classSize}"
11              fill="#FFFFFF" stroke="#000000" stroke-width="2px" />

Figure 12: Portion of XSLT class template

In addition to generating SVG code to display the diagrams, JavaScript code is also generated to aid the user in positioning the classes through dragging and dropping. The JavaScript also provides access to controls used to zoom in and out, or to pan the diagram. Access to the elements in the SVG document once transformed is provided through the SVG Document Object Model (SVG DOM). The SVG DOM enables us to select individual elements or groups of elements in order to modify their position or properties.

Figure 15 is a section of JavaScript code that allows the user to drag the classes around in the diagram.

1  function mouseDown () 
2  {
3    target = get_target(evt);
4    target.style.setProperty('opacity', '0.5');
5    root.removeChild(target);
6    root.appendChild(target);
7    var matrix = target.getCTM();
8    var mouse = getMouse(evt);
9    offset.x = matrix.e - mouse.x;
10   offset.y = matrix.f - mouse.y;
11   togglePointerEvents("down");
12 }

Figure 13: JavaScript code used to drag class

The Results

Use Case Diagrams

Layout

It was determined that the easiest way to layout the use case diagrams was in a simple row format. This layout choice was made with the assumption that the number of use cases being diagrammed would not be massive. Each use case is placed in its own row, if one customer initiates multiple use cases the customer is repeated for each use case. The actor that initiates the use case is placed to the left of the use case and any supporting actors are placed to the right. All relationships with the primary use case are presented by linking the use cases with a line to the center of the primary use case (Figure 16).

The scenarios that accompany the use case diagram are created in XHTML and laid out in a simple table (Appendix A), they are accessed from the diagram by clicking on a use case ellipse. Images represent the design scope and the goal level of the use case as described by Alistair Cockburn [1].

Use case diagram
Figure 14: Use case diagram layout

Problems

It was clear in the development of the use case diagrams that with the current layout technique, the number of elements used affects the clarity and usefulness of the diagram. For example, it is apparent in Figure 17 that the presence of four relationships significantly decreases the clearness of the diagram. The relationships connect to the center of the primary use case; this produces a clutter of lines and arrowheads if many relationships exist. Because different style arrowheads are used for each type of relationship, it is more difficult to determine the type. It may have been more effective to position the use cases in this manner, and then allow the user to manually move the use cases for a more readable representation.

UML Use Case Diagram
Figure 15: Use case diagram layout with many relationships

Use case diagrams were our first attempt at dynamic generation of diagrams and therefore some of the techniques used could have been refined for more a more efficient generation of diagrams. For example, Figure 18 is the code that creates the actor stick figure, this code was placed in a loop through all actors in the XML file; however, a better method would have been to create a definition of an actor at the beginning of the SVG and position each actor by simply translating the definition to the appropriate coordinates. Many improvements came in generating class diagrams; these improvements could also be applied to the use case diagrams to increase their usefulness.

1  <!-- Actor Group -->
2  <g id="actor{$gid}" onmouseover="showInfo(evt,'actorHover{$gid}')"
3                                onmouseout="hideInfo(evt,'actorHover{$gid}')">
4  <!-- Actor's name -->
5  <text x="{$xOffset}" y="{$yOffset + 70}" style="fill:black; stroke: none; font-size:12; text-anchor: middle;">
6    <xsl:value-of select="//actor[@actorID = $varInitiator]/name" />
7  </text>
8  <!-- Actor's head -->
9  <circle cx="{$xOffset}" cy="{$yOffset}" r="10" />
10  <!-- Actor's body -->
11  <line x1="{$xOffset}" y1="{$yOffset + 10}" x2="{$xOffset}" y2="{$yOffset + 35}" />
12  <!-- Actor's arms -->
13  <line x1="{$xOffset - 15}" y1="{$yOffset + 20}" x2="{$xOffset + 15}" y2="{$yOffset + 20}" />
14  <!-- Actor's right leg -->
15  <line x1="{$xOffset}" y1="{$yOffset + 35}" x2="{$xOffset + 10}" y2="{$yOffset + 55}" />
16  <!-- Actor's left leg -->
17  <line x1="{$xOffset}" y1="{$yOffset + 35}" x2="{$xOffset - 10}" y2="{$yOffset + 55}" />
18  </g>

Figure 16: Use case actor code

Class Diagrams

Layout

Due to the potential complexity and large size of a Class Diagram a large amount of thought was put into the best way to automatically position the classes. Problems arise when trying to position the classes so that relationships between them are accurately depicted and to avoid a cluttered image.

There were two solutions that our team considered implementing in detail. First, we considered laying the classes out in a radial formation, the class with the most relationships would be at the center of the circle (Figure 19). Each layer thereafter would be arranged around that class, so classes with a direct relationship would be placed on the next layer and so on. The classes in each layer would be staggered to allow relationships to cross between to layers. This solution would produce a fairly clean diagram most of the time. However, determining the complexity of each class based on its relationships would take additional server processing and would not necessarily account for all layout issues.

radial layout
Figure 17: Radial layout

Next, we considered just laying out each class in a grid format (Figure 20). No particular order for the classes would be implemented and relationships between classes could very well pass through other classes. This method, however, would allow the user the ability to position the classes where he or she desires to create the best looking, most readable diagram. This is the approach that many commercial Computer Aided Software Engineering (CASE) tools take and is the method that we ultimately implemented.

grid layout
Figure 18: Grid layout

Diagrams

In order to demonstrate the effectiveness of this solution in creating class diagrams, we are going to present a portion of a diagram created with the help of Microsoft Visio and then compare that with a diagram created using our process. The diagram in Figure 21 was created using Visio. It contains three classes: Person, Applicant and Application. There are two relationships: a generalization between Person and Applicant and an association between Applicant and Application.

class diagram
Figure 19: Class diagram created with Microsoft Visio

A small portion of the XML document used to create this diagram using our process is provided in Figure 22. The next step is to transform the XML document using the class diagram XSLT. The resulting diagram before the user positions them is shown in Figure 23. Figure 24 shows the diagram after the user has a chance to position the classes how they desire. The result is a diagram identical to the one created using Microsoft Visio (Figure 21).

1  <?xml version="1.0" encoding="ISO-8859-1"?>
2  <?xml-stylesheet type="text/xsl" href="classDiagram.xsl"?>
3  <uml xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 4xsi:noNamespaceSchemaLocation="classDiagram.xsd" >
5  <classDiagram>
6    <class classID="person">
7      <name>Person</name>
8       <isAbstract>false</isAbstract>
9      <attribute>
10        <name>countryName</name>
11        <type>CString</type>
12        <visibility>private</visibility>
13      </attribute>
14      <operation>
15        <name>Person</name>
16        <visibility>public</visibility>
17      </operation>
18      <operation>
19        <name>PersonInfo</name>
20        <visibility>public</visibility>
21      </operation>
22    </class>
23  </classDiagram>
24 </uml>

Figure 20: XML data for creation of class diagram

UML class diagram
Figure 21: Class diagram before user positioning

UML class diagram
Figure 22: Class diagram after user positioning

Web-based Tool

In order to simplify the process of creating UML diagrams using XML, we have created a web-based tool. Using technologies such as Active Server Pages (ASP), Visual Basic Scripting (VBScript), and XHTML we were able to create a tool that makes the XML transformation transparent to the user. The following paragraphs provide a brief introduction to the tool.

Simple input forms were created in XHTML to allow the user to enter information about each of the components in the diagram. Using ASP and VBScript to access the XML DOM, the forms are processed and the information is assembled into an XML document that is stored on the server. Once the user has completed entering the components of the diagram, they have the option to view the XML document, view the completed diagram, and to view the XML Schema for which the document conforms. By selecting the View Diagram button, the XML document is transformed server-side into a dynamic SVG image by applying the XSLT.

Error checking is provided through the use of JavaScript on the client-side and VBScript on the server-side. This ensures that the XML document created will validate to the Schema and produce a useful diagram. Error messages are displayed if errors exist in the XML document and no transformation will take place. Should the user want to modify the diagram, the tool enables editing or deleting existing components.

After the transformation has occurred, the SVG diagram is displayed in the browser using a SVG viewer plug-in. The classes in the diagram are laid out in a three-column grid as discussed earlier. The user is able to position the classes as desired by dragging and dropping. A control box is provided to allow zooming and panning of the image. A context menu is enabled by right clicking on the image and provides the user with options to save the diagram, view the diagram source code or to view help on either the viewer plug-in or the tool.

screen capture of Web based tool
Figure 23: Web-based tool

Conclusion

While the aim of this research was proof-of-concept, the creation of an online system for creating UML diagrams could be beneficial in several ways. The web-based solution eliminates the need for any additional software, with the exception of a SVG viewer plug-in for the browser. This provides for an access-anywhere product with substantially less costs than a commercial CASE tool.

Future work on this solution would include the creation of a more complete set of UML diagrams. Layout issues with use case diagrams could be resolved using the method employed for class diagrams. In addition, creation of skeleton code for common languages such as Java, C, C++, etc. would be useful and relatively trivial to implement.

This research has provided the opportunity to demonstrate the power of XML as well as create a tool that may provide software engineers and management with a useful, inexpensive service.

We would like to take the opportunity to thank Dr. Gellenbeck for giving us the opportunity to participate in this research and for his invaluable insight into the workings of the XML and UML. Work on this project has provided us with valuable skills in advanced web technologies.

Appendix A

use case scenario

References

  1. Cockburn, Alistair. Writing Effective Use Cases. Boston: Addison-Wesley, 2000.
  2. Fowler, Martin and Kendall Scott. UML Distilled A Brief Guide to the Standard Object Modeling Language. 2nd Ed. Boston: Addison-Wesley, 1999.
  3. Unified Modeling Language 1.4 Specification. OMG, 2003. <http://www.omg.org/technology/documents/formal/uml.htm>
  4. Berners-Lee, Hendler, Lassila. The Semantic Web. Scientific American. 2001 May 17.
  5. W3C Architecture domain:Extensible Markup Language (XML). W3C, 2003. <http://www.w3.org/XML/>
  6. XML in 10 points. W3C, 2001. <http://www.w3.org/XML/1999/XML-in-10-points>
  7. W3C Architecture domain: XML Schema. W3C, 2003. <http://www.w3.org/XML/Schema>
  8. Cagle, Kurt and Michael Bierman. SVG Programming. APress, 2002.
  9. Watt, Andrew. Designing SVG Web Graphics. New Riders Publishing, 2002.
  10. Scalable Vector Graphics (SVG) 1.1 Specification. W3C, 2003. <http://www.w3.org/TR/SVG11/>