FamilySearch / GEDCOM.io

Files for the GEDCOM.io website
2 stars 5 forks source link

Extension tag URIs in YAML file #96

Closed dthaler closed 6 months ago

dthaler commented 11 months ago

https://gedcom.io/terms/format has an "extension tags" section which contains extTag values.

However the extTag is simply the tag:

extTag  = underscore 1*tagchar

and there seems to be nowhere to list the URI if any. So if we have a documented extension tag that is deployed today, with a URI pointing to a YAML file for it, and then later a standard tag is assigned, it will result in a new standard URI that is semantically equivalent to the documented extension tag's URI. But there seems to be no way to correlate these URIs as having the same meaning. One can add an HTTP redirect perhaps, but that seems fragile.

dthaler commented 11 months ago

https://gedcom.io/terms/format says:

A list, with the most-preferred tag first, of extension tags known to be used by applications for this concept.

Standard structures may have an extension tags entry to list fully compatible extensions that predated the standard and can be converted to the standard tag without any other modification. For example, 7.0’s UID structure is fully compatible with the common 5.5.1 extension identified by tag _UID.

However, that is insufficient since there can be multiple extension tags with the same extTag value, used by different applications. As a result, extTag is not sufficient to unambiguously say what extensions are fully compatible, and can be incorrectly taken to imply that ALL extensions that use a given extTag value are fully compatible with the standard. Hence, I believe that extTag should be replaced by a URI in the YAML file. If that is done, then I think that would also solve #95.

dthaler commented 11 months ago

Discussion during 9/28/2023 GEDCOM meeting: The same issue of two semantically equivalent URIs can arise when two different applications both create an extension that is equivalent, which has happened several times in the past.

dthaler commented 6 months ago

Fixed in PR #113 using subsumes to address this issue.