version 7.0.15 release

_pages/changelog.md

@@ -4,6 +4,46 @@ permalink: /changelog/
 sidebar:
 nav: "changelog"
 ---
+# Version 7.0.15
+
+- Clarified that `FORM`.`MEDI` describe the original medium, not the derived medium, when used with derived files.
+
+- Clarified the meaning of the `WWW` structure, which previously only mentioned its payload datatype.
+
+- Clarified `PLAC` to both define "jurisdiction" and document its meaning in the absence of a `PLAC`.`FORM`.
+
+- Clarified what the term "principal date" means in different contexts in the definition of `g7:DATE`.
+
+- Updated `NICK` to no longer suggest that some names are "improper" and to document the diversity of views in what a "nickname" is.
+
+- Removed confusing reference to superstructures in the meaning of a documented extension tag.
+
+- Added ABNF for more datatypes and updated DIGIT's capitalization for compatibility with more ABNF toolchains.
+
+- Various typo corrections.
+
+
+# Version 7.0.14
+
+- Recommend that `NO XYZ` only be used where `XYZ` is permitted (its meaning is undefined elsewhere).
+
+- Recommend that a given `INDI` have at most one `FAMC` pointing to a given `FAM` (having more than one has unclear meaning); and likewise that a given `FAM` have at most one `CHIL` pointing to a given `INDI` (having more than one indicates nonsensical birth order).
+
+- Refactor presentation of local files to better match related RFCs and only make implementable constraints, and to use its own `<FilePath>` datatype instead of `<Special>`. This does not change `FILE` payloads, only how they are specified to better support automated tooling.
+
+- Refactor the enumeration tags `CENS`, `EVEN`, `FACT`, `NCHI`, and `RESI` to have different URIs, removing a previous parsing ambiguity. This changes neither the set of tags permitted in any enumeration set nor those tags' meaning, only how they are specified to better support automated tooling.
+
+- Deprecate extension-defined substructures using `stdTag` in a way incompatible with any standard definition of that tag. The now-deprecated use was common in 5.5.1 and is permitted in 7.0, but can prevent extension structures from being adopted as-is as new standard structures in future versions of the specification.
+
+- Clarify that the "applies to" and "status" columns of `g7:enumset-ord-STAT` are recommendations, not restrictions.
+
+- Clarify that AGE values may be larger than any calendar supports. This was always permitted; that fact is now called out more clearly.
+
+- Clarify that records cannot be relocated standard structures. This was always incompatible with the definition of relocated standard structures; that fact is now called out more clearly.
+
+- Various typo corrections.
+
+
 # Version 7.0.13
 
 - Deprecated `ADR1`, `ADR2`, and `ADR3` which convey no information not already in `ADDR`.
@@ -79,7 +119,7 @@ nav: "changelog"
 
 - Changes anticipating a coming extension registry:
 
-    - Add URIs for sets of enumeration values. This has changes some fragment identifiers in the HTML version of the spec and could cause hotlinks to the specific sections discussing enumeration sets to change.
+    - Add URIs for sets of enumeration values. This changed some fragment identifiers in the HTML version of the spec and could cause hotlinks to the specific sections discussing enumeration sets to change.
 
     - Many updates to the YAML format served at <https://gedcom.io/terms/v7/record-INDI> and at the other URIs in the specification.
 
@@ -145,7 +185,7 @@ nav: "changelog"
         - `mul` can be used if there is no single primary language, but is unlikely to provide practical functionality beyond `und`.
         - `zxx` can be used for ASCII art and other non-language text, and can improve accessibility for screen readers.
 
-- Clarify that empty *payloads* are encoded as missing `LineVal`s and empty `LineVal`s are not been permitted; this has been true since 7.0.0 but was easily overlooked in the previous text.
+- Clarify that empty *payloads* are encoded as missing `LineVal`s and empty `LineVal`s are not permitted; this has been true since 7.0.0 but was easily overlooked in the previous text.
 
 - Note cases where the same couple might be the partners in multiple `FAM` records.
 
@@ -226,7 +266,7 @@ nav: "changelog"
 
 # Version 7.0.0
 
