How XML Works

(Excerpt from "XML in a Nutshell" by Elliotte Rusty Harold & W. Scott Means)

The following code example shows a simple XML document. This particular XML document might appear in an inventory system or stock database. It marks up the data with tags and attributes that describe the colour, size, barcode number, manufacturer, product name and so on.

Code Example: An XML Document

This document is text and could simply be stored in a text file. You can edit the file with any ordinary text editor, such as BBEdit, jEdit, UltraEdit, Emacs or vi. You do not need a special XML editor. In fact, we have found that most general-purpose XML editors do more harm than good and are much harder to use than a simple text editor.

Programs that actually try to understand the contents of an XML document, rather than simply treating it like any other text file, use an XML parser to read the document. The parser is responsible for breaking the document down into individual elements, attributes and other components. It passes the contents of the XML document to an application piece by piece. If the parser detects a violation of XML’s well-formedness rules at any point, it reports an error to the application and stops parsing. Sometimes the parser can continue past the first error in the document so that it can detect and report further errors occurring later. Once it has detected the first error, however, it stops passing the contents of the elements and attributes it recognises to the application.

Individual XML applications usually impose more specific rules about which elements and attributes are permitted where. For example, you would not expect the element Notenschlüssel in a biology document. Some of these rules can be specified precisely using a schema; this schema may be a DTD or may be written in a schema language such as the W3C’s or RELAX NG. A document can contain a URL indicating where its schema can be found. Some XML parsers use this information and compare the document with its schema as they read it, to determine whether it conforms to the constraints specified there. Such a parser is called a validating parser. A violation of these constraints is a validity error, and the entire process of checking a document against a DTD is called validation. When a validating parser finds a validity error, it reports it to the application on whose behalf it is checking the document. That application can then decide whether parsing should continue. Unlike well-formedness errors, however, validity errors are not necessarily serious; an application might simply ignore them. Not all parsers validate. Some merely check well-formedness.

The following applications might receive data from a parser:

• A web browser such as Netscape Navigator or Internet Explorer, which presents the document to a reader.
• A word processor such as StarOffice Writer, which loads the XML document for editing.
• A database such as Microsoft SQL Server, which stores XML data in a new record.
• A drawing program such as Adobe Illustrator, which interprets the XML data as coordinates for the contents of an image.
• A spreadsheet such as Gnumeric, which searches the XML data for numbers and functions to use in a calculation.
• A financial program such as Microsoft Money, which treats the XML data as a bank statement.
• An editorial program that extracts the latest news headlines from the XML document.
• A program you have written yourself in Java, C, Python or another language to perform exactly the task you specify.
• Almost anything else.

XML is an extremely flexible data format. It is used for all of these purposes and many more. These are real examples. In theory, any data that can be stored on a computer can be represented in XML. In practice, XML is suitable for storing and exchanging any data that can sensibly be encoded as text. It is unsuitable only for digitised data such as photographs, music, video and other very large sequences of bits.