3.2.1 Elements and attributes

Take another look at Figure 3.1. It helps explain large parts of what we have to know about XML. An XML document always starts with a line that makes declarations for the XML document:

version="1.0" indicates the version of XML that is being used. There are currently two versions: XML 1.0 and XML 1.1.² Additionally, the declaration can, but need not hold the character encoding of the document, which in our case is encoding="ISO-8859-1".³ Another attribute the declaration can contain—but does not in our example—is the standalone attribute, which take values of yes or no and indicates whether there are external markup declarations that may affect the content of the document.⁴

An XML file must contain one and only one root element that embraces the whole document. In our case, it is:

Information is usually stored in elements. An XML element is defined by its start tag and the content. An element frequently has an end tag, but can also be closed in the start tag with a slash /. It can contain

• other elements.
• attributes, bits of information that describe the element in more detail. Attributes, like elements, are slots for information, but they cannot contain further elements or attributes.
• data of any form and length, for example, text, numbers or symbols.
• a mixture of everything, which sounds complicated but is a rather ordinary case when elements contain other elements that contain data. For example, the <movie> elements in Figure 3.1 all contain an attribute, other elements, and data within the children elements.
• nothing, which means really nothing—no data, no other element, not even white spaces.

Consider the first <title> element from above:

Its constituent parts are

We are already familiar with the start tag–end tag logic from HTML. The benefit of this syntax is that we can easily locate data of a certain element in the document, regardless of where, that is, on which line or hierarchical level it is located. The element <title> occurs three times in the example. We could retrieve all of these elements by building a query like “give me the content of all elements named <title>.” This is what we will learn in Chapter 4 when we learn how to use the query language XPath. A more compact way of writing elements is

This element contains

In this case there is no end tag but only a start tag. This is a so-called empty element because the element contains no data. Empty elements are closed with a slash /. The element in the example is of course not literally empty. Just like in HTML, XML elements can contain attributes that provide further information. There is no limit to the number of attributes an element can contain. The example element has two attributes. They are separated by a white space. Attributes are always part of a start tag and hold their values in quotes after an equal sign. The information stored in attributes is called attribute value. Attribute values always have to be put in quotes, either using single quotes like bond=’Sean Connery’ or double quotes like bond="Daniel Craig". However, if the attribute value itself contains quotes, you should use the opposed pair of quotes for the attribute value:

As the structure of an XML document is inherently flexible, there are many ways to store the same content. Note how the actors were stored in the running example in Figure 3.1. Another way would have been the following:

All information is retained, but the actors’ names are now stored in elements, not attributes. Both ways are equally valid. The problem with attributes is that they do not allow further branching—attributes cannot be expanded and can only contain one value. Besides, we find them more difficult to read and more inconvenient to extract compared to elements. They are, however, not altogether useless. Take a look at the code in Figure 3.1. Attributes named id are used to make elements with the same name uniquely identifiable. This can be of help when we need to manipulate information in a particular element of the XML tree.

3.2.2 XML structure

Each XML document can be represented as a hierarchical tree. The fact that data are stored in a hierarchical manner is well suited for many data structures we are confronted with: Survey participants are nested within countries. Survey participants’ responses are nested within survey participants. Votes are nested within polling stations that are nested within electoral districts that are nested within countries, and so on. Figure 3.2 gives a graphical representation of the XML data from the XML code in Figure 3.1. At the very top stands the root element <bond_movies>. All other elements have one and only one parent. In fact, we can apply a family tree analogy to the entire document, describing each element as a node:

• the movie nodes are children of the root node bond_movies;
• the movie nodes are siblings;
• the bond_movie node is the parent of the movie nodes, which are parents of the title,..., boxoffice nodes;
• the title,..., boxoffice nodes are grandchildren of bond_movies.

Note that the attributes and their values are presented in the element value boxes in Figure 3.2, even though they could be viewed as further leaves in the XML tree. However, as attributes cannot be parents to other elements or attributes, they are rather element-describing content than autonomous nodes. Nevertheless, they are strictly speaking attribute nodes.

Elements must be strictly nested, which means that no cross-nesting is allowed. An illegal document structure would be:

While it is theoretically sensible that the element <child> with the value Jonathan opens a new <family> branch containing Jonathan’s wife Julia and their child Jeff, Jonathan’s <child> element has to be closed before the <family> element.

3.2.3 Naming and special characters

One of the strengths of XML is that we are basically free to chose the names of elements. However, there are some naming rules:

