Neil, Neil Williams <[EMAIL PROTECTED]> writes:
> When I started on this Palm->Invoice saga, the use of an XML interchange file > format was discussed. After looking at the current format, I am having to > discount the hierarchy based on AccountGroup because it cannot be easily > written by non-GnuCash applications - which may not have any explicit object > hierarchy in their QOF objects. 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. But I'd like to make as few changes to the "gnucash xml data file format" as possible. > It will mean writing a new format and handlers for backend/file but I'm up for > that. > > The main difference is that I would like to use the XML for data interchange > between QOF applications and to make the format more like a simple bag than a > tree: Nice in theory... but it does add issues when you have cross-object references which may (or may not) be explicit in the QOF definitions. Then you have to be very careful about ordering objects during load/save and might wind up with dangling pointers or half-completed objects. Not a major concen, just something to think about. > <?xml version="1.0"?> > <qof-bag-v1> > <qof:count-data cd:type="book">1</qof:count-data> > <qof:book version="1.0.0"> > <book:id type="guid">c0dd5ca1b11338f3ceae57f6e0106d75</book:id> > <qof:count-data cd:type="qof-expenses">1</qof:count-data> > <qof:object version="1.0.0" type="qof-expenses"> > <obj:desc type="qof-expenses">Pilot-link QOF expenses</obj:desc> > <obj:id type="guid">c9c3c49db198b3b87e8d513e618f9078</obj:id> > <obj:date type="expense_date">1099016941</obj:date> The date should probably be an actual XML Date string instead of a Unix Time number. > <obj:int32 type="type_of_expense">7</obj:int32> I'm also concerned about "int32 magic numbers" here. What does "type of expense 7" mean? 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. > <obj:int32 type="form_of_payment">2</obj:int32> > <obj:int32 type="currency_code">1</obj:int32> > <obj:int32 type="expense_amount">32</obj:int32> > <obj:int64/> > <obj:boolean/> Uh, shouldn't you at least have the parameter names for these attributes? > <obj:string type="expense_vendor">Company Name</obj:string> > <obj:string type="expense_city">City Name</obj:string> > <obj:string type="expense_attendees">Names</obj:string> > <obj:string type="expense_note">Any string content</obj:string> > <obj:gnc_numeric> > <obj:gnc_numeric_enum/> > <obj:gnc_numeric_denom/> > </obj:gnc_numeric> enum?? I think we should continue to encode gnc_numeric as XXX/YYY. > </qof:object> > </qof:book> > </qof-bag-v1> > > This way, the XML can hold any compatible QOF data. Hmm, I'm thinking this might be best for a bonobo-style interface but I'm not convinced how useful it would be for long-term storage. *ponders* > I'm still working on the map to convert one to another. -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 [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel