Gedcom 7: Planned handling of RESI

[Jefferson49]

If converting my Gedcom data to Gedcom 7, some validators throw errors/warnings about the RESI tag. The background for this is that Gedcom 7 seems to require a non-empty <Text> after the RESI tag.

RESI <Text> {1:1} g7:INDI-RESI
+1 TYPE <Text> {0:1} g7:TYPE
+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}

Do you already have some thoughts about how to handle the RESI tag in Gedcom 7? Will you copy the PLAC value to the <Text> value? This would be compliant to the standard. However, it introduces an additional redundancy to the already existing redundancy between PLAC and _LOC.

1 RESI Hammelburg, Landkreis Bad Kissingen, Bayern, DEU
2 DATE FROM SEP 1960 TO 10 OCT 1960
2 PLAC Hammelburg, Landkreis Bad Kissingen, Bayern, DEU
3 _LOC @P7268@

Another alternative would be to leave the <Text> empty and accept that some validators will throw errors/warnings.

[ric2016]

Do you already have some thoughts about how to handle the RESI tag in Gedcom 7?

No, and this should be handled in webtrees itself, if necessary, but:

Will you copy the PLAC value to the value? This would be compliant to the standard.

According to the spec, this shoudn't be done: "The payload text should not duplicate PLAC or ADDR information"

Another alternative would be to leave the empty and accept that some validators will throw errors/warnings.

Leaving it empty seems to be allowed by the spec, so it's actually the validators who are in error here.

[Jefferson49]

According to the spec, this shoudn't be done: "The payload text should not duplicate PLAC or ADDR information"

Thank you for the hint to this additional clarfication. I really like that there is a clear statement and an example how to use it.

Leaving it empty seems to be allowed by the spec, so it's actually the validators who are in error here.

Good to hear! While first looking at <Text>, I wrongly assumed it to be non-empty. After diving more deeply into the specification, I found "Text = *anychar", which is allowed to be empty.

Thank you for your feedback! I am happy that the result of the discussion is that we can continue to use the structure from 5.5.1!