QSF XML file backend for gnucash-gnome2-dev branch

Neil Williams linux at codehelp.co.uk
Wed Jan 26 03:13:43 EST 2005

On Wednesday 26 January 2005 12:01 am, Josh Sled wrote:
> > Quite - QSF will never write an invalid XML file, nor accept one for
> > input. I was just waffling, as usual.
> Well -- and please correct me if I'm wrong on this -- it sounds like one
> can create a session which only contains only a subset of a
> self-[referentially-]consistent object graph, and serialize that
> fragment.  It would be valid XML, but semantically invalid because of
> missing data...

Only by hand editing the file or deliberately constructing QOF objects that 
don't have a full list of parameters.

As long as the objects ARE self-consistent, they cannot be semantically 
invalid - it is the job of the map to fill in any missing data. That's how I 
get 3 pilot-link objects to form 4 GnuCash objects which in turn refer to 
multiple objects in GnuCash that are completely unknown to the Palm.

e.g. With the invoice, all the datebook and expenses data can go to the 
relevant parameters of GncEntry and GncInvoice, etc. Contacts get looked up 
in GncCustomer. Fine. But the Palm knows nothing about which *accounts* to 
use for that customer or that invoice. That is set in the map. The 
calculations in the map need to remain fixed if the map is to work, but the 
defaults can be user-edited.

Which reminds me:

Q. Where should I put user-edited files? In with the reports?

These will be maps that the user edits - e.g. the example map has a default 
for the mileage rate to claim. That obviously needs to be user-editable. The 
modified map would then be stored in userspace and would be used in 
preference to any matching map installed with the application.

Object files will be wherever the user chooses to save them on their 
filesystem - they can browse for those like any other file.

> Hmm.  I've written many XML parsers, and none _required_ a schema
> definiton to parse data....

OK, but parsing always requires that the incoming format is detectable and 
predictable. When these are user-edited object files, I would have to 
reinvent the majority of the schema to be sure that QSF could work with the 

> It looks like you're doing the majority of the parsing as a side-effect
> of the validation tree-traversal

No, the two are separate. I validate the file against the schema to detect the 
filetype. Then I validate the content to see if a map is required. Then I 
validate the map and cross reference the map with both the incoming QSF 
objects and the existing QOF objects in the application to determine the 
right map to use.

It's determining the filetype and validating the content that would require 
duplication of the schema code so that I know which tags will occur where.

> It certainly must be valid!  Doesn't necessarily need to be
> _validated_,  however.

The code must know which tags to find where - this is absolutely essential for 
the maps. The map is a complex sequential mask that overlays one set of 
objects to create another set. It is imperative that the map and the objects 
are 100% predictable. Data loss and data corruption would be inevitable 

> I.e., we don't need to compare the output XML to 
> some XML Schema definition [let alone a more reasonable
> schema-definition language].

It's hard enough as it is, without doing the validation by hand.

> > No. Although the code will handle it, the XML will not validate. IIRC,
> > the -0500 format won't validate, it would need to be -05:00. Try it with
> > xmllint
> Yeah, "-0500" is wrong, as per xsd:dateTime.

But you can't generate -05:00 using strftime without using regexps. Try it 
with the date command - it won't put the colon in.

> > It's a nice idea but when you get up close with xmllint, you can't format
> > the timezone to validate without using regexps. It's easier to use UTC
> > and Z.
> "Without using regexps" where?

Converting the libc time to a string, you'd need to insert a colon in the 

Anyways, I'm off to bed - you lot may be in the early evening, it's late this 
side of the pond!


Neil Williams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050126/67e98a44/attachment.bin

More information about the gnucash-devel mailing list