OK, good point, and something that can be addressed, when someone finds time for that. And that leads to questions like:
-
Would it be worth our (developers’) effort to create an exporter for places, which includes all attached notes, sources, etc? I don’t need that myself, because I work with a single large tree, but it can be a big time saver for users who work with separate ones.
-
Or could we just as well rely on an external tool, that reads a Gramps backup file, and does this outside Gramps? For me, that would work just as well, and it would allow me to write such a tool in a language that I’m way more proficient in, like C#, and another person might prefer Java for that. And an advanced Python developer could even write an independent tool that reads the pickled data from our database.
My personal view is that there is no real need to create another exporter, because a Gramps XML backup has the full database in it, and any smart person can figure out what to do with it, even without documentation, simply by reading the XML, and trying to make sens of that. That’s reverse engineering, and it can work quite well. It’s also what we do, when we’re confronted with an exotic GEDCOM file, created by a company that has better things to do, than to write documentation for competitors.
And in the case of places, one can also think of a selective import instead.