New XML file format for QOF?

[Neil Williams]

On Friday 29 October 2004 6:15 pm, you wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > It's more of a format for QOF that any QOF compatible program can use for
> > their own data.
>
> In other words it's a "QOF Object Serialization Format"?

Yes. QOFOSF? Or just QSF?

> No, it's not for parsing reasons, it's for communicating between
> machines that have a difference concept of the epoch.  Also, XML
> already has a standard DateTime format (ISO8601); we should continue
> to use it.

OK.

> >> What if the enumeration changes?  IMHO it's much
> >> better to say "expense_type PAYMENT" or some other string value that's
> >> more "human readable" and doesn't tie into a specific enumeration
> >> implementation.
> >
> > OK, can do. However, this will be a specific implementation - the
> > pilot-link one. Each implementation would use the same tags with
> > different type attributes and content. Which is where the name collisions
> > come in.
>
> Of course..  But the pilot-link QOF Implementation will define the
> pilot-link QOF objects, the Gnucash implementation will define the
> gnucash QOF objects.  Then you can map across them in a way that if
> the enumeration changes in one implementation you don't have to fix
> the map.

OK. Rather than simply writing out the objects and their parameters in a blind 
and rigorous way - which might be appealing initially but does have problems 
when the objects are modified - I'll do some basic translation of the core 
data before writing out readable versions that are less affected by small 
changes in the code. I should have thought of that. Thanks.

> > You mean as:
> > <obj:gnc_numeric>XXX/YYY</obj:gnc_numeric>
>
> Yes, that's what I mean.

> > While I'm not against this, I'm concerned that it will add more code
> > to gnucash that may not be used much.  Perhaps it will.  I don't know.

I'm hoping it will be used for all kinds of imports, especially those like the 
ones on the user list at the moment where people have data in unusable 
formats and out of sheer frustration have written their own scripts to create 
an XML format of their own. If this serialization or QSF format can be 
documented clearly, it should divert attention from the more fraught 
tampering with the main GnuCash XML data file and the future SQL backend 
(which, in a MySQL form, is possibly even more appealing to those who would 
fiddle and hack their own import data). By having a format that is easier to 
write than the current gnucash XML (and which will take care of the 
relationships between objects itself) it should make life easier for 
everyone.

I did think of having two forms, one that takes the pilot-link code and uses a 
hard-coded map to do the conversion (as the mapping code for a generic map is 
nowhere near as accessible as I'd like) and one that is suitable for 
hand-editing or basic Perl script formation which uses familiar objects from 
GnuCash and which simply needs the book merge code but no particular mapping.

I prefer the idea of keeping just one format, just let people hack their own 
files into the QSF format for pilot-link - that could be much easier but 
potentially could limit users to business type objects - I'll have to look at 
whether the one format could support transactions as well as entries, no 
particular reason why not. There are finance applets for the Palm that could 
be queried by QOF to provide normal transactions and some users may well want 
to import their Expenses as transactions rather than invoice entries. Keeping 
one format and one mapping should keep the door open for more generic 
mechanisms in the future too.

Whichever way, this whole approach will be limited to data outside the remit 
of gncCommodity until that is altered to work with QOF. Stocks, shares and 
accounts that use a different currency wouldn't be supported. Even the code 
to merge the QofBook from an existing GnuCash XML data file will not be able 
to support gncCommodity in that way.

> > But I'd like to make as few changes to the "gnucash xml data file
> > format" as possible.

With the above changes, are you happy for me to use this format for QOF as a 
serialization format? I can adapt the existing GnuCash file:// backend to be 
part of QOF and QOF will write out the pilot-link objects using 
qof_object_foreach rather than by strictly following a hierarchical tree like 
the one based on AccountGroup. GnuCash doesn't have to write QSF format but 
perhaps it could use it to export just the customer list or a batch of 
invoices and as exporting is always easier than importing, there might not be 
a reason to avoid it. I really can't see how else I can create an XML data 
interchange if we stick to only the current hierarchical structure - this 
should be a small amount of new code with large benefits.

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- 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/20041030/cf09d5e1/attachment.bin