New XML file format for QOF?

[Derek Atkins]

Neil,

Neil Williams <linux at codehelp.co.uk> 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
       warlord at MIT.EDU                        PGP key available