• Element names can be composed of letters, numbers, and other characters, like in <name1> … </name1>. Special characters like ä, ö, ü, é, è, or à are allowed, but not recommended—they might limit the compatibility of XML files across systems.
• Names must not start with a number, like in <123name> … </123name>.
• Names must not start with a punctuation character, like in <.name> … </.name>.
• Names must not start with the letters xml (or XML, or Xml, etc.), like in <xml.rootname> … </xml.rootname>.
• Element names and attribute names are case sensitive. <movie> is not the same as <MOVIE> or <Movie>.
• Names must not contain spaces, like in <my family> … </my family>.

As in HTML, there are some characters that cannot be used literally in the content as they are needed for markup. To represent these characters in the content, they have to be replaced by escape sequences. These entities are listed in Table 3.1 and used as follows

You do not always need to escape special characters. For example, apostrophes are sometimes left unescaped, like in "Richard ’Jaws’ Kiel" in the example above. In this case, the apostrophes are unambiguous because the attribute value is enclosed by double quotes. Using apostrophes in XML element values is usually no problem either, because they have no special meaning in the value slot of the element, only inside tags as limiters to attribute values.

3.2.4 Comments and character data

XML provides a way to comment content with the syntax

Everything in between <!-- and --> is not treated as part of the XML code and therefore ignored by parsers. Comments may be used between tags or within element content, but not within element or attribute names.

The use of escape sequences can be cumbersome when the elements to be escaped are common in the data values. For example, imagine the following character sequence needs to be stored in an XML file

In XML code, this would translate to

To avoid this mess, XML provides an environment that prevents the content from being interpreted. It is called CDATA and works as follows

All characters in the CDATA section are taken as is. The difference between comments and a CDATA section is that a comment is not part of the document … 

… whereas a CDATA section is:

If we write both snippets in an XML file and open it with a browser, the comments are not displayed or explicitly highlighted as part of the XML tree. In contrast, the CDATA section is displayed in the tree. If we delete the CDATA tags, this will produce an error because the browser fails to interpret the ampersands and quotation marks.

You may want to try this out yourself. Save the last code snippet with your text editor as an XML file and open it with your browser. Modify the content of the XML file, save it, and reload the content with the browser. Experiment with allowed and disallowed changes. Try special characters, cross-nested tags, and forbidden element names.

3.2.5 XML syntax summary

To sum up, the XML syntax comprises the following set of rules:

1. An XML document must have a root element.
2. All elements must have a start tag and be closed, except for the declaration, which is not part of the actual XML document.
3. XML elements must be properly nested.
4. XML attribute values must be quoted.
5. Tags are named with characters and numbers, but may not start with a number or “xml.”
6. Tag names may not contain spaces and are case sensitive.
7. Space characters are preserved.
8. Some characters are illegal and have to be replaced by meta characters.
9. Comments can be included as follows: <!-- comment -->.
10. Content can be excluded from parsing using: <![CDATA[...]]>.

3.4.1 Namespaces

Consider the following two pieces of HTML and XML:

Both pieces store information in the element <title>. If the XML code were embedded in HTML code, this might create confusion. As we will see, there are many XML extensions to store specific data, for example, geographic, graphical, or financial data. All of these languages are basically XML with limited vocabulary. When several of these XML-based languages are used in one document, element or attribute names can become ambiguous if they are multiply assigned. XML namespaces are used to circumvent such problems. The idea is very simple: Ambiguous elements become distinguishable if some unique identifier is added. Just like zip codes allow distinguishing between many different Springfields and area codes make phone numbers unambiguous, namespaces help make elements and attributes uniquely identifiable.

The implementation of namespaces is straightforward:

In this example, namespaces are declared in the root element using the xmlns attribute and two prefixes, h and t. The namespace name, that is, the namespace attribute value, usually carries a Uniform Resource Identifier (URI) that points to some Internet address. The URIs in the example are two URLs that refer to an existing Internet resource on the W3C homepage and the fictional domain funnybooknames.com. When dealing with namespaces, note the following rules:

1. Namespaces can be declared in the root element or in the start tag of any other element. In the latter case, all children of this element are considered part of this namespace.
2. The namespace name does not necessarily have to be a working URL. Parsers will never try to follow the link, not even a URI. Any other string is fine. However, it is common practice to use URIs for two reasons: First, as they are a long, unique string of characters, duplicates are unlikely, and second, actual URLs can point the human reader to pages where more information about the namespace is given.⁵
3. Prefixes do not have to be explicitly stated, so the declaration can either be xmlns or xmlns:prefix . If the prefix is dropped, the xmlns is assumed to be the default namespace and any element without a prefix is considered to be in that namespace. When prefixes are used, it is bound to a namespace in the declaration. Attributes, however, never belong to the default namespace.

