Case sensitivity for controlled enumerations

[webtrees-pesz]

Are payload values in enumerations case-sensitive?

In GEDCOM 5.5.1 there was a rule, that all controlled line_value choices should be considered as case insensitive. Is this rule still valid?

The Compatibility Report Generator for GEDCOM 7 distinguishes between
1 RESN CONFIDENTIAL, LOCKED
and
1 RESN confidential, locked

Best regards
Peter

[dthaler]

This is a great question. The GEDCOM 5.5.1 spec was clear because the RESTRICTION_NOTICE values were controlled line_value choices.

The FamilySearch GEDCOM 7 spec however doesn't have the same language. The only language similar to the quote about controlled line_value choices is:

Double-quote delimit literal strings. Literal strings are case-insensitive unless they are preceded by %s.

However, enumerations are not listed in the spec as delimited by double-quotes, and so the above text does not apply if taken literally, since enumerated values are not "literal strings".

I suspect this is not the intent and this may be a bug in the FamilySearch GEDCOM 7 spec if so.

[webtrees-pesz]

Hello Dave,

I found the answer meanwhile in the spec.

Enum = Tag
Tag = stdTag / extTag
stdTag = ucletter tagchar
extTag = underscore 1tagchar
tagchar = ucletter / digit / underscore

[dthaler]

That quote is different, that's about the characters in tag names, as opposed to characters in values.
I now suspect it is not a bug and the enumeration values were intentionally changed to be uppercase only.
For example, the "FROM" and "TO" in a date period were case insensitive in GEDCOM 5.5.1 and are explicitly case sensitive in FamilySearch GEDCOM 7. I suspect the same is true for all controlled line value choices.

[tychonievich]

The intent of the 7.0 authoring team was that all case-insensitive components of 5.5.1 should be standardized to upper-case. We did this by

• using %s"FROM" and the like in all literal values in the ABNF grammar
• using upper-case letters in the ABNF for Tag and Enum

This change was inspired by reports that case insensitivity was a common source of incompatibilities between implementations. By removing case insensitivity we hope to make more applications interoperable with 7.0 than they were with 5.5.1.