# libxml++ - An XML Parser for C++

libxml++ is a C++ API for the popular libxml2 XML parser, written in C. libxml2 is famous for its high performance and compliance to standard specifications, but its C API is quite difficult even for common tasks.

libxml++ presents a simple C++-like API that can achieve common tasks with less code. Unlike some other C++ parsers, it does not try to avoid the advantages of standard C++ features such as namespaces, STL containers or runtime type identification, and it does not try to conform to standard API specifications meant for Java. Therefore libxml++ requires a fairly modern C++ compiler such as g++ 8 or g++ 9. libxml++ 3.9.1 and later require a C++17-compliant compiler.

But libxml++ was created mainly to fill the need for an API-stable and ABI-stable C++ XML parser which could be used as a shared library dependency by C++ applications that are distributed widely in binary form. That means that installed applications will not break when new versions of libxml++ are installed on a user's computer. Gradual improvement of the libxml++ API is still possible via non-breaking API additions, and new independent versions of the ABI that can be installed in parallel with older versions. These are the general techniques and principles followed by the GNOME project, of which libxml++ is a part.

libxml++ is packaged by major Linux and *BSD distributions and can be installed from source on Linux and Windows, using any modern compiler, such as g++ or MSVC++.

For instance, to install libxml++ and its documentation on Debian, use apt-get or synaptic like so:

        # apt-get install libxml++4.0-dev libxml++4.0-doc

To check that you have the libxml++ development packages installed, and that your environment is working properly, try `pkg-config libxml++-4.0 --modversion`.

Links for downloading and more documentation can be found at libxmlplusplus.github.io/libxmlplusplus. libxml++ is licensed under the LGPL, which allows its use via dynamic linking in both open source and closed-source software. The underlying libxml2 library uses the even more generous MIT licence.

The libxml++ API takes, and gives, strings in the UTF-8 Unicode encoding, which can support all known languages and locales. This choice was made because, of the encodings that have this capability, UTF-8 is the most commonly accepted choice. UTF-8 is a multi-byte encoding, meaning that some characters use more than 1 byte. But for compatibility, old-fashioned 7-bit ASCII strings are unchanged when encoded as UTF-8, and UTF-8 strings do not contain null bytes which would cause old code to misjudge the number of bytes. For these reasons, you can store a UTF-8 string in a std::string object. However, the std::string API will operate on that string in terms of bytes, instead of characters.

Because Standard C++ has no string class that can fully handle UTF-8, libxml++ uses the Glib::ustring class from the glibmm library. Glib::ustring has almost exactly the same API as std::string, but methods such as length() and operator[] deal with whole UTF-8 characters rather than raw bytes.

There are implicit conversions between std::string and Glib::ustring, so you can use std::string wherever you see a Glib::ustring in the API, if you really don't care about any locale other than English. However, that is unlikely in today's connected world.

glibmm also provides useful API to convert between encodings and locales.

To use libxml++ in your application, you must tell the compiler where to find the include headers and where to find the libxml++ library. libxml++ provides a pkg-config .pc file to make this easy. For instance, the following command will provide the necessary compiler options: `pkg-config libxml++-4.0 --cflags --libs`

When using autoconf and automake, this is even easier with the PKG_CHECK_MODULES macro in your configure.ac file. For instance:

        PKG_CHECK_MODULES(SOMEAPP, libxml++-4.0 >= 4.0.0)
        AC_SUBST(SOMEAPP_CFLAGS)
        AC_SUBST(SOMEAPP_LIBS)

Like the underlying libxml2 library, libxml++ allows the use of 3 parsers, depending on your needs - the DOM, SAX, and TextReader parsers. The relative advantages and behaviour of these parsers will be explained here.

All of the parsers may parse XML documents directly from disk, a string, or a C++ std::istream. Although the libxml++ API uses only Glib::ustring, and therefore the UTF-8 encoding, libxml++ can parse documents in any encoding, converting to UTF-8 automatically. This conversion will not lose any information because UTF-8 can represent any locale.

Remember that white space is usually significant in XML documents, so the parsers might provide unexpected text nodes that contain only spaces and new lines. The parser does not know whether you care about these text nodes, but your application may choose to ignore them.

The DOM (Document Object Model) parser parses the whole document at once and stores the structure in memory, available via `DomParser::get_document()`. With methods such as `Document::get_root_node()` and `Node::get_children()`, you may then navigate into the hierarchy of XML nodes without restriction, jumping forwards or backwards in the document based on the information that you encounter. Therefore the DOM parser uses a relatively large amount of memory.

You should use C++ RTTI (via `dynamic_cast<>`) to identify the specific node type and to perform actions which are not possible with all node types. For instance, only `Element`s have attributes. Here is the inheritance hierarchy of node types:

- xmlpp::Node

  - xmlpp::Attribute

    - xmlpp::AttributeDeclaration

    - xmlpp::AttributeNode

  - xmlpp::ContentNode

    - xmlpp::CdataNode

    - xmlpp::CommentNode

    - xmlpp::EntityDeclaration

    - xmlpp::ProcessingInstructionNode

    - xmlpp::TextNode

  - xmlpp::Element

  - xmlpp::EntityReference

  - xmlpp::XIncludeEnd

  - xmlpp::XIncludeStart

All `Node`s created by the DOM parser are leaves in the node type tree. For instance, the DOM parser can create `TextNode`s and `Element`s, but it does not create objects whose exact type is `ContentNode` or `Node`.

Although you may obtain pointers to the `Node`s, these `Node`s are always owned by their parent `Node`. In most cases that means that the `Node` will exist, and your pointer will be valid, as long as the `Document` instance exists.

There are also several methods which can create new child `Node`s. By using these, and one of the `Document::write_*()` methods, you can use libxml++ to build a new XML document.

This example looks in the document for expected elements and then examines them. All these examples are included in the libxml++ source distribution.

Source Code

The SAX (Simple API for XML) parser presents each node of the XML document in sequence. So when you process one node, you must have already stored information about any relevant previous nodes, and you have no information at that time about subsequent nodes. The SAX parser uses less memory than the DOM parser and it is a suitable abstraction for documents that can be processed sequentially rather than as a whole.

By using the `parse_chunk()` method instead of for instance `parse_file()`, you can even parse parts of the XML document before you have received the whole document.

As shown in the example, you should derive your own class from SaxParser and override some of the virtual methods. These "handler" methods will be called while the document is parsed.

This example shows how the handler methods are called during parsing.

Source Code

Like the SAX parser, the TextReader parser is suitable for sequential parsing, but instead of implementing handlers for specific parts of the document, it allows you to detect the current node type, process the node accordingly, and skip forward in the document as much as necessary. Unlike the DOM parser, you may not move backwards in the XML document. And unlike the SAX parser, you must not waste time processing nodes that do not interest you.

All methods are on the single parser instance, but their result depends on the current context. For instance, use `read()` to move to the next node, and `move_to_element()` to navigate to child nodes. These methods will return false when no more nodes are available. Then use methods such as `get_name()` and `get_value()` to examine the elements and their attributes.

This example examines each node in turn, then moves to the next node.

Source Code