Was looking for something else but found a tag-by-tag assessment of Gramps’ GEDCOM 5.5.1 import. Thought I’d post it (and a couple previous ones) here for future reference.
In GEDasssement dot com’s summary, counts ranged from tools correctly handling 121 tags to 229 tags. Gramps was 4th at 187 tags handled “correctly” by their standards.
2 Likes
That link is not working anymore. Do you have a copy of the assessment report?
Here is the 22 Mar 2022 snapshot of John Cardinal’s GEDCOM Assessment v1.05 on the Wayback Machine (Internet Archive).
Contacted John Cardinal on 14 Apr 2024. He had determined there was too little traffic to justify the cost of the domain, hosting and the ongoing testing project. The site has been permanently discontinued.
Two of the enhancements to Gramps’ Date type phrases for 5.2 were in open-ended date spans: ‘From’ and ‘To’ dates.
Errors when importing From and To dates were SIX of of the Date Validation issues.
Now that Gramps supports those Date Span Type formats, perhaps we could have a Developer discussion thread that describes how to add support for such an expansion in Gramps? (Or perhaps that came for free when the Date Handler was improved??? Both import and export of open-ended date spans worked with the 5.2.1 version.)
Used as an example, people might be willing to tackle enhancing the GEDCOM 5.5.1 import one-tag-at-a-time. And possibly adding some common GEDCOM dialect custom tags too.
Likewise, the tests 31-34 (e.g., #33 “INT 3 MAR 1914 (Phrase)”) tag just means the phrase is known as an internal date format for the exporting software. I think the expectation may be wrong for these tests. To pass the test, all Gramps would have to do is attempt to parse the phrase and convert it to a date instead of text. (Which is easy to do with a 3-line SuperTool script as a post-import process.) But I wonder if the GEDCOM intent wasn’t to have a Date Display Format override for a valid date?
Perhaps we could revisit how the GEDCOM import annotates data that could not be imported?
When the parser finds tags that does not recognize, it does not discard the data (which is good) but it does take structured data and encase in a less structured note that complicates post-processing (which is bad)
It also appears to be slow.
Perhaps the annotation output could be refined into something that makes it more actionable?
Rather than a unstructured Note, perhaps the annotation could leverage the Citation structure? So, instead of making post-processing harder, the added evaluation structure would make it more approachable.