New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
draft that removes under-specified extended-use standard structures #24
Conversation
I've love feedback on the new "requirements and recommendations" section, particularly the new items:
Should this be a recommendation instead?
Is this the right order? |
Co-authored-by: Dave Thaler <dthaler@microsoft.com>
::: | ||
|
||
As a special case, a tagged extension structure can be defined to have a standard structure type. | ||
These are called **relocated standard structures** and can only appear with superstructures that are not documented as a superstructure of that structure type in this specification. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 forTIME
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.
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
2 TAG _DATE https://gedcom.io/terms/v7/DATE
then we can use_DATE
iff we can't useDATE
to mean ag7:DATE
.