-As a major release and the first update to the specification in 20 years, there a many changes in this version.
+As a major release and the first update to the specification in 20 years, there are many changes in this version.
 
 This version is the first version to use [semantic versioning](https://semver.org/).
 7 was chosen as the new major version number because 1 through 6 were each used previously, some for released standards and others for abandoned drafts.
@@ -308,7 +348,7 @@ Earlier versions of GEDCOM predated language tags, media types, and Unicode beca
 
 ## New Extensibility
 
-- Every standard tag now has a single "default" meaning, even if it also has additional meanings in other contexts. Tags conforming to this default meaning can now be used by extensions as substructures of structures with extention tags.
+- Every standard tag now has a single "default" meaning, even if it also has additional meanings in other contexts. Tags conforming to this default meaning can now be used by extensions as substructures of structures with extension tags.
 
 - Extension tags remain in a backwards-compatible way, but should additionally be paired with a URI to avoid name collisions and provide documentation.
 
@@ -332,7 +372,7 @@ Earlier versions of GEDCOM predated language tags, media types, and Unicode beca
 
 - Age phrases are now only phrases, not long-hand terms for specific age ranges
 
-- Previously registered values (APPROVED_SYSTEM_ID, RECEIVING_SYSTEM_NAME, etc) are kept as-is if present; new ones are URIs instead of having a separate registration process
+- Previously registered values (APPROVED_SYSTEM_ID, RECEIVING_SYSTEM_NAME, etc.) are kept as-is if present; new ones are URIs instead of having a separate registration process
 
 - `RESI` may have a payload, just as all other attributes may
 
@@ -350,7 +390,7 @@ Various ambiguities were identified in version 5.5.1: some due to poor wording,
 
 - Dual-year dates were used with widely different semantics and have been replaced by more flexibility in date phrases.
 
-- `SEX` is now unambiguously biological sex at birth; all other related concepts (gender identity, sexual preference, sex reassignment, etc) are time-varying attributes and to be stored in an individual attribute instead
+- `SEX` is now unambiguously biological sex at birth; all other related concepts (gender identity, sexual preference, sex reassignment, etc.) are time-varying attributes and to be stored in an individual attribute instead
 
     Note that new tags were not introduced for gender-related attributes. It is not yet clear what the correct set of attribute types should be given the evolving and regionally-specific understanding of these concepts. The generic `FACT` is recommended for these concepts instead. 
 

_pages/tag-def/ABBR.md

@@ -31,6 +31,8 @@ substructures: {}
 
 superstructures:
   "https://gedcom.io/terms/v7/record-SOUR": "{0:1}"
+
+contact: "https://gedcom.io/community/"
 ...
 
 ```

_pages/tag-def/ADDR.md

@@ -20,31 +20,36 @@ standard tag: ADDR
 
 specification:
   - Address
-  - The location of, or most relevant to, the subject of the superstructure.
-    See ADDRESS_STRUCTURE for more.
+  - The location of, or most relevant to, the subject of the superstructure. See
+    `ADDRESS_STRUCTURE` for more details.
   - |
     A specific building, plot, or location. The payload is the full formatted
     address as it would appear on a mailing label, including appropriate line
-    breaks (encoded using CONT tags). The expected order of address components
-    varies by region; the address should be organized as expected by the
-    addressed region.
+    breaks (encoded using `CONT` tags). The expected order of address components
+    varies by region; the address should be organized as expected by the addressed
+    region.
 
-    Optionally, additional substructures such as STAE and CTRY are provided to
+    Optionally, additional substructures such as `STAE` and `CTRY` are provided to
     be used by systems that have structured their addresses for indexing and
-    sorting. If the substructures and ADDR payload disagree, the ADDR payload
-    shall be taken as correct. Because the regionally-correct order and
-    formatting of address components cannot be determined from the
-    substructures alone, the ADDR payload is required, even if its content
-    appears to be redundant with the substructures.
+    sorting. If the substructures and `ADDR` payload disagree, the `ADDR` payload
+    shall be taken as correct. Because the regionally-correct order and formatting
+    of address components cannot be determined from the substructures alone, the
+    `ADDR` payload is required, even if its content appears to be redundant with
+    the substructures.
 
-    ADR1 and ADR2 were introduced in version 5.5 (1996) and ADR3 in version
-    5.5.1 (1999), defined as “The first/second/third line of an address.” Some
-    applications interpreted ADR1 as “the first line of the street address”,
-    but most took the spec as-written and treated it as a straight copy of a
-    line of text already available in the ADDR payload.
+    <div class="deprecation">
+
+    `ADR1` and `ADR2` were introduced in version 5.5 (1996) and `ADR3` in version
+    5.5.1 (1999), defined as "The first/second/third line of an address." Some
+    applications interpreted ADR1 as "the first line of the *street* address", but
+    most took the spec as-written and treated it as a straight copy of a line of
+    text already available in the `ADDR` payload.
 
     Duplicating information bloats files and introduces the potential for
-    self-contradiction. ADR1, ADR2, and ADR3 should not be added to new files.
+    self-contradiction. `ADR1`, `ADR2`, and `ADR3` should not be added to new
+    files.
+
+    </div>
 
 label: 'Address'
 
@@ -114,6 +119,8 @@ superstructures:
   "https://gedcom.io/terms/v7/WILL": "{0:1}"
   "https://gedcom.io/terms/v7/record-REPO": "{0:1}"
   "https://gedcom.io/terms/v7/record-SUBM": "{0:1}"
+
+contact: "https://gedcom.io/community/"
 ...
 
 ```

_pages/tag-def/ADOP-FAMC.md

@@ -23,11 +23,11 @@ specification:
   - |
     The individual or couple that adopted this individual.
 
-    Adoption by an individual, rather than a couple, may be represented either
-    by pointing to a FAM where that individual is a HUSB or WIFE and using a
-    https://gedcom.io/terms/v7/FAMC-ADOP substructure to indicate which 1
-    performed the adoption; or by using a FAM where the adopting individual is
-    the only HUSB/WIFE.
+    Adoption by an individual, rather than a couple, may be represented either by
+    pointing to a `FAM` where that individual is a `HUSB` or `WIFE` and using a
+    `https://gedcom.io/terms/v7/FAMC-ADOP` substructure to indicate which 1
+    performed the adoption; or by using a `FAM` where the adopting individual is
+    the only `HUSB`/`WIFE`.
 
 label: 'Family child'
 
@@ -38,6 +38,8 @@ substructures:
 
 superstructures:
   "https://gedcom.io/terms/v7/ADOP": "{0:1}"
+
+contact: "https://gedcom.io/community/"
 ...
 
 ```

_pages/tag-def/ADOP.md

@@ -20,10 +20,10 @@ standard tag: ADOP
 
 specification:
   - Adoption
-  - An Individual Event. See also INDIVIDUAL_EVENT_STRUCTURE.
+  - An [Individual Event]. See also `INDIVIDUAL_EVENT_STRUCTURE`.
   - adoption
-  - Creation of a legally approved child-parent relationship that does not
-    exist biologically.
+  - Creation of a legally approved child-parent relationship that does not exist
+    biologically.
 
 label: 'Adoption'
 
@@ -58,6 +58,8 @@ superstructures:
 value of:
   - "https://gedcom.io/terms/v7/enumset-EVEN"
   - "https://gedcom.io/terms/v7/enumset-EVENATTR"
+
+contact: "https://gedcom.io/community/"
 ...
 
 ```

_pages/tag-def/ADR1.md

@@ -21,11 +21,16 @@ standard tag: ADR1
 specification:
   - Address Line 1
   - |
-    The first line of the address, used for indexing. This structure’s payload
-    should be a single line of text equal to the first line of the
-    corresponding ADDR. See ADDRESS_STRUCTURE for more.
+    The first line of the address, used for indexing. This structure's payload
+    should be a single line of text equal to the first line of the corresponding
+    `ADDR`. See `ADDRESS_STRUCTURE` for more details.
 
-    ADR1 should not be added to new files; see ADDRESS_STRUCTURE for more.
+    <div class="deprecation">
+
+    `ADR1` should not be added to new files; see `ADDRESS_STRUCTURE` for more
+    details.
+
+    </div>
 
 label: 'Address Line 1'
 
@@ -35,6 +40,8 @@ substructures: {}
 
 superstructures:
   "https://gedcom.io/terms/v7/ADDR": "{0:1}"
+
+contact: "https://gedcom.io/community/"
 ...
 
 ```

_pages/tag-def/ADR2.md

@@ -21,11 +21,16 @@ standard tag: ADR2
 specification:
   - Address Line 2
   - |
-    The second line of the address, used for indexing. This structure’s payload
-    should be a single line of text equal to the second line of the
-    corresponding ADDR. See ADDRESS_STRUCTURE for more.
+    The second line of the address, used for indexing. This structure's payload
+    should be a single line of text equal to the second line of the corresponding
+    `ADDR`. See `ADDRESS_STRUCTURE` for more details.
 
-    ADR2 should not be added to new files; see ADDRESS_STRUCTURE for more.
+    <div class="deprecation">
+
+    `ADR2` should not be added to new files; see `ADDRESS_STRUCTURE` for more
+    details.
+
+    </div>
 
 label: 'Address Line 2'
 
@@ -35,6 +40,8 @@ substructures: {}
 
 superstructures:
   "https://gedcom.io/terms/v7/ADDR": "{0:1}"
+
+contact: "https://gedcom.io/community/"
 ...
 
 ```

_pages/tag-def/ADR3.md

@@ -21,11 +21,16 @@ standard tag: ADR3
 specification:
   - Address Line 3
   - |
-    The third line of the address, used for indexing. This structure’s payload
-    should be a single line of text equal to the third line of the
-    corresponding ADDR. See ADDRESS_STRUCTURE for more.
+    The third line of the address, used for indexing. This structure's payload
+    should be a single line of text equal to the third line of the corresponding
+    `ADDR`. See `ADDRESS_STRUCTURE` for more details.
 
-    ADR3 should not be added to new files; see ADDRESS_STRUCTURE for more.
+    <div class="deprecation">
+
+    `ADR3` should not be added to new files; see `ADDRESS_STRUCTURE` for more
+    details.
+
+    </div>
 
 label: 'Address Line 3'
 
@@ -35,6 +40,8 @@ substructures: {}
 
 superstructures:
   "https://gedcom.io/terms/v7/ADDR": "{0:1}"
+
+contact: "https://gedcom.io/community/"
 ...
 
 ```

_pages/tag-def/AGE.md

@@ -20,8 +20,8 @@ standard tag: AGE
 
 specification:
   - Age at event
-  - The age of the individual at the time an event occurred, or the age listed
-    in the document.
+  - The age of the individual at the time an event occurred, or the age listed in
+    the document.
 
 label: 'Age at event'
 
@@ -70,6 +70,8 @@ superstructures:
   "https://gedcom.io/terms/v7/SSN": "{0:1}"
   "https://gedcom.io/terms/v7/WIFE": "{1:1}"
   "https://gedcom.io/terms/v7/WILL": "{0:1}"
+
+contact: "https://gedcom.io/community/"
 ...
 
 ```

_pages/tag-def/AGNC.md

@@ -20,11 +20,10 @@ standard tag: AGNC
 
 specification:
   - Responsible agency
-  - The organization, institution, corporation, person, or other entity that
-    has responsibility for the associated context. Examples are an employer of
-    a person of an associated occupation, or a church that administered rites
-    or events, or an organization responsible for creating or archiving
-    records.
+  - The organization, institution, corporation, person, or other entity that has
+    responsibility for the associated context. Examples are an employer of a person
+    of an associated occupation, or a church that administered rites or events, or
+    an organization responsible for creating or archiving records.
 
 label: 'Responsible agency'
 
@@ -85,6 +84,8 @@ superstructures:
   "https://gedcom.io/terms/v7/RETI": "{0:1}"
   "https://gedcom.io/terms/v7/SSN": "{0:1}"
   "https://gedcom.io/terms/v7/WILL": "{0:1}"
+
+contact: "https://gedcom.io/community/"
 ...
 
 ```

_pages/tag-def/ALIA.md

@@ -22,15 +22,19 @@ specification:
   - Alias
   - |
     A single individual may have facts distributed across multiple individual
-    records, connected by ALIA pointers (named after “alias” in the computing
+    records, connected by `ALIA` pointers (named after "alias" in the computing
     sense, not the pseudonym sense).
 
-    This specification does not define how to connect INDI records with ALIA.
-    Some systems organize ALIA pointers to create a tree structure, with the
-    root INDI record containing the composite view of all facts in the leaf
-    INDI records. Others distribute events and attributes between INDI records
-    mutually linked by symmetric pairs of ALIA pointers. A future version of
-    this specification may adjust the definition of ALIA.
+    <div class="note">
+
+    This specification does not define how to connect `INDI` records with `ALIA`.
+    Some systems organize `ALIA` pointers to create a tree structure, with the root
+    `INDI` record containing the composite view of all facts in the leaf `INDI`
+    records. Others distribute events and attributes between `INDI` records
+    mutually linked by symmetric pairs of `ALIA` pointers. A future version of this
+    specification may adjust the definition of `ALIA`.
+
+    </div>
 
 label: 'Alias'
 
@@ -41,6 +45,8 @@ substructures:
 
 superstructures:
   "https://gedcom.io/terms/v7/record-INDI": "{0:M}"
+
+contact: "https://gedcom.io/community/"
 ...
 
 ```