@domorium/validator 1.8.0 → 1.8.2

package/CHANGELOG.md

@@ -2,6 +2,90 @@
 
 All notable changes to `@domorium/validator` are documented here.
 
+## 1.8.2 - 2026-08-18
+
+- **A tag written in mixed case is read as written, and the message says which tag
+  is meant.** `1 NoTe hello` was reported as "Unknown tag N" — the tag pattern held
+  upper case only, so it matched as far as `N` and `oTe hello` became the value, and
+  the reader was told about a tag that is nowhere in their file. The tag is now read
+  whole and the message says a tag is written in upper case, naming `NOTE`. Where
+  case is not the problem, `1 NOTEE` still reads as an unknown tag.
+- **A line carrying no level is reported once.** The parser says a GEDCOM line must
+  begin with a level, and the validator no longer adds its own word about the tag of
+  a line that is not a line.
+
+- **A tag declared twice in `HEAD.SCHMA` with different URIs is no longer reported.**
+  The specification permits it — "the schema structure may contain the same tag more
+  than once with different URIs" — and its own `extensions.ged` declares `_PARTY`
+  twice, once for a substructure and once for a record. The check now asks whether
+  the same tag was declared twice with the _same_ URI, which says nothing the first
+  declaration did not. Which of several URIs applies where a tag is used is a
+  separate question.
+
+- **A line the lexer cannot read is reported once, in words about GEDCOM.** An xref
+  with a space in it — `0 @NoTe ref@ NOTE …` — produced "unexpected character:
+  ->@<- at offset: 199, skipped 1 characters", which is true of the scanner and no
+  use to a reader. The lexer then resumed one character on, so the wreckage lexed
+  into a tag `N` and a value, and the line was reported a second time as an unknown
+  tag that is nowhere in the file. Such a line now yields one diagnostic, saying an
+  xref holds letters, digits and underscore between two @ marks, and its tokens are
+  dropped rather than read as something else. The lines around it are untouched.
+- **An unknown tag at the top level says `root`** where it said `undefined`. The
+  message about a missing tag has said `root` all along.
+- **A file whose lines end in CR is read as a file, not as one line.** 5.5.1 ends a
+  line with CR, LF, CR-LF or LF-CR; the lexer's terminator was `\r?\n` and the line
+  index counted only LF, so a CR-only document parsed to a single node, its version
+  was never found, and everything above the lexer worked from one line. All four
+  terminators now end a line, a two-character form counts as one, and positions come
+  out the same whichever is used.
+
+- **A required tag missing from a childless parent is reported where it is
+  missing.** The position came from the parent of the first child, so a parent with
+  no children at all had no position to offer and the report landed on line 1. In a
+  105 707-line export that put ten `Missing required tag FORM in FILE` diagnostics
+  at the top of the document, a hundred thousand lines from the media references
+  they describe.
+- **Six closed value sets in 5.5.1 are checked at last.** `QUAY 9`, `PEDI nonsense`,
+  `RESN whatever`, `ORDI maybe`, `STAT nonsense` under `FAMC` and `ADOP nonsense`
+  under `INDI.ADOP.FAMC` all passed, because 5.5.1 states these sets in its
+  primitive definitions rather than in an enumeration vocabulary, and a payload
+  type the field-type switch did not name was validated as free text. Each now
+  names its set in the scheme and is judged by the rule that already existed for
+  GEDCOM 7 enumerations. Every real export in the corpus already wrote these
+  correctly, so nothing new is reported there. Completion offers the same values
+  while one is typed, because it reads the same sets: a `PEDI` line in a 5.5.1
+  file now proposes `adopted`, `birth`, `foster` and `sealing`.
+- **A BC year in a 5.5.1 file is read in the spellings exports write.** `1472 B.C.`
+  passed while `1472 BC`, `1472BC` and `1472B.C.` were reported, though `YEAR_GREG`
+  carries no epoch at all and the specification only says in prose that "(B.C.)"
+  appended to the year marks a date before the common era — pinning neither the
+  spelling nor the delimiter. Every spelling now reads as the same era, in the
+  validity check and in the leap-year rule alike, so `29 FEB 1000 BC` is no longer
+  judged by whether 1000 was a leap year. Free text stays reported: `609 BC Megiddo`
+  and `abt. 716 BC (or 725)` belong in `DATE_PHRASE` parentheses. GEDCOM 7 is
+  unchanged, where `epoch = %s"BCE"` says exactly what is allowed.
+- **An age in a 5.5.1 file is no longer judged by GEDCOM 7's grammar.** `AGE <8y`
+  was reported while `AGE < 8y` passed, and `8Y` and `child` were reported while
+  `8y` and `CHILD` passed. One expression served both versions, and it was
+  written to v7's ABNF, where the delimiter after `<` or `>` is required and
+  `years = Integer %x79` pins the unit letter. 5.5.1 prints neither rule, and
+  real exports write both forms, so 5.5.1 ages are now read without a required
+  delimiter and without regard to case. v7 keeps its ABNF exactly.
+
+## 1.8.1 - 2026-08-17
+
+- **A note written as text in a 5.5.1 file is no longer reported.** `1 NOTE plain
+text` was told to be a pointer to a `NOTE` record, though `NOTE_STRUCTURE` has
+  two forms and the text itself is the second. A note that ran to a `CONT` line
+  escaped, because the pointer rule stays silent for a structure with children,
+  so the report landed only on one-line notes — which every export from
+  MyHeritage, Ancestry and Gramps is full of. The schema still names the pointer
+  form, which is the one with a target to resolve and to complete.
+- **A source citation carrying its description is no longer reported either.**
+  `1 SOUR Parish register, Warsaw, vol 3 p 41` is the branch 5.5.1 provides for
+  systems that keep no source records, and `TEXT` written beneath it is no longer
+  an unknown tag. See [ADR 0010](../../docs/adr/0010-two-form-structures-in-5-5-1.md).
+
 ## 1.8.0 - 2026-08-14
 
 - **A header naming a system before `GEDC` is Personal Ancestral File, and is no