Creating Gnucash invoices with XML

[Derek Atkins]

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

> Yes, it's a pity the I/O is one lump of code - in order to do any work on 
> partial files, let alone DTD's (not necessarily schemas which are slightly 
> different), I'd expect to have to do more work than expected on this bit.

It depends on your definition of "one lump of code".  I would have to
look at the code to be sure, but IIRC the API is effectively:

  int load_xml(const char* filename, GNCBook* book)

but I'm not completely sure.  It may make some assumptions about
the session..

> Thereagain, IF the XML data file format is to be abandoned, this might be no 
> bad thing. The one good thing is that I should still be able to reuse the 
> bindings, getting the XML data into GList etc. 
>
> This is getting to be a much larger project than I anticipated.

Ignore the XML side.  Assume you have the above API already
implemented; the work is merging the "new" GNCBook* into the existing
GNCBook*.  This is the hard work that needs to be done.

>> I just suspect this is a lot of work for (IMHO) little gain.
>
> I know, I'm trying hard to convince myself - don't put me off!
> :-)

Why not?  IMHO the more interesting work is the merge.  It's necessary
in either case, so why not write it first and get some new
functionality instead of re-writing existing code?  You need to write
the merge code in either case, so why not write it first?

> How soon will gnucash leave the XML data file behind? Once that's done, I'll 
> have a free hand to rewrite the XML I/O. The current I/O would need to be 
> retained, perhaps as a secondary program, for backwards compatibility?

I don't know..  This depends on resource availability.  Even when the
default file format is "changed", there's no plan to rip out the XML
code, just change how it's used.  We definitely still need to read XML
files to up-convert from 1.8 data files.  And we probably still need
an export-to-XML to send data to 1.8.  So I don't expect the XML code
to be ripped out.

HOWEVER, that doesn't mean we can't re-use the existing XML parsers in
an XML importer.

>> Honestly, if you want to implement a "gnucash XML import" I'm 100% behind
>> you, and I think it's a great idea.  I'm not trying to derail that concept.
>> I think it's a GREAT idea.
>
> Maybe I can do this in two stages. Work with the current I/O for now with a 
> view to just getting a limited XML import functioning. Then work on the 
> backend.
>
> I could start by making the current I/O into a standalone file that outputs 
> the content in GList (much like your CSV test program) and then getting that 
> to accept partial input.

EH?  Why do that?

>> >> Yes, the xml parsers need to be modified to not require a full book.
>> >> Not TOO difficult, I don't think.
>
> It'll take me a while to get to know the hand-crafted parser, I'm used to 
> standard ones.

Consider it an abstraction that isn't flexible.  It works effectively
the same as a schema-driven parser.  You give it an XML document and
it gives you back a set of data objects in a GNCBook.

>> IMHO, yes.  I think the bulk of the task is the merging.  You need to
>> determine what data in the import maps to the existing data, what data
>> is new, and what data is a duplication.  I think this is the hardest
>> part.  There's been a good deal of work to do this with Transactions,
>> but not with Accounts, or any of the business features.
>>
>> NOTE: a general API to "merge two books" would be a good potential
>> solution.
>
> I agree, but this task is already big enough for me. I'm OK in C but I'm no 
> wizard!

Well, this "merge two books" is the code you'd need to write
regardless of whether you decide to re-write the parsers.  If you
consider this too much work for you then give up now and save yourself
the headache.  The "merge" function is necessary AND sufficient for
the functionality you want.  The XML parser re-write is neither
necessary nor sufficient.

>> Yes.  Although it might behoove you to collect all the events and save
>> the applause until all the names have been called.  If you've got 100
>> events, would you rather have 100 pop-ups or a window with a list of
>> 100 items?  Personally I'd rather have the latter.
>
> Definitely. Having just had a bad day with KPilot - offering a collision 
> dialog one per contact for 30 contacts - it's NOT fun!

HEHE.

-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