GnuCash XML spec (for non-C languages?)

Geert Janssens janssens-geert at
Tue Nov 6 08:28:05 EST 2012

On 06-11-12 14:14, Graham Leggett wrote:
> On 06 Nov 2012, at 12:22 PM, Christian Stimming <christian at> wrote:
>> Hence, even though it is still not yet realistic to find a complete
>> specification of data store access independently from our C library, I think
>> it should be possible to do a specification of a subset of the data. And
>> applications that access and work on only that subset should then be possible.
>> Such as, an Android app that access a gnucash SQL data base, and using only
>> those specified features and data store elements. Voila, there we have our
>> multi-user multi-platform gnucash within reach…
> I think the biggest obstacle to using gnucash over the long term is the unstable data format, and the inability to interoperate. Once the data format is defined, everything flows from there.
> I think a formal XSD of the XML format would be a good start.
> I use an XSD that "works for me", but this isn't ideal, I want to use an XSD I can trust.
> Regards,
> Graham
> --
Just for completeness, let me repeat what has been said multiple times 
before: an XSD can't possibly describe the accounting constraints we 
impose (eg sum of all splits in a transaction should be zero). So at 
best an XSD can protect you from writing invalid gnucash-xml, but it 
can't help with ensuring the data still makes sense.

Also, xml is only one of the data store formats we support. There are 
also three flavours of SQL databases. Same there. You can formalize the 
database schema, but that doesn't help enforcing additional accounting 

Having said all that, I agree an official XSD/Db schema can be a start. 
Another layer describing the accounting constraints that have to be 
adhered to should be added at least though.


More information about the gnucash-devel mailing list