TMG-L Archives

Archiver > TMG > 2004-07 > 1088982069


From: Tim Powys-Lybbe <>
Subject: Re: [TMG] Spouses even though no marriage shown?
Date: Mon, 05 Jul 2004 00:01:11 +0100
References: <485ea3c84c.tim@south-frm.demon.co.uk> <8806b8c84c.tim@south-frm.demon.co.uk> <5a5dc4c84c.tim@south-frm.demon.co.uk> <07c333c94c.tim@south-frm.demon.co.uk> <6.1.0.6.2.20040704124705.02eb8cb0@popd.ix.netcom.com>
In-Reply-To: <6.1.0.6.2.20040704124705.02eb8cb0@popd.ix.netcom.com>


In message of 4 Jul, Dennis Lee Bieber <> wrote:

> On or about 07/04/04 05:01 a carrier pigeon from Tim Powys-Lybbe
> delivered:
>
>
> >This is where TMG is not reading the data in Generations correctly.
> >Generations would say that a couple's status is Marriage unless the
> >user has entered something different. That is how Generations works.
>
> Ah, but this requires one to know the "business rules" IMPLEMENTED
> by Generations. This is a much more complex arena than just reverse
> engineering from only the data tables. Anyone honest, given just the task
> of importing the data contained in a set of files, would follow what is in
> those files explicitly.

And I can't blame them for doing so.

But Wholly-Genes has advertised that they have built this super
Gen-Bridge facility to import naked files from a variety of other
genealogy systems. So they have to get the import right.

> Can you state, in a format usable for software engineering, the logic
> Generations uses when reading data from a file to come to some
> conclusion? These statements, if done to formal specifications look
> similar to:
>
> The import module shall generate a marriage event when the marriage-flag is
> set to 1 (marriage).
>
> The import module shall generate a marriage event when the marriage-flag is
> set to 0 (marriage unset).
>
> The import module shall generate a custom common-law marriage event when
> the marriage-flag is set to 3 (common-law marriage).
>
> The import module shall not generate a marriage event when the
> marriage-flag is set to 2 (unmarried).

I can't because I have no idea what the internal files of Generations
are like.

> Carry this process out for all criteria that Generations uses for
> determining marriage conditions. (Oh, that "shall not" in the last
> requirement, in the most strict specifications, is a "no-no" --
> requirements state what a program must perform, not what a program
> must not perform).

In fact I thing the last criterion is wrong as it gives the wrong thing
in TMG. An unmarried couple are living together. They cohabit. They
have children (which is usually why you enter them into your genealogy
system).

So the way this works in Generations means that the event to be created
in TMG should be in the marriage group, but this particular tag (I do
hope I have the right word) should be called Unmarried. If you do this
then the people appear as "spouses" ("lovers"?) in the Family and Tree
displays in Generations. With the present importing procedures they do
not appear together in the trees at all, which is wrong for how they
appear in Generations.

A similar thing should be done for the Common Law tag. This is more
than ever a marriage and should be put in the Marriage tag group and
not, like it and Unmarried tags are now, in the Custom tag group.


> Complaining about TMG's lack of knowledge of Generations computed
> marriage state would be similar to complaining about a "tax program"
> computing a large taxable income because it is working from data from
> another program that has a table of "person:gross income:#
> dependents" and one of "income:tax due" with no information that the
> value of "income" is based on "gross income - (# dependents *
> some-constant)".

We are not complaining about the lack of knowledge, only about the fact
that TMG has misinterpreted the Generations data through false, but
understandable, assumptions and we would like that corrected. The
challenge has been to get anyone to agree that TMG has a problem. This
problem has been complained of over one or two years by (ex-)
Generations users. While I first heard of the problem I had no idea what
it was as I did not then own a copy of TMG.

>
> Since disassembling Generations to find out the actual code logic is
> commonly frowned upon (if not illegal), one is left with
> black-boxing. Enter data into the program, and see what comes out
> the other side -- then use that knowledge to design the module that
> accesses the data files. I doubt that WG has the staff to try every
> possible means of data entry, with every possible program, to
> analyze and derive requirements for the import module(s). Not to
> mention, the staff -- being familiar with how TMG works --
> everything must be explicitly entered, quite likely would add
> marriage data, thereby masking Generation's implicit "marriage if
> not stated otherwise". So, I suspect WG is strictly reverse
> engineering the data files only, in the absence of the Generations
> program.

I would not expect Wholly-Genes to disassemble Generations nor any other
of the programs that Gen-Bridge will handle. I have every sympathy
with them in trying to work out what the data files of any other
program means. But Wholly-Genes decided to offer this excellent import
facility which certainly persuaded me to buy a copy of TMG. Already
two TMG problems on handling Generations files have been fixed since I
bought my copy of TMG. My hope is that this one will be fixed too.

One interesting fact with the Generations files is that they are
totally exchangeable with Reunion files for the Apple mac. (I have done
this successfully in the past.) Leister Productions who own the Reunion
program might be more willing to assist Wholly Genes than the current
lack of a clear developer of Generations.

--
Tim Powys-Lybbe
For a miscellany of bygones: http://powys.org

This thread: