Enabling an extension-to-standard workflow

[tychonievich]

Objective: If an extension is well liked, we should be able to make it standard without changing its structure types or URIs. That way parsers could be written with a stand-alone tag-to-URI front-end and all of the semantics using URIs, allowing the standardization to have only parser-end impact on the implementation.

Challenge: Currently, extension tags get special dispensation in how they behave.

As written in 7.0.2,

• a structure with a standard tag has its substructure types limited by the spec
• a structure with an extension tag does not have its substructure types limited by the spec
  Notably, this is about tags, not structure types; thus in the following example

1 SCHMA
2 TAG _NAME https://gedcom.io/terms/v7/NAME
2 TAG _DATE https://gedcom.io/terms/v7/DATE
0 SUBM
1 NAME Banned
2 DATE 1903
0 SUBM
1 _NAME Permitted
2 DATE 1903
0 SUBM
1 NAME Also Permitted
2 _DATE 1903

• the first DATE is prohibited because g7:NAME has no DATE substructure
• the second DATE is permitted because an structure with an extension tag has no substructure limitations
• the third DATE is permitted because it uses an extension tag

My instinct is that the third should be permitted: it can be seen as a proposal that g7:NAME be allowed a g7:DATE substructure. But the second should not: if you are proposing a new name that can have a date, it should have a new structure type.

Proposal: change the current text

An extended-use standard structure is a structure whose type, tag, and meaning are defined in this document and whose superstructure is a tagged extension structure.

to

An extended-use standard structure is a structure whose type, tag, and meaning are defined in this document and whose superstructure has a structure type that is not defined in this document.

This issue is also related to #13 which also addresses extended-use standard structures and may need to be updated depending on how that issue is resolved.

[tychonievich]

Alternatively, we could simply always allow an undocumented standard structure anywhere. Which will make our life easier in several ways (e.g., we'd not need two CENS, two NCHI, etc) but make validation a bit less robust.

[tychonievich]

The proposed wording is not precise enough, implicitly allowing arbitrary tags

[tychonievich]

resolved by #24