Addon:Lxml Gramplet
lxml gramplet is an experimental gramplet working under POSIX platform(s), which reads, writes, transforms our Gramps XML file on the fly without an import into our database (Gramps session).
Contents
Dependencies and file format
- lxml is a Pythonic binding for the C libraries libxml2 and libxslt. It is known for good performances by using C-level (Cython).
- Gramps XML file format is robust and well documented.
Goals
The idea of this experimental lxml gramplet is to provide a way for using basic lxml features with Gramps XML files.
XPath, Xslt, RelaxNG validation, can be used and done by lxml, which provides an API very close to etree ElementTree module from python 2.5 and later.
The experimental lxml gramplet aims to use these lxml features[1] by parsing a Gramps XML file generated by Gramps 3.3.x and to generate an output sample, using open W3C standards (XML, Web design, Web services, etc ...).
[1] see also lxml.objectify
Test it
You can get a copy of this draft from Addon repository:
http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons/branches/gramps33/contrib/lxml
Currently, this addon explores multiple ways. Feel free to modify for your own use.
Go further
Comments on DB API Idea
I was basically approaching it from the leave gen.lib alone and
implement a "fully blown" SimpleAccess-esque solution.
At the moment I basically have a 'DB' object which represents an open
database. This at the moment is populated from a Gramps XML file. This
is then basically stored as lxml.objectify objects. Internally a graph
structure is built to represent the linking inside the database (so
relationships and ref. integrity is made easier).
'DBItem' objects consist of the 'node' data, the basic save/delete
etc... Deleting an event automatically removes all other references to
it (which has caught me out previously).
class Person(DBItem):
DBTYPE = 'person'
Basically registers an object that 'wraps' a basic DBItem, but
containing useful attributes/methods. So for a person, we can write
attributes such as .birth, .mother, .families etc... etc... It can also
over-ride how it should be saved/retrieved etc...
I chose this approach because it keeps the process incremental. We can
still access the 'raw' data in a DBItem for the stuff I'm not caring
about at the moment, but someone can write a 'Place' class later for
instance.
The DB itself is an xpath queryable object (adds a bit of flexibility
for selections that don't have convenient attributes as of yet).
I'll see if I can get the code example out this week.
Anyway, does this seem a reasonable approach?
source: Archive (Dec 07, 2009) on gramps-devel mailing list
Data transfer
Experimental phase for typeless data entry !
Database compare and merge
- GrampsCompare.py, a python script for comparing data in 2 Gramps xml files.
