QSF XML file backend for gnucash-gnome2-dev branch

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

> QOF_TYPE_INT64 and QOF_TYPE_NUMERIC support aren't as robust as I intended, 
> but I can fix it.

oops.  :)

> At present, if prefix is given to autogen.sh as:
> --prefix=/opt/garfield/qof
> the schemas get installed to:
> /opt/garfield/qof/share/qsf/
> for QOF.
>
> In GnuCash, for a prefix of:
> --prefix=/opt/garfield/gnucash
> the schemas are installed into:
> /opt/garfield/gnucash/share/qsf/
>
> On a standard package install, that would be:
> /usr/share/gnucash/share/qsf
> (other directories in gnucash/ being bin/ lib/ etc.)
>
> If you want that to be:
> /opt/garfield/gnucash/share/xml/qsf/
> and
> /usr/share/gnucash/share/xml/qsf/
>
> That's easy. I used qsf/ to distinguish from any other xml formats.

Uh, well, /usr/share/gnucash/share/xml/qsf is just wrong, regardless.
Keep in mind that we've got two types of installs,
--enable-opt-style-install and the 'normal' install.  In a normal
install with --prefix=/usr the files should go into:

/usr/share/xml/qsf
  or
/usr/share/xml/gnucash

In an opt-style install with --prefix=/opt/gnucash the files should
go into:

/opt/gnucash/share/xml
  or
/opt/gnucash/share/xml/qsf

I don't have a strong opinion which choices you make.

> The QSF usually contains only a partial book and certainly doesn't have to 
> contain AccountGroup so it can't be loaded as the main GnuCash book - nothing 
> will show up in the CoA in most cases. It needs to be merged into an existing 
> book somehow.
>
> So, you can't really load QSF directly (at least, not always) - on Open, the 
> final code can inform the user that the QSF will be merged into the current 
> QofBook, giving the option to abort.

Fair enough...  In the long run I want to move completely away from
XML as a "storage" format.  But that's still a ways away.

> I will sort out the File -> Import menu later. I just figured that someone, 
> sometime, is going to try and open the file directly with File -> Open and I 
> ought to make sure it identified it correctly. Plus it was easier to test it 
> there than to add a whole new menu option and all the code that goes with it.

Sure..  Get it working, then get the UI to work well around it.  A
pretty UI without any guts is rather useless, no?  :)

>> > QSF increases the libxml2 requirement to 2.6.0 for the gnome2 branch to
>> > support the schema validation which identifies QSF files relative to
>> > existing files.
>>
>> This is a major issue.  Our target platform has libxml2-2.5.10, not
>> 2.6.  We cannot depend on 2.6.
>
> I thought it was OK to go to 2.5.2?  I just thought I'd play safe by going for 
> 2.6.

2.5.2 is okay.  2.5.10 is okay.  2.5.11 is maybe okay.  2.6 is not okay.

> https://lists.gnucash.org/pipermail/gnucash-devel/2005-January/012511.html
>> > FWIW, requiring libxml2 >= 2.5.2 shouldn't be a problem.  Even RH9
>> > (updates) distributes 2.5.4, and FC1 uses 2.5.11 by default.  So I
>> > don't see this as a problem.
>
> I can go back to 2.5.2 but schemas simply weren't supported before that.
>
> There may be a few problems at 2.5.2 - schemas were very new - but it should 
> be OK - I'm not making huge demands on the schema code, at least not until I 
> get to grips with KVP.

You don't have to go back to 2.5.2; but you should go back to 2.5.10.
RHEL3 ships 2.5.10.  FC1 ships 2.5.11.  Those are the target
platforms, IMHO, so it should work with those versions.  The fact that
it continues to work with 2.6 is a Good Thing, but it should work with
2.5.1[01].

>> Why is QOF_TYPE_KVP a challenge?
>
> Maps. I knew this would be the hardest part and it's not disappointing me.
> :-(

I dont understand?  Assume gnucash<->gnucash -- why is KVP so hard?
(Keep in mind that I'm significantly less interested in
gnucash<->non-gnucash ;)

> Trying to calculate KVP frames from other object data is not my idea of fun. 

Why?  You know that a transaction note maps to <kvp type="string"
path="/notes"> so I would think that would be relatively easy to map,
no?

> If I can handle them as defaults, booleans or some other lookup method, I 
> will. I'd rather have 6 user defaults than a 6 level tree within the QSF. It 
> makes validation a pig and it makes mapping v.complex.

See josh's comment about validation.  IMHO (and in my personal
experience) validation is a lot of overhead for very little gain.
Just throw an error when you actually parse the data if you see
something in the document that you don't expect and can't handle.
Gnucash has lived without validation for, what, 4, 6 years now?  Has
it suffered horribly for the lack of validation?  I certainly don't
think so.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available