3.4.2 Extensions of XML

Thus far, we have praised XML for its flexibility and extensibility. However, standardization also has its benefits in data exchange scenarios. Recall how browsers deal with HTML. They “know” what a table looks like, how headings should be formatted, and so on. In general, many data exchange processes can be standardized because sender and recipient agree on the content and structure of the data to be exchanged.

Following this logic, a multitude of extensions of the XML language has been developed that combine the classical XML features of openness with the benefits of standardization. In that sense, XML has become an important metalanguage—it provides the general architecture for other XML markup languages. Varieties of XML rely on XML schemas that specify allowed structure, elements, attributes, and content. Table 3.2 lists some of the most popular XML derivations. Among them are languages for geographic applications like KML or GPX as well as for web feeds and widely used office document formats. You might be surprised to find that MS Word makes heavy use of XML. To gain basic insight into XML extensions that are ubiquitous on the Web, we focus on two popular XML markup languages—RSS and SVG.

3.4.3 Example: Really Simple Syndication

Web users commonly cultivate a list of bookmarks of their favorite webpages. It can be rather tiresome to regularly check for new content on the sites. Really Simple Syndication (RSS)⁶ was built to solve this problem—both for the user and the content providers. The basic idea is that news sites, blog owners, etc., convert their content into a standardized format that can be syndicated to any user.

We illustrate the logic of RSS in Figure 3.3. Authors of a blog or news site set up an RSS file that contains some information on the news provider, which is stored on a web server. The file is updated whenever new content is published on the blog. Both are usually done by an RSS creation program like RSS builder. The list of entries or notifications is often called RSS feed or RSS channel and might be located at http://www.example.net/feed.rss. It is written in XML that follows the rules of the RSS format. Common elements that are allowed in this XML flavor are listed in Table 3.3. There are elements that describe the channel and others that describe single entries. Users collect channels by subscribing to an RSS reader or aggregator like Feedly, which automatically locates the RSS feed on a given website and lays out the content. These readers automatically update subscribed feeds and offer further management functionalities. This way, users are able to assemble their own online news.

There are several versions of RSS, the current one being RSS 2.0. RSS syntax has remained fairly simple, especially for users who are familiar with XML. The rules are strict, that is, there is a very limited set of allowed elements and a clear document structure. Consider the following example of a fictional RSS channel accompanying this book:

RSS documents start with an XML and RSS declaration in the first two lines. The <channel> element wraps around both meta information and the actual entries. The channel's meta block has three required elements—<title>, <description>, and <link>. In the example, there is another optional element, <lastBuildDate>, that indicates the last time content was changed on the channel. The content block consists of a set of <item> elements. Whenever a new story, blog entry, etc., is published, a new <item> element is added to the feed. <item> elements have three obligatory children—again, they are called <title>, <description>, and <link>. The main content is usually stored in the <description> element. Sometimes the whole entry is stored here, sometimes just the first few lines or a summary. In general, RSS syntax obeys the same set of rules as XML syntax.

Take a moment to look at actual RSS feeds. They are all around the Web and indicated with the RSS icon (). There are several popular news and blogging platforms about R. For example, have a look at http://planetr.stderr.org/ where new R packages are posted (via Dirk Eddelbuettel's CRANberries blog http://dirk.eddelbuettel.com/cranberries/), and at http://www.r-bloggers.com/, a meta-blogging platform that collects content from the R blogosphere.

RSS 2.0 is not the only content syndication format. Besides various predecessors, another popular standard is Atom, which is also XML-based and has a very similar syntax. In order to grab RSS feeds into R, we can use the same XML extraction tools that are presented in Section 3.5.

3.4.4 Example: scalable vector graphics

A more peculiar but incredibly popular extension of XML is scalable vector graphics (SVG). SVG is used to represent two-dimensional vector graphics. It has been developed at the W3C since 1999 and was initially released in 2001 (Dailey 2010). The idea was to create a vector graphic format that stores graphic information in lightweight, flexible form for exchange over the Web.

