SCHEMA.TAG ambiguity

[dthaler]

FamilySearch/GEDCOM.io#89 has an illustrative case:

1 SCHMA
2 TAG _PARTY http://example.com/party-participation
2 TAG _PARTY http://example.com/party

In the example above, the two URIs may differ in terms of what superstructures _PARTY can appear in.
However, there's no way for a GEDCOM processor to know which is the case without knowing the schema details.
Should there be a substructure under TAG that can list the superstructures? Or do we require the URI to resolve to a YAML file? Or do we leave it unusable by generic tools?

[tychonievich]

Possible 7.1 solution:

2 TAG _PARTY http://example.com/party-participation
3 TYPE SUBSTRUCTURE
4 CONTEXT https://gedcom.io/terms/v7/record-INDI
3 TYPE ENUM_VALUE
4 CONTEXT https://gedcom.io/terms/v7/enumset-EVEN
4 CONTEXT https://gedcom.io/terms/v7/enumset-EVENATTR
2 TAG _PARTY http://example.com/party
3 TYPE RECORD

For backwards compatibility, if there's no TAG.TYPE then its up to the application to understand the context.

For brevity, CONTEXT is optional, only needed when URIs share the same tag and TYPE. We could instead omit TYPE and only have CONTEXT, but that would make things like new event substructures (such as GEDCOM-L's _LOC substructure) very verbose to specify

Open design decisions:

• Should we have separate RECORD/SUBSTRUCTURE enumeration values or combine into a STRUCTURE enumeration value and add a URI for the CONTEXT of records?
• Should we require TYPE and/or CONTEXT to be exhaustive if provided (i.e. finding the tag where they don't apply is an error) or not (i.e. finding the tag there they don't apply means application discretion)?
• Given two TAGs with the same extTag, one with a TYPE and one without, does the one without apply in all cases that the one with doesn't apply or is it application discretion?

[tychonievich]

That said, I'm also open to explicitly referencing the YAML registry in the spec and saying applications need to consult it for duplicated extTags.

[tychonievich]

Discussed 2023-08-10
We think recommending that YAML files be available from registry or URL may be a simpler approach than adding content to the header.