On Friday 29 October 2004 6:15 pm, you wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > It's more of a format for QOF that any QOF compatible program can use for > > their own data. > > In other words it's a "QOF Object Serialization Format"?
Yes. QOFOSF? Or just QSF? > No, it's not for parsing reasons, it's for communicating between > machines that have a difference concept of the epoch. Also, XML > already has a standard DateTime format (ISO8601); we should continue > to use it. OK. > >> What if the enumeration changes? IMHO it's much > >> better to say "expense_type PAYMENT" or some other string value that's > >> more "human readable" and doesn't tie into a specific enumeration > >> implementation. > > > > OK, can do. However, this will be a specific implementation - the > > pilot-link one. Each implementation would use the same tags with > > different type attributes and content. Which is where the name collisions > > come in. > > Of course.. But the pilot-link QOF Implementation will define the > pilot-link QOF objects, the Gnucash implementation will define the > gnucash QOF objects. Then you can map across them in a way that if > the enumeration changes in one implementation you don't have to fix > the map. OK. Rather than simply writing out the objects and their parameters in a blind and rigorous way - which might be appealing initially but does have problems when the objects are modified - I'll do some basic translation of the core data before writing out readable versions that are less affected by small changes in the code. I should have thought of that. Thanks. > > You mean as: > > <obj:gnc_numeric>XXX/YYY</obj:gnc_numeric> > > Yes, that's what I mean. > > While I'm not against this, I'm concerned that it will add more code > > to gnucash that may not be used much. �Perhaps it will. �I don't know. I'm hoping it will be used for all kinds of imports, especially those like the ones on the user list at the moment where people have data in unusable formats and out of sheer frustration have written their own scripts to create an XML format of their own. If this serialization or QSF format can be documented clearly, it should divert attention from the more fraught tampering with the main GnuCash XML data file and the future SQL backend (which, in a MySQL form, is possibly even more appealing to those who would fiddle and hack their own import data). By having a format that is easier to write than the current gnucash XML (and which will take care of the relationships between objects itself) it should make life easier for everyone. I did think of having two forms, one that takes the pilot-link code and uses a hard-coded map to do the conversion (as the mapping code for a generic map is nowhere near as accessible as I'd like) and one that is suitable for hand-editing or basic Perl script formation which uses familiar objects from GnuCash and which simply needs the book merge code but no particular mapping. I prefer the idea of keeping just one format, just let people hack their own files into the QSF format for pilot-link - that could be much easier but potentially could limit users to business type objects - I'll have to look at whether the one format could support transactions as well as entries, no particular reason why not. There are finance applets for the Palm that could be queried by QOF to provide normal transactions and some users may well want to import their Expenses as transactions rather than invoice entries. Keeping one format and one mapping should keep the door open for more generic mechanisms in the future too. Whichever way, this whole approach will be limited to data outside the remit of gncCommodity until that is altered to work with QOF. Stocks, shares and accounts that use a different currency wouldn't be supported. Even the code to merge the QofBook from an existing GnuCash XML data file will not be able to support gncCommodity in that way. > > But I'd like to make as few changes to the "gnucash xml data file > > format" as possible. With the above changes, are you happy for me to use this format for QOF as a serialization format? I can adapt the existing GnuCash file:// backend to be part of QOF and QOF will write out the pilot-link objects using qof_object_foreach rather than by strictly following a hierarchical tree like the one based on AccountGroup. GnuCash doesn't have to write QSF format but perhaps it could use it to export just the customer list or a batch of invoices and as exporting is always easier than importing, there might not be a reason to avoid it. I really can't see how else I can create an XML data interchange if we stick to only the current hierarchical structure - this should be a small amount of new code with large benefits. -- 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
pgpx0EH2jv8IM.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