Vector graphic formats consist of basic geometric forms such as points, curves, circles, lines, or polygons, all of which can be expressed mathematically. In contrast, raster graphic formats store graphic information as a raster of pixels, that is, rectangular cells of a certain color. In contrast to raster graphics, vector graphics can be resized without any loss of quality and are usually smaller. As the SVG format is based on XML, SVG graphics can be manipulated with an ordinary text editor. There are, however, SVG editors that simplify this task. For example, Inkscape is an open-source graphics editor that implements SVG by default and runs on all common operating systems.⁷ In order to view SVG files, we can use current versions of the common browsers.

To get a first impression of how SVG works, Figure 3.4 provides code of a small SVG file. This code generates a stylized representation of the R icon just like the one displayed in Figure 3.5. In fact, if we open an SVG file with the content of the sample code with our browser, we see the graphic shown in Figure 3.5. The syntax does not only resemble XML, it is XML with a limited set of legal elements and attributes. An SVG file starts with the usual XML declaration. The standalone attribute indicates that the document refers to an external file, in this case an external DTD in lines 2 and 3. This DTD is stored at the www.w3.org webpage and describes which elements and attributes are legal in the current SVG version 1.1 (as of March 2014). The actual SVG code that describes the graphic is enclosed in the <svg> element. It contains a namespace and a version attribute.

SVG uses a predefined set of elements and attributes to represent parts of a graphic (‘SVG shapes’). Among the basic shapes of SVG are lines (<line>), rectangles (<rect>), circles (<circle>), ellipses (<ellipse>), polygons (<polygon>), (<text>), and, the most general of all, paths (<path>). Each of these elements comes with a specific set of attributes to tune the object's properties, for example, the position of the corners, the size and radius of a circle, and so on. Elements are placed on a virtual coordinate system, with the origin (0,0) in the upper-left corner. Formatted text can also be placed into the graphic. The order of elements is important. A later-listed element covers a previous element—elements can therefore be thought of as layers. Further, there is a palette of special effects like blurs or color gradients. Elements can even be animated. A complex SVG graphic is often generated by quite complex SVG code. The complexity usually does not stem from a highly hierarchical structure—most of the elements are often just children of the root element—but from the mass of elements and their attributes. Our basic graphic in Figure 3.5 is composed of only three elements—two ellipses and one text element. By default, elements come in the compact form of XML element syntax: Elements are usually empty and contain no further information than those given in the attributes.

Back to the example, the locations of the ellipses are defined by their attributes cx and cy, their shape by the horizontal and vertical radius in rx and ry. Colors and other effects can be passed via arguments in the style attribute. The white ellipse is plotted on the top of the grey ellipse simply because it appears second in the code, creating the donut effect. Finally, shape, color, font, and location of the “R” is defined in the <text> element.

Beyond the principle advantages of vector over raster graphics, SVG, in particular, has some features that make it attractive as a graphic standard on the Web: It can be edited with any text editor, opened with the common browsers, follows a familiar syntax as it is basically just XML, and has been developed for a wide range of applications. We have learned that XML is flexible but because of the flexibility cannot be interpreted further by a browser. This is not true for XML extensions such as SVG. As the set of elements and attributes is clearly defined, browsers can be programmed to display SVG content as meaningful graphic, not as code—just as they interpret and display HTML code. In HTML5, SVG graphics can even be embedded as simply as this

Why could SVG be useful in the context of automated data collection? At first glance, SVG is a flexible and widely used vector graphics format. From the data collection perspective, however, it is more than that. The information in these graphs—and often more than just the visible parts—are stored in text form and can therefore be searched, subsetted, etc. SVG is becoming more and more popular on the Web and is used for increasingly complex tasks, for example, to store geographic information, create interactive maps, or visualize massive amounts of data.⁸

The takeaway message of these two examples is that XML is present in many different areas, and many of these applications hold potentially useful information. And the neat thing is: We will learn how easy it is to retrieve and process this information with R, regardless of whether the information is stored in “pure” XML or any of its extensions.

3.5.1 Parsing XML

We parse XML for the same reason that we parse HTML documents (see Section 2.4.1), to create a structure-aware representation of XML files that allows a simple information extraction from these files. Similar to what was outlined in the HTML parsing section, the process of parsing XML essentially includes two steps. First, the symbol sequence that constitutes the XML file is read in and used to build a hierarchical tree-like data structure from its elements in the C language, and second, this data structure is translated into an R data structure via the use of handlers.

The package we use to import and parse XML documents is, appropriately enough, called XML (Temple Lang 2013c). Using the XML package we can read, search, and create XML documents—although we only care about the former two tasks. Let us see how to load XML files into R. For DOM-style parsing of XML files one can use xmlParse(). The arguments of the function coincide with those of htmlParse() for the most part. We illustrate the process with the help of technology.xml, an XML file that holds stock information for three technology companies. The first few lines of the document are presented in Figure 3.6. As we see, the file contains stock information like the closing value, lowest and highest value for a day, and the traded volume. To obtain the XML tree with R, we pass the path of the file to xmlParse()’s file argument:

R> library(XML)
R> parsed_stocks <- xmlParse(file ="stocks/technology.xml")

The xmlParse() function is used to parse the XML document.⁹ The parsing function offer a set of options that can be ignored in most settings but are still worth knowing. It is possible to treat the input as XML and not as a file name (option asText), to decide whether both namespace URI and prefix should be provided on each node or just the prefix (option fullNamespaceInfo), to determine whether an XML schema is parsed (option isSchema), or to validate the XML against a DTD (option validate). Let us consider this last option in more detail.

Although HTML and XML are very similar in most respects, a noteworthy difference exists in that XML is confined to much stricter specification rules. As we have seen in Section 3.3, valid XML not only has to be well formed, that is, tags must be closed, attributes names must be in quotes, etc., but also has to adhere to the specifications in its DTD. To check whether the document conforms to the specification, a validation step can be included after the DOM has been created by setting the validate argument to TRUE. We try to validate technology.xml with the corresponding external technologystocks.dtd (see Figure 3.7), which is deposited in our folder and referred to in line 2 of the XML file (see Figure 3.6):

R> library(XML)
R> parsed_stocks <- xmlParse(file ="stocks/technology.xml", validate = TRUE)

There is no complaint; the validation has succeeded. To demonstrate what happens if an XML does not conform to a given DTD, we manipulate the DTD such that the document node is no longer defined. As a consequence, the XML file does not conform to the (corrupted) DTD anymore and the function raises a complaint:

R> library(XML)
R> stocks <- xmlParse(file ="stocks/technology-manip.xml", validate = TRUE)
No declaration for element document
Error: XML document is invalid

In general, the rather bulky logic of XML validation with DTD, XSD, or other schemas should not discourage you from making use of the full power of the XML DOM structure. In most web scraping scenarios, there is no need to validate the files and we can simply process them as they are.

3.5.2 Basic operations on XML documents

Once an XML document is parsed we can access its content using a set of functions in the XML package. While we recommend using the more general and robust XPath for searching and pulling out information from XML documents, here we present some basic operations that might suffice for less complex XML documents. To see how they work, let us go back to our running example: We start by parsing the bond.xml file:

When we type bond into our console, the output looks pretty much like the original XML file. We know, however, that the object is anything but pure character data. For instance, we can perform some basic operations on the root element. The top-level node is extracted with the xmlRoot() function; xmlName() and xmlSize() return the root element's name and the number of children:

Within the node sets, basic navigation or subsetting works in analogy to indexing ordinary lists in R. That is, we can use numerical or named indices to select certain nodes. This is not possible with objects of class XMLInternalDocument that are generated by xmlParse(). We therefore work with the root object, which belongs to the class XMLInternalElementNode. Indexing with predicate “1” yields the first child:

We have to use double brackets to access the internal node. By adding another index, we can move further down the tree and extract the first child of the first child:

R> root[[1]][[1]]
<name>Dr. No</name>

Element names can be used as predicates, too. Using double brackets yields the first element in the tree, single brackets return objects of class XMLInternalNodeList. To see the difference, compare

with

Names and numbers can also be combined. To return the atomic value of the first <name> element, we could write

R> root[["movie"]][[1]][[1]]
Dr. No

The structure of the object is retained and can be used to locate elements and values. However, content retrieval from XML files via ordinary predicates is quite complex, error prone, and anything but convenient. Further, this method does not capitalize on node relations—a core feature of parsed XML documents. For anybody who is seriously working with XML data, there are good reasons to learn the very powerful query language XPath. We will show how this is done in the next chapter.

In general, all methods and all those to follow are applicable to other XML-based languages as well. The parser does not care about naming and structure of documents as long as the code is valid. Therefore, documents like the RSS sample code from above can be imported just as easy as

3.5.3 From XML to data frames or lists

Sometimes it suffices to transform an entire XML object into common R data structures like vectors, data frames, or lists. The XML package provides some appropriate functions that make such operations straightforward if the original structure is not too complex.

Single vectors can be extracted with xmlSApply(), a wrapper function for lapply() and sapply() that is built to deal with children of a given XML node. The function operates on an XML node (provided as first argument), applies any given function on its children (given as the second argument), and commonly returns a vector. We can use the function in combination with xmlValue() and xmlGetAttr() (and other functions; see Table 4.4) to extract element or attribute values:

As long as XML documents are flat in the hierarchical sense, that is, the root node's most distant relatives are grandchildren or children, they can usually be transformed easily into a data frame with xmlToDataFrame()

Note, however, that this function already runs into trouble with the <actor> element, which is itself empty except for two attributes. The corresponding variable in the data.frame object is left empty with a shrug.

Similarly, a conversion into a list is possible with xmlToList():

R> movie.list <- xmlToList(bond)

XML and other data exchange formats like JSON can store much more complicated data structures. This is what makes them so powerful for data exchange over the Web. Forcing such structures into one common data frame comes at a certain cost—complicated data transformation tasks or the loss of information. xmlToDataFrame() is not an almighty function to achieve the task for which it is named. Rather, we are typically forced to develop and apply own extraction functions.

3.5.4 Event-driven parsing

While parsing the XML example files in Section 3.5.1 was processed quickly by R, files of larger size can lead to overloaded working memory and concomitant data management problems. As a format primarily designed for carrying data across services, XML files are oftentimes of substantially greater size than HTML files. In many instances, file sizes can exceed the memory capacity of ordinary desktop PCs and laptops. This problem is aggravated when data streams are concerned, where XML data arrives iteratively. These applications obstruct the DOM-based parsing approach we have been applying in this and the previous chapter and demand for a more iterative parsing style.

The root of the problem stems from the way the DOM-style parsers process and store information. The parser creates two copies of a given XML file—one as the C-level node set and the second as the data structure in the R language. To detect certain elements in an XML file, we can deal with this problem by employing a parsing technique called event-driven parsing or SAX parsing (Simple API for XML). Event-driven parsing differs from DOM-style parsing in that it skips the construction of the complete DOM at the C level. Instead, event-driven parsers sequentially traverse over an XML file, and once they find a specified element of interest they prompt an instant, user-defined reaction to this event. This procedure provides a huge advantage over DOM-style parsers because the machine's memory never has to hold the complete document.

Let us reconsider technology.xml and the problem of extracting information about the Apple stock. Assume we are interested in obtaining Apple's daily closing value along with the date. Once again, we make use of a handler function to specify how to handle a node of interest. Similar to the extraction problem considered in Section 2.4.3, we define the handler as a nested function to combine it with a reference environment and container variables (see Figure 3.8). branchFun() defines two local variables container_close and container_date, serving as the container variables. Since we are interested in Apple stock information, we suggest the following approach: We start by defining a handler function for the <Apple> nodes (lines 6 and 8). Conditional on these elements, we look for their children called date and close and return their values (lines 7 and 9). A return function getContainer() is defined (line 12) that assembles the container variable's contents into a data frame and returns this object.

To generate a usable instance of the handler function, we execute the function and pass its return value into a new object called h5:

We are now ready to run the SAX parser over our technology.xml file using XML’s xmlEventParse() function. Instead of the handlers argument we will pass the handler function to the branches argument. The branches is a more general version of the handlers argument, which allows to specify functions over the entire node content, including its children. This is exactly what we need for this task since in our handler function h5 we have been making use of the xmlChildren function for retrieving child information. Additionally, for the handlers argument we need to pass an empty list:

R> invisible(xmlEventParse(file ="stocks/technology.xml", branches = h5, handlers = list()))

To get an idea about the iterative traversal through the document, remove the commented line in the handler and rerun the SAX parser. Finally, to fetch the information from the local environment we employ the getStore() function and route the contents into a new object:

R> apple.stock <- h5$getStore()

To verify parsing success, we display the first five rows of the returned data frame:

R> head(apple.stock, 5)
R> # date close 1 2013/11/13 520.634 2 2013/11/12 520.01 3 2013/11/11 519.048 4
R> # 2013/11/08 520.56 5 2013/11/07 512.492

As we have seen, the event-driving parsing works and returns the correct information. Nonetheless, we do not recommend users to resort to this style of parsing as their preferred means to obtain data from XML documents. Although event-style parsing exceeds the DOM-style parsing approach with respect to speed and may, in case of really large XML files, be the only practical method, it necessitates a lot of code overhead as well as background knowledge on R functions and environments. Therefore, for the small- to medium-sized documents that we deal with in this book, in the coming chapters we will focus on the DOM-style parsing and extraction methods provided through the XPath query language (Chapter 4).