GnuCash XML spec (for non-C languages?)

[Graham Leggett]

On 06 Nov 2012, at 3:28 PM, Geert Janssens <janssens-geert at telenet.be> wrote:

> 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.

It's not XSD's job to enforce this kind of thing, you're always going to reach a garbage-in-garbage-out problem that XSD won't protect you from.

The two key things that an XSD allows you to do is validate the overall structure of the gnucash file, and to generate code. This "generate code" part is the killer feature, it suddenly becomes very easy (therefore desirable) to develop new gnucash based tools.

> 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.

We should formalise the schema too.

Without formalised data formats, there is no way to tell whether something is a bug, or a feature.

> 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.

Certainly.

Initially we might insert these as XSD comments and XSD documentation, and then perhaps investigate where XSD might enforce things for us.

Regards,
Graham
--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4365 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20121106/4d861e04/attachment.p7s>