New XML file format for QOF?

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

> On Friday 29 October 2004 3:48 pm, you wrote:
>> 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'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"?

>> >   <obj:date type="expense_date">1099016941</obj:date>
>>
>> The date should probably be an actual XML Date string instead of a
>> Unix Time number.
>
> Is that for parsing reasons? Isn't the number (as universal time) just as 
> independent of timezone issues?

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.

>> >   <obj:int32 type="type_of_expense">7</obj:int32>
>>
>> I'm also concerned about "int32 magic numbers" here.
>
> That, I thought to use to tell another QOF process that the content is a 
> QOF_TYPE_INT32 (or 64 etc). Just trying to match the existing QOF types to 
> the tags.

Yes, but different implementations may use different enumerations.
For example, the gnucash account type enumeration changed between
versions.

>> What does "type 
>> of expense 7" mean?
>
> shorthand - it's the value for the #define EXPENSE_TYPE used in the QOF 
> definitions. The value 7 is as output by the Palm, it is an enum internal to 
> Palm that would be defined by the map. It can be expanded.
>
>> 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.

>> >    <obj:gnc_numeric_denom/>
>> >   </obj:gnc_numeric>
>> enum??  I think we should continue to encode gnc_numeric as XXX/YYY.
>
> You mean as:
> <obj:gnc_numeric>XXX/YYY</obj:gnc_numeric>
> rather than one tag for XXX and one for YYY?
> <obj:gnc_numeric_numerator>XXX</obj:gnc_numeric_numerator>
> <obj:gnc_numeric_denom>YYY</obj:gnc_numeric_denom>

Yes, that's what I mean.

-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