The logic behind getDisplayType()

[michelesalvador]

Current behavior of EventFact.getDisplayType() is to return a display type obtained from the tag of the event.

0 @F1@ FAM
1 MARR

The tag MARR produces the display type "Marriage". So far, so good.

Things change when a TYPE is defined. Take for example:

0 @F1@ FAM
1 MARR
2 TYPE Common Law

In this case the display type of Marriage is "Other".

But the GEDCOM standard (5.5.1 more than 5.5) clearly suggests another use for TYPE value:

{Size=1:90} A descriptive word or phrase used to further classify the parent event or attribute tag. [...] Using the subordinate TYPE tag classification method with any of the other defined event tags provides a further classification of the parent tag but does not change the basic meaning of the parent tag. For example, a MARR tag could be subordinated with a TYPE tag with an EVENT_DESCRIPTOR value of `Common Law.' 1 MARR 2 TYPE Common Law This classifies the entry as a common law marriage but the event is still a marriage event.

So, for my comprehension, the result of getDisplayType() should be yet "Marriage", or maybe something like "Marriage (Common Law)", but not "Other".

At last, if the value of TYPE is present among personal or family event fact tags, the correspondent display type is returned:

0 @F1@ FAM
1 MARR
2 TYPE CLAW

The display type of this Marriage event will be "Common law marriage". Even if this example can appear correct, in GEDCOM standard I found no trace that the TYPE value can be a tag that completely replaces the parent tag.

[stoicflame]

Fair enough. I'm happy to merge a pull request.

[michelesalvador]

To be honest, the same names DISPLAY_TYPE and getDisplayType no longer seem correct to me, because here it's nothing about the type, it's about the main definition of an event... So they may be something like DISPLAY_NAME and getDisplayName.