Neil Williams <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
