On 06 Nov 2012, at 3:28 PM, Geert Janssens <[email protected]> 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 --
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
