On 06-11-12 14:14, Graham Leggett wrote:
On 06 Nov 2012, at 12:22 PM, Christian Stimming <[email protected]> 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
constraints.
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.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
