QIF spec ambiguity in example file

[Daniel White]

Hi Biloti,

It was me who initially wrote the QIF post. Anyway, glad you
sympathize with my problem. I've studied other specs such as
MIDI, CSV, and vCard, and despite being more complicated (other than CSV,
which is nevertheless (in practice) much more involved than one might  
expect!),
they seem to at least be clearer on the basics.

People, whether accidentally or deliberately, for good or for bad, tend
to extend, adjust, misuse, or even abuse the specification. It's hard  
enough
to write an interpreter when the specification is perfectly concise,  
explicit
and non-ambiguous due to people not following the spec. When the spec  
itself
is unclear, then we have a potential catastrophe.

Anyway, what may help us to reverse engineer the format is to look for
qif files out in the wild. They seem to be surprisingly few in number
for such a popular format. Type this into Google: filetype:qif

Regards, Daniel



On Mon, 28 Apr 2014 12:42:58 +0100, Ricardo Biloti <biloti at gmail.com>  
wrote:

> Dear John
>
> I totally agree with you. I am trying myself to write some scripts to
> produce QIF file from my personal sources and I am struggling with lack  
> of
> precise information on QIF specification.
>
> Personally, I would like to see the complete reference for the (subset)  
> QIF
> format that Gnucash understands, as well as a rich list of sample
> transactions and their QIF translation.
>
> Regards,
> Biloti
>
> Em 27/04/2014 11:28, "John Ralls" <jralls at ceridwen.us> escreveu:
>
>>
>> On Apr 27, 2014, at 5:13 AM, twinbee42 at skytopia.com wrote:
>>
>> > Hi John, I've just been looking over your article on the QIF
>> specification and have been pondering an apparent ambiguity in the  
>> "Sample
>> Files" example QIF file at the end. I was wondering if you'd be so kind  
>> to
>> help clarify things.
>> >
>> > Here's the article:
>> >
>> >
>> http://svn.gnucash.org/trac/browser/gnucash/trunk/src/import-export/qif-imp/file-format.txt
>> >
>> > After the "!Account" line, we have listed the control chars: N, T, D,  
>> Q,
>> T, P, N, L, Y. However, the only control chars listed for the "Account
>> Information Format" are: N, T, D, L, /, and $. So I'm guessing Q, P and  
>> Y
>> must be referring to perhaps the control chars from the "Investment
>> transaction format". However that doesn't seem to be made clear (as  
>> there's
>> no caret symbol to say the "Account Information Format" section is over.
>> >
>> > A further piece of confusion arises since T is listed twice ("TInvst"
>> and "T500"), and so T there means two different things. Also, D looks  
>> like
>> a date ("D10/30/2006"). However D is also a control char for the  
>> "Account
>> Information Format" which should mean "Description". When parsing this
>> algorithmically, how can I tell which one it's supposed to be? A human  
>> can
>> obviously tell it's a date, but I'm surprised, since specifications are
>> usually much more rigid as there can be sometimes be numbers (or even a
>> date) in a description if it's simply arbitrary text.
>> >
>>
>> As a general rule one shouldn't write developers directly. Most projects
>> have mailing lists for handling user enquiries. Ours is
>> gnucash-users at gnucash.org, and I've copied that list on this reply.
>> Please subscribe to that list and direct any further correspondence  
>> there.
>>
>> As it happens, I'n not the author of that file, just the last person to
>> have touched it for a reason unrelated to its content. I don't know much
>> about the QIF spec or the importer. Someone who does can answer your
>> questions on the list.
>>
>> Regards,
>> John Ralls
>>
>>
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/