XML: Structuring Data for the Web: An Introduction

What does XML look like?

In contrast to recent Web technologies such as HTML, Cascading Style Sheets and Dynamic HTML, XML is about all about structure, not presentation.

If written properly, normal HTML may reflect document structure, but it cannot adequately represent the structure of data. Consider this trivial HTML example.

<B>John Q Public</B>
<P>                          
john.q.public.1@gsfc.nasa.gov<BR>
phone: 301-286-aaaa<BR>
fax: 301-286-bbbb<BR>
Bldg. 23, Rm. 999<BR>
NASA<BR>
Goddard Space Flight Center<BR>
588.0<BR>
Greenbelt, MD 20221<BR>

As humans, we recognize that this example represents information about an employee: name, phone, address, etc. However, the elements used to markup this snippet do not in fact reveal any such interpretation! The markup merely describes how the lines should be displayed. When the HTML is processed by the browser, no semantics can be inferred; your poor computer has no understanding of the kind of information being rendered.

Now consider a possible XML representation of the same information which conveys the relationship between various data objects. In the XML version below, we have an employee, described by a name, an email address, phone and fax numbers, a location, and an address. Note that each conceptual piece of information is represented by its own XML element, such as <EMPLOYEE>, <NAME>, and <ADDRESS>.

<EMPLOYEE>
  <NAME>
        <FIRST>John</FIRST>
        <MIDDLE>Q</MIDDLE>
        <LAST>Public</LAST>
  </NAME>         
  <EMAIL>john.q.public.1@gsfc.nasa.gov</EMAIL>
  <PHONE>301-286-aaaa</PHONE>
  <FAX>301-286-bbbb</FAX>
  <LOCATION>
        <BUILDING>Bldg. 23</BUILDING>
        <ROOM>999</ROOM>
  </LOCATION>
  <ADDRESS>
        <ORG>NASA</ORG>
        <CENTER>Goddard Space Flight Center</CENTER>
        <MAILSTOP>588.0</MAILSTOP>
        <CITY>Greenbelt</CITY>
        <STATE>MD</STATE>
        <ZIP>20221</ZIP>
  </ADDRESS>
</EMPLOYEE>

The advantage of XML in this example is that it preserves the semantics and structure of the data. We can think of this information as hierarchical data. An employee object consists of name, email, phone, fax, location, and address objects. A name consists of first, middle, and last components, a location contains a building and a room object, and so forth. The parallel to database records should be obvious.

We can easily imagine a Document Object Model (DOM) based on JavaScript or ECMAScript that accommodates this hierarchy, so if this entry were the fifth employee "record" on the page, we could reference the value of the last name ("Public") like this:

doc.employee[4].name[0].last[0].value

Note that in the XML representation, there is no description of how to display the content. While this might at first appear to be undesirable, the separation of semantics from visual representation makes possible several of the benefits discussed below.

XML: Structuring Data for the Web: An Introduction
XML: Structuring Data for the Web: An Introduction
XML: Structuring Data for the Web: An Introduction