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
pgpeepgZF1kts.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
