update build/README and release 7.0.5

build/README.md

@@ -7,25 +7,27 @@ This directory is used to convert the `specifications/gedcom.md` source file int
     - [python 3](https://python.org)
     - [pandoc](https://pandoc.org)
     - [weasyprint](https://weasyprint.org) installed by running `python3 -mpip install --user --upgrade weasyprint`
+        - Note: version 52.5 was notably faster than later versions;
+            `python3 -mpip install --user weasyprint==52.5` will install that version instead of the latest version.
     - [git](https://git-scm.com/)
     - `make`-compatible executable
 
 2. From the directory containing this README, run `make`
 
 # Pushing to [gedcom.io](https://gedcom.io)
 
-A script is provided to assist in uploading tag definitions and rendered specifiations to gedcom.io. To use it
+A script is provided to assist in uploading tag definitions and rendered specifications to gedcom.io. To use it
 
-1. Clone <https://github.com/FamilySearch/GEDCOM.io/> into a local diretory
+1. Clone <https://github.com/FamilySearch/GEDCOM.io/> into a local directory
 2. From the directory containing this README, run
 
     ````sh
     make
-    python3 path/to/GEDCOM.io
+    python3 push_to_gedcomio.py path/to/GEDCOM.io
     ````
 3. From the GEDCOM.io directory
 
-    1. `git add _pages/tag-def/*.md`
+    1. `git add _pages/tag-def/*.md specifications/FamilySearchGEDCOMv7.*`
     2. `git commit` and `git push`
 
 # Building -- how it works

extracted-files/tags/FAM-RESI

@@ -8,7 +8,11 @@ standard tag: RESI
 
 descriptions:
   - Residence
-  - A Family Attribute. See also FAMILY_ATTRIBUTE_STRUCTURE.
+  - |
+    A Family Attribute. See also FAMILY_ATTRIBUTE_STRUCTURE.
+
+    See https://gedcom.io/terms/v7/INDI-RESI for comments on the use of payload
+    strings in RESI structures.
   - residence
   - An address or place of residence where a family resided.
 

extracted-files/tags/HEAD-LANG

@@ -9,10 +9,25 @@ standard tag: LANG
 descriptions:
   - Language
   - |
-    The language in which the Text-typed payloads of all structures in the
-    document appear, except as superseded by a https://gedcom.io/terms/v7/LANG.
+    A default language which may be used to interpret any Text-typed payloads
+    that lack a specific language tag from a https://gedcom.io/terms/v7/LANG
+    structure. An application may choose to use a different default based on
+    its knowledge of the language preferences of the user.
 
     The payload of the LANG structure is a language tag, as defined by BCP 47.
+
+    Some algorithms on text are language-specific. Examples include sorting
+    sequences, name comparison and phonetic name matching algorithms,
+    spell-checking, computer-synthesized speech, Braille transcription, and
+    language translation. When the language of the text is given through a
+    https://gedcom.io/terms/v7/LANG, that should be used. When
+    https://gedcom.io/terms/v7/LANG is not available,
+    https://gedcom.io/terms/v7/HEAD-LANG provides the file creator’s suggested
+    default language. For some language-specific algorithms, the user’s
+    preferred language may be a more appropriate default than the file’s
+    default language. User language preferences can be found in a variety of
+    platform-specific places, such as the default language from operating
+    system settings, user locales, Input Method Editors (IMEs), etc.
 
 payload: http://www.w3.org/2001/XMLSchema#Language
 

extracted-files/tags/INDI-RESI

@@ -8,7 +8,23 @@ standard tag: RESI
 
 descriptions:
   - Residence
-  - An Individual Attribute. See also INDIVIDUAL_ATTRIBUTE_STRUCTURE.
+  - |
+    An Individual Attribute. See also INDIVIDUAL_ATTRIBUTE_STRUCTURE.
+
+    Where possible, the residence should be identified in PLAC and/or ADDR
+    substructures of the RESI structure. The payload text should not duplicate
+    PLAC or ADDR information, but may be used for residence information that
+    cannot be expressed by those structures.
+
+    The following two examples show situations where a RESI payload may be
+    appropriate:
+
+        1 RESI living with an aunt
+        2 DATE ABT MAR 1894
+
+        1 RESI in a mobile caravan
+        2 PLAC , , Austro-Hungarian Empire
+        3 FORM City, County, Country
   - residence
   - An address or place of residence where an individual resided.
 

extracted-files/tags/PLAC

@@ -10,10 +10,10 @@ descriptions:
   - Place
   - |
     The principal place in which the superstructure’s subject occurred,
-    represented as a [List] of jurisdictional entities in a sequence from from
-    the lowest to the highest jurisdiction. As with other lists, the
-    jurisdictions are separated by commas. Any jurisdiction’s name that is
-    missing is still accounted for by an empty string in the list.
+    represented as a [List] of jurisdictional entities in a sequence from the
+    lowest to the highest jurisdiction. As with other lists, the jurisdictions
+    are separated by commas. Any jurisdiction’s name that is missing is still
+    accounted for by an empty string in the list.
 
     The type of each jurisdiction is given in the PLAC.FORM substructure, if
     present, or in the HEAD.PLAC.FORM structure. If neither is present, the

extracted-files/tags/SDATE

@@ -16,7 +16,7 @@ descriptions:
     should be used for sorting and positioning while the DATE should be
     displayed as the date of the structure.
 
-    SDATE and it substructures (including PHRASE, TIME, and any extension
+    SDATE and its substructures (including PHRASE, TIME, and any extension
     structures) should be used only as sorting hints, not to convey historical
     meaning.
 

extracted-files/tags/TYPE

@@ -22,20 +22,22 @@ descriptions:
     Using the subordinate TYPE classification method provides a further
     classification of the superstructure but does not change its basic meaning.
 
-    A MARR with a TYPE could clarify what kind of marriage was performed:
+    A ORDN with a TYPE could clarify what kind of ordination was performed:
 
         0 @I1@ INDI
-        1 MARR
-        2 TYPE Common Law
+        1 ORDN
+        2 TYPE Bishop
 
-    This classifies the entry as a common law marriage but the event is still a
-    marriage event.
+    This classifies the entry as an ordination as a bishop, which is still a
+    ordination event. The event could be further clarified with RELI, DATE, and
+    other substructures.
 
     Other descriptor values might include, for example,
 
     -   “Stillborn” as a qualifier to BIRT (birth)
-    -   “Tribal Custom” as a qualifier to MARR (marriage)
+    -   “Civil” as a qualifier to MARR (marriage)
     -   “College” as a qualifier to GRAD (graduation)
+    -   “Oral” as a qualifier to WILL
 
     See also FACT and EVEN for additional examples.
 

extracted-files/tags/record-SNOTE

@@ -35,10 +35,10 @@ descriptions:
         2 NOTE Named after the astronaut Gordon Cooper
         2 SNOTE @GORDON@
 
-    Although sharable notes have been present since version 5.0 was released in
-    1991, as of 2021 relatively few applications have a user interface that
-    presents shared notes as such to users. It is recommended that SNOTE be
-    avoided when NOTE will suffice.
+    The ability to have multiple structures share a single note using pointers
+    was introduced in version 5.0 in 1991. However, as of 2021 relatively few
+    applications have a user interface that presents shared notes as such to
+    users. It is recommended that SNOTE be avoided when NOTE will suffice.
 
     A SHARED_NOTE_RECORD may contain a pointer to a SOURCE_RECORD and vice
     versa. Applications must not create datasets where these mutual pointers

extracted-files/tags/type-Date

@@ -67,7 +67,11 @@ descriptions:
     a substructure (such as a PHRASE or TIME) is desired.
 
     Versions 5.3 through 5.5.1 allowed phrases inside DateValue payloads. Date
-    phrases were moved to the PHRASE substructure in version 7.0.
+    phrases were moved to the PHRASE substructure in version 7.0. A current
+    limitation, however, is that a phrase in the PHRASE substructure cannot
+    specify a language, so if a non-default language is needed to correctly
+    interpret the phrase, then <<EVENT_DETAIL>>.SOUR.DATA.TEXT can be used
+    instead along with a LANG substructure.
 
     As defined by the grammar above, every date must have a year. If no year is
     known, the entire date may be omitted.