LDS_ORDINANCE_DETAIL: DATE vs STAT

[dthaler]

Is it legal for both DATE and STAT to appear under the same LDS ordinance structure? If so, under what circumstances?

<<LDS_ORDINANCE_DETAIL>>.DATE seems to be defined as the date the ordinance was done. <<LDS_ORDINANCE_DETAIL>>.STAT has values where most of them mean the ordinance was not needed or not done. In such cases, it would seem that <<LDS_ORDINANCE_DETAIL>>.DATE would not be permitted.

STAT COMPLETED is specifically defined as "Completed, but the date is not known." Does that mean that no <<LDS_ORDINANCE_DETAIL>>.DATE should be present? Or that an estimate like "ABT 1970" is permitted? But if "DATE ABT 1970" is present, then "STAT COMPLETED" would be redundant.

STAT CANCELED is defined as "Canceled and considered invalid." Does this mean that a <<LDS_ORDINANCE_DETAIL>>.DATE is permitted, which is the date the original ordinance was done, and then STAT.DATE would be the date it was canceled? Or would <<LDS_ORDINANCE_DETAIL>>.DATE be the date it was canceled?

[tychonievich]

I'm hesitant to weigh in on this because the church that defined these structures no longer uses them in any official capacity. I think it is permissible to do anything that was not prohibited by 5.5.1, the last standard where these fields might have been provided by the church. We could recommend against duplicate or contradictory data, but I don't think we can forbid it.

On your specific question about STAT and DATE:

• BIC or CHILD or INFANT or STILLBORN with DATE could mean an ordinance was performed despite not being needed
• COMPLETED or PRE_1970 with DATE could mean it was performed twice, or the DATE is a guess (but not necessarily an EST or ABT: I might have a journal entry giving the date even though no date is available from the church)
• The presence of DNS_CAN suggests DNS without CANCELED is also possible, and hence both might have dates
• The 5.5.1 specification didn't clarify which date the DATE with STAT CANCELED is, so we can't assume that two files with it mean the same date.

I also note that you've touch just the tip of the iceberg in what could be seen as invalid. Per church policy it's illegal to have a CONL without a BAPL, or a STAT BIC without a FAMC.SLGS, or an ENDL with SEX M and a post-ENDL.DATE DEAT.DATE without an ORDN, or any number of other combinations. My preference is to leave these specified as they are and not get into the topic of what makes sense.

[dthaler]

Discussion 21 JUN 2022: GEDCOM should be capable of recording seemingly contradictory things such as CONL with no BAPL or CONL before BAPL. But we can clarify use of STAT vs DATE?

Suggestion to split the STAT enumeration values into current vs obsolete values. Also add a column saying which ordinances are valid for which values (e.g., DNS only for SLGC, SLGS). Current: BIC, CANCELED, CHILD, DNS Obsolete: EXCLUDED, DNS_CAN (could be obsoleted if we added ), INFANT, COMPLETED (but would need [Y|], PRE_1970, STILLBORN?, SUBMITTED, UNCLEARED

[lynchrs3]

I believe COMPLETED is still current. FamilySearch uses NOT NEEDED instead of CHILD. (Based on a 21 JUN 2022 review.)

[dthaler]

I believe COMPLETED is still current.

Follow up question: When would you have a current use of COMPLETED without a DATE?

FamilySearch uses NOT NEEDED instead of CHILD. (Based on a 21 JUN 2022 review.)

Good to know. However, "NOT NEEDED" is not a legal FamilySearch GEDCOM 7 value. CHILD is the present GEDCOM equivalent.

[dthaler]

Consider for next minor:

• Allow [Y|<null>] on ordinance structures
• Allow <List:Enum> instead of DNS_CAN

[tychonievich]

I started to work on a patch for next-minor but ran into several problems.

1. Adding [Y|<null>] is not minor

   If we add [Y|<null>] to the LDS ordinance structures, we would presumably have to add the justification for it present under events, which is currently

   Event structures can be used to record notes about an event without asserting the event actually occurred. An event structure asserts the event did occur if any of the following are true: [... lists DATE, PLAC, and Y as the three ways to assert it did happen ...]

   There is no indication like this in 7.0 for LDS ordinances. If we add "no Y means it might not have happened" in 7.1 I think we change the implied meaning of Y-lacking 7.0 files, which cannot happen in a minor release of the spec.

2. Removing DNS_CAN is not minor. Adding <List:Enum> is minor, but introduces two ways to handle the same data and I'm hesitant to do that. Do we have use cases motivating this additional flexibility? I'm not immediately seeing why we'd combine any of the other non-deprecated values.