Derek Atkins <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> writes: > > > Derek Atkins <[EMAIL PROTECTED]> writes: > > > > > The problem is that data import is "lossy", you don't necessarily have > > > all the import information in the GNC Transaction. For example, you > > > lose the QIF Category name, but you DEFINITELY want to be able to map > > > from QIF Category to GNC Account. > > > > Well, my first reaction is that importing shouldn't be lossy. Having lossy > > steps closes options such as being able to show the user where a transaction > > came from and what the information the bank presented was. I could see that > > being useful in a dispute with a bank or debugging problems after the fact. > > Argubly it has to be, considering the GNC format is very different > from the QIF format, which is very different than OFX or HBCI... So > by definition you're going to have SOME loss.
Well what I meant was that the transaction should keep a copy of the original raw data it was imported from. double clicking to view a transaction detail should show the user what the raw data was. > Perhaps, but there is a good reason for this. There is call for > actually using separate data stores for different periods, for example > one XML data-file per year. The reason is that XML is LARGE, and you > necessarily need to read/parse a complete XML document. After several > years your data file can get to be tens or maybe even hundreds of > megabytes -- why force users to load all that extraneous data? I guess I'm not impressed by XML. It feels weird to be driving major design decisions from the fact that XML is bloated and cannot be parsed incrementally. -- greg _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
