Possibility to use RapidXml instead of Xerces-C++

[retifrav]

Hello. Have you considered using RapidXml instead of Xerces-C++ (or perhaps not instead but as an option)? Why one might want to do so is at least due to the complexity of building Xerces-C++ and its dependencies (especially for mobile platforms).

We've managed to replace Xerces-C++ with RapidXml in our in-house build of E57Format library, and that seems to work fine. I could probably submit a patch here, if you'll be interested.

If you have considered RapidXml, but decided not to use it for particular reasons, could you please share your reasoning? In that case it would be useful for us to maybe reconsider and stay with the original dependency of Xerces-C++.

One possible reason I can name myself: RapidXml hasn't been updated for many years now, so one probably should be cautious about using seemingly unmaintained code.

[Brynyard]

Hi, I'm the one who did the RapidXML port, and I'd recommend not using it as it's not actively maintained (which is a death sentence for any text processing lib) and is generally quite crude. The reason I used Rapidxml is because we where already using it in other parts of the project, so it had minimal impact for us.

Having a dependency on Xerces in e57format is quite silly, so I'll do the port again using a newer, a bit more capable library that is actively maintained. I'm currently leaning towards pugixml.

[asmaloney]

Hello!

To answer the initial question, yes I had considered replacing Xerces. It's much too heavy for the tiny bit of XML involved here. Years ago I looked at replacing it and that was part of what lead me to start a new implementation from scratch (as I mentioned over here and here). I also wanted to modernize the codebase, use a different license, and generally change the architecture/API, so a new implementation made sense. Then I stopped doing much with this library because I didn't think anyone was really using it anyways.

Fast-forward to 3.0 - this came about because some people started contributing some code and it got me looking at it again. So I pulled in a whole bunch of things I'd written for the new one which is how we have some testing, ASan, proper formatting, etc..

I recall looking at several Xerces replacement options. I agree with @Brynyard's assessment of RapidXML. (I also freely admit to an anti-Sourceforge bias - terrible UX - so that would have worked against it 😆 ) I too landed on... pugixml! So that's what I use in my alternate implementation.

All of that to say that I'd be happy to accept a changeover to pugixml if you want to submit a PR. I'm sure a lot of people would be thankful to be rid of Xerces.

[retifrav]

Great news all the way. That answers my questions, so I'll close this issue (unless you'd like to use it for tracking Xerces-C++-related things).