It’s been a while since I’ve mentioned anything about XML. Well, I just released XMLNode. It’s a library that I’ve been using at work for the last few years. It’s basic purpose in life is to give us a clean interface to data-driven XML documents that we use. It has adaptors to allow us to use STL algorithms to parse, or manipulate the XML. It also provides a straight forward, object tree that represents the XML.

XMLNode is by no means complete. It currently has some destructive tendencies. If you read XML into XMLNode, then use XMLNode to write the tree back out, any comments, or extra white space are removed. We have plans to fix this, and to have a lower level interface that is more DOM like. XMLNode will then become a light wrapper to the DOM that allows STL manipulations, as well as more straightforward object traversal.

I’ll try and post some examples here shortly where XMLNode shines.

-Synwan

Lately I’ve been running into an interesting problem. We have a fairly large record based XML tree. We need that tree to act more like a database in that the same tree can be updated by multiple objects, concurrently and safely. The obvious question is why not make it a database. My reasoning for that is this XML changes fairly frequently, and we want to avoid having to convert the schema each time. XML allows us to easily extend the tree with no need to break the existing structure. We’re playing with some solutions, but none of them are far enough along to really discuss yet. However here are our goals:

• Concurrent (or very close) read access of the tree
• Concurrent (or very close) write access of elements in the tree
• Sane persistence of the tree (When a write happens, we don’t lose some other write that was just made)
• Generic enough framework that it can be used for any record based tree. Even better would be any XML tree at all.
• If it’s an existing solution, it must allow non-GPL use (BSD style is ok, or perhaps LGPL) and it must be affordable.
• It must not require external administration, processes, daemons, etc.

Lofty to be sure, but I feel it’s possible, so we’ll see.

-Synwan

As I mentioned last post, we like to use the STL to process our XML. This really only works with datacentric XML documents. What I mean by datacentric XML, is XML that tends to hold collections of XML “records” with the same structure. An example would look like this:
<customers>
<customer>
<name>John Doe</name>
<address>
<street-address>123 N. Main</street-address>
<city>Beverly Hills</city>
<state>California</state>
<zip>90210</zip>
</address>
<comment>Rich guy</comment>
</customer>
<customer>
<name>Jane Doe</name>
<address>
<street-address>1235 Hill Ave</street-address>
<city>Beverly Hills</city>
<state>California</state>
<zip>90210</zip>
</address>
<comment/>
</customer>
</customers>

Given that XML tree, we could ask for a collection of customers, and using a std::sort, sort on zipcode. Then we could use std::for_each and a custom function to read each customer tree and populate a mail-merge app for a monthly mailing list.

We could also create a custom function that decorates the address tree with 5+4 digit zip codes. We could then get a collection of the zip code nodes. Using std::transform, and the function, we could iterate over each of these nodes, converting their zip codes, then, reinserting them into the tree, perhaps as a new node called <full-zip>.

Using datacentric XML can provide flexible data storing needs. We’ve found it to be an excellent solution for handling data for several different design patterns. Especially the decorator, and command patterns.

Ok, here’s a question? Am I the only one that loves the flexibility, self documenting nature, and general coolness factor of XML? And am I the only one that detests working with the DOM? My buddies and I have been coding together for over 3 years now. We’ve been using XML almost exclusively for data storage and communication. We love it, but we all hate working with the DOM. It’s tedious at best. We’ve written a wrapper to sit on top of the DOM. It contains the basic DOM functions for traversal, along with some STL adaptors so we can iterate over XML data trees using STL algorithms. We can iterate over a collection of nodes and extract a given bit of info, using XPath. We can generate new XMLNode trees from a collection of strings, structs, etc. We’re working on getting it out, but in the meantime, I’m curious if anyone else has any solutions that they use? Is everyone just a DOM user? Do you have wrappers? Anyway, I’m curious to hear about anyone else’s experience.

-Synwan