New XML file format for QOF?

[Neil Williams]

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. 

> 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.

I know, that worried me too. 

> Not a major concen, just something to think about.

> >   <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?

> >   <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.

> 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.

> >   <obj:int64/>
> >   <obj:boolean/>
>
> Uh, shouldn't you at least have the parameter names for these
> attributes?

If this was a real file, yes, those lines were just put in to show the other 
types that could be used. Empty tags (thinking about it) probably wouldn't be 
written out.

> >   <obj:gnc_numeric>
> >    <obj:gnc_numeric_enum/>

Oops. What I meant to do was to split the numerator and denominator parts of 
the gnc_numeric and I slipped an 'e' in there by mistake.

<obj:gnc_numeric_numerator/>

> >    <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>

> > 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've been thinking around this area a lot and there had to be a way to do this 
already. OAF may be the way. I'll investigate how OAF provides long term 
storage and whether this XML will be useful or not.

-- 

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20041029/29327d99/attachment.bin