Creating Gnucash invoices with XML

[Neil Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 06 Apr 2004 1:26, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > That's the first job, build the DTD and enforce it.
> > (abort loading of XML files that don't match the DTD structure - that
> > will need to be done by 'proper' C XML handling libraries, libxml etc.)
>
> So you're suggesting a re-write of all the existing XML i/o to use
> verified schema instead of the existing hand-created generators and
> parsers?  Not that I'm against this idea, but doesn't that go against
> the grain of re-using the existing code?

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.

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.

> I suppose that's fine provided your plan is:
>
>   1) reverse-engineer the existing XML objects into Schemas
>   2) re-write the xml code to use schemas
>   3) drop rewrite in place of existing code

That would be the most flexible solution and it would open the door, 
hopefully, to all imports and exports from all sections.

> 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!
:-)

> But we already have the XML structures defined (albeit not in a
> Schema).  Been there, done that -- reuse what we've got unless you
> really want to re-write all the i/o.  But if you have limited time I
> see little reason to do that.

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?

> 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.

> >> 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.

> 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!

> 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!


- -- 

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAcwQAiAEJSii8s+MRAh/IAKCeMoEgP2PnEsvyJ4ubIs26vvFSewCg2VGy
VnBfoxgVMKImpEP9rVMGeCU=
=QsK9
-----END PGP SIGNATURE-----