RetroGen – Rethinking and Rework

I have been rethinking my approach to common gedcom tags such as notes and media, and the fact that media can have notes, to rework some of my logic. There is an old premise that the simple solutions are the best and when the logic of ones code is looking overtly complicated, it is sadly time to rethink, replan and redo ones work. My recoding approach has worked well for header and submitter tags, and tomorrow, I will brace myself for the more complex nature of redoing individuals tags (and latter still, families, repository, sources, events, media etc).

I have updated the entity relationship diagram as it contains a consolidated event files.

*     โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”      โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”      โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”     *
*     โ”‚ Individual โ”‚      โ”‚   Event    โ”‚      โ”‚  Citation  โ”‚     *
*     โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค      โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค      โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค     *
*     โ”‚Id      (PK)โ”œโ”€โ”€โ”ฌโ”€โ”€>โ”คId+No.  (PK)โ”œโ”€โ”€โ”€โ”€โ”€>โ”คId+No.  (PK)โ”‚     *
*     โ”‚Name        โ”‚  โ”œโ”€โ”€>โ”คId+Tag  (SK)โ”œโ”€โ”€โ”€โ”€โ”€>โ”คIdTagEv#(SK)โ”‚     *
*     โ”‚Sex         โ”‚  โ”‚   โ”‚Date        โ”‚      โ”‚Source Id   โ”œโ”€โ”€โ”€โ”€โ”*
*     โ”‚Birth Date  โ”‚  โ”‚   โ”‚Place       โ”‚      โ”‚Details     โ”‚    โ”‚*
*     โ”‚Death Date  โ”‚  โ”‚   โ”‚Details     โ”‚      โ”‚Apid        โ”‚    โ”‚*
* โ”Œโ”€โ”€โ”€โ”คChild Familyโ”‚  โ”‚   โ”‚Type        โ”‚      โ”‚Ref Note Id โ”œโ”€โ”€โ” โ”‚*
* โ”‚โ”Œโ”€โ”€โ”คSpouseFamilyโ”‚  โ”‚   โ”‚Ref Note Id โ”œโ”€โ”€โ”€โ”  โ”‚InlineRefId โ”œโ”€โ”€โ”ค โ”‚*
* โ”‚โ”‚  โ”‚Ref Note Id โ”œโ”€โ”€(โ”€โ” โ”‚InlineNoteIdโ”œโ”€โ”€โ”€โ”ค  โ”‚Media Id    โ”œโ”€โ”€(โ”โ”‚*
* โ”‚โ”‚  โ”‚InlineNoteIdโ”œโ”€โ”€(โ”€โ”ค โ”‚Media Id    โ”œโ”€โ” โ”‚  โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜  โ”‚โ”‚โ”‚*
* โ”‚โ”‚  โ”‚Media Id    โ”œโ”€โ”โ”‚ โ”‚ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ”‚ โ”‚  โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”  โ”‚โ”‚โ”‚*
* โ”‚โ”‚  โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ”‚โ”‚ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€(โ”€โ”ค  โ”‚    Note    โ”‚  โ”‚โ”‚โ”‚*
* โ”‚โ”‚  โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”‚โ”‚   โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”‚ โ”‚  โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค  โ”‚โ”‚โ”‚*
* โ”‚โ”‚  โ”‚   Family   โ”‚ โ”‚โ”‚   โ”‚ Repository โ”‚ โ”‚ โ”œโ”€>โ”คId+No.  (PK)โ”œ<โ”€โ”คโ”‚โ”‚*
* โ”‚โ”‚  โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค โ”‚โ”‚   โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค โ”‚ โ”‚  โ”‚Data        โ”‚  โ”‚โ”‚โ”‚*
* โ”‚โ”‚  โ”‚Id (PK)     โ”œโ”€(โ”˜โ”Œโ”€>โ”คId      (PK)โ”‚ โ”‚ โ”‚  โ”‚Newline CONTโ”‚  โ”‚โ”‚โ”‚*
* โ”‚โ”œโ”€>โ”คHusband Id  โ”‚ โ”‚ โ”‚  โ”‚Name        โ”‚ โ”‚ โ”‚  โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜  โ”‚โ”‚โ”‚*
* โ”‚โ””โ”€>โ”คWife Id     โ”‚ โ”‚ โ”‚  โ”‚Address     โ”‚ โ”‚ โ”‚  โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”  โ”‚โ”‚โ”‚*
* โ””โ”€โ”€>โ”คChild Id    โ”‚ โ”‚ โ”‚  โ”‚Ref Note Id โ”œโ”€(โ”€โ”ค  โ”‚   Media    โ”‚  โ”‚โ”‚โ”‚*
*     โ”‚Ref Note Id โ”œโ”€(โ”€(โ”€โ”โ”‚InlineNoteIdโ”œโ”€(โ”€โ”ค  โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค  โ”‚โ”‚โ”‚*
*     โ”‚InlineNoteIdโ”œโ”€(โ”€(โ”€โ”คโ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ”œโ”€(โ”€>โ”คId      (PK)โ”œ<โ”€(โ”คโ”‚*
*     โ”‚Media Id    โ”œโ”€โ”ดโ”€(โ”€(โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค โ”‚  โ”‚File        โ”‚  โ”‚โ”‚โ”‚*
*     โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜   โ”‚ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€(โ”€โ”ค  โ”‚Form        โ”‚  โ”‚โ”‚โ”‚*
*     โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”   โ”‚                 โ”‚ โ”‚  โ”‚Title       โ”‚  โ”‚โ”‚โ”‚*
*     โ”‚   Source   โ”‚   โ”‚                 โ”‚ โ”‚  โ”‚Ref Note Id โ”œโ”€โ”€โ”คโ”‚โ”‚*
*     โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค   โ”‚                 โ”‚ โ”‚  โ”‚InlineNoteIdโ”œโ”€โ”€โ”˜โ”‚โ”‚*
*     โ”‚Id      (PK)โ”œ<โ”€โ”€(โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€(โ”€(โ”€โ”โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜   โ”‚โ”‚*
*     โ”‚_Author     โ”‚   โ”‚                 โ”‚ โ”‚ โ”‚โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”   โ”‚โ”‚*
*     โ”‚Publisher   โ”‚   โ”‚                 โ”‚ โ”‚ โ”‚โ”‚ Submitter  โ”‚   โ”‚โ”‚*
*     โ”‚Repo Id     โ”œโ”€โ”€โ”€โ”˜                 โ”‚ โ”‚ โ”‚โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค   โ”‚โ”‚*
*     โ”‚ReferenceNo.โ”‚                     โ”‚ โ”‚ โ”‚โ”‚Id      (PK)โ”‚   โ”‚โ”‚*
*     โ”‚APID        โ”‚                     โ”‚ โ”‚ โ”‚โ”‚Name        โ”‚   โ”‚โ”‚*
*     โ”‚Repo Name   โ”‚                     โ”‚ โ”‚ โ”‚โ”‚Address     โ”‚   โ”‚โ”‚*
*     โ”‚Call Number โ”‚                     โ”‚ โ”‚ โ”‚โ”‚Media Id    โ”œโ”€โ”€โ”€โ”˜โ”‚*
*     โ”‚Ref Note Id โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€(โ”€โ”ค โ”‚โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜    โ”‚*
*     โ”‚InlineNoteIdโ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€(โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜*
*     โ”‚Media Id    โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜                       *
*     โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜             Note: Gedcom and Header omitted.*

Update; I have changed the processing to include using a stack of gedcom tags. When a higher-level gedcom tag is encountered, the parent (or prior) tag is pushed onto the stack. The child tags can be processed whilst referencing the parent on the stack and when a lower-level tag is encountered later on, the top value on the stack is popped, so the prior parent is apparent for use.

2 NAME Family Tree Maker for Windows
2 CORP The Software MacKiev Company
3 ADDR 30 Union Wharf,
4 CONT Boston, MA 02109,
3 CITY Boston
3 POST 02109
2 PHON (617) 227-6681
2 FAX (617) 227-6680
1 DATE 28 Sep 2019
1 FILE FTM2019.ged
2 VERS 5.5.1

For example, when the gedcom line of ‘3 ADDR 30 Union Wharf,’ is processed, there was a change (or increase) in gedcom level, so the ‘CORP’ tag is pushed onto the stack. When the ‘CONT’ tags are processed, again there was a change (oe increase) in gedcom levels, so the parent ‘ADDR’ tag was also pushed to the stack. When the ‘CITY’ tag is processed, this resulted in a lower-leveled tag, so the top value of ‘ADDR’ is pushed from the stack, so the prior parent of ‘CORP’ is top of stack for the processing of ‘CITY’ through ‘CTRY’.

The use of the stack makes the logic of differing levels are processing of tags appropriate to each level more viable and straight-forward.

%d bloggers like this: