draft that removes under-specified extended-use standard structures

[tychonievich]

A solution to #13 using a different tack than #19:

Given we had defined a term "extended-use standard structures" but had not provided semantics for determining their meaning, this PR simply removes them entirely.

This PR also clarifies that

• _LOC.NAME is OK, and is defined in the specification for _LOC
• _LOC.NAME._XYZ is OK, and is defined in the specification for _XYZ not _LOC
• If we have 2 TAG _DATE https://gedcom.io/terms/v7/DATE then we can use _DATE iff we can't use DATE to mean a g7:DATE.

[tychonievich]

I've love feedback on the new "requirements and recommendations" section, particularly the new items:

• It is required that each extension structure type use the same payload type in each place it appears.

Should this be a recommendation instead?

• In order from most-preferred to least-preferred, the options for extensions are:
  1. A feature request for inclusion in a future version of this specification (and then waiting for that version's release).
  2. A relocated standard structure with a documented extension tag.
  3. A tagged extension structure, calendar, or enumerated value with a documented extension tag.
  4. An extension-defined substructure beneath a documented extension tag.
  5. A tagged extension structure, calendar, or enumerated value with a undocumented extension tag.
  6. An extension-defined substructure beneath an undocumented extension tag.

Is this the right order?
Do we want to express it like this? We could also do it as a set of "you shouldn't use X if Y will suffice" recommendations instead.

[dthaler]

Is there a technical reason for this limitation?
This might prevent arguably legitimate cases, such as DATE.TIME with local time, and DATE._TIME with UTC (say because an obit stated time of death, but the time zone boundary or DST rule was updated in a later year so listing the UTC disambiguates which time zone it was in at the time). With this one would have to define _TIME to use something other than g7:type-Time even if the syntax is the same as g7:type-Time. I just made up this use case right now and I don't need it, there may be other legit ones that people do need.

[tychonievich]

g7:type-Time is a payload type, not a structure type, and its not limited by this clause. It's perfectly OK to define a structure type _UTCTIME with payload type g7:type-Time and use it next to a g7:TIME structure type. But g7:TIME is a structure type and is limited by this clause.

Why the limit?

• g7:TIME should be a full description of the structure type. It shouldn't have variants for TIME vs _TIME as the tag.
• Structure types define semantics, and singular structures define semantics that don't generalize to plurality. Is a DATE with two TIMEs suppose to be an event that happened twice in a day, or under uncertainty about the time, or the same time in two time zones, or ...?

Result: if there's already a g7:TIME substructure, you can't define a new tag for it. Either it's already plural, in which case use several with tag TIME, or you have some new plural semantics in mind and should define a structure type to explain that.