QSF XML file backend for gnucash-gnome2-dev branch
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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