-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 06 Apr 2004 1:26, Derek Atkins wrote: > Neil Williams <[EMAIL PROTECTED]> 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----- _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
