summaryrefslogtreecommitdiff
path: root/lib/citation/book.mli
diff options
context:
space:
mode:
authorLukasz Kasprzak <lukas@labunix.xyz>2026-08-26 13:30:02 +0200
committerLukasz Kasprzak <lukas@labunix.xyz>2026-08-26 13:30:02 +0200
commit9cc763c169a6ce4ebbdbed506c5eb2dad1f9f3c1 (patch)
treeb38d6e418c7de49766478a47f5654086157e66e0 /lib/citation/book.mli
parent1a3046e2a3793fe52ec518818b19a6f15aadbb75 (diff)
downloadcolitur-9cc763c169a6ce4ebbdbed506c5eb2dad1f9f3c1.tar.gz
colitur-9cc763c169a6ce4ebbdbed506c5eb2dad1f9f3c1.zip
fix(citation): recognise English-canonical OF books, verse sub-letters
35% of OF citation fields (259/730 on colitur readings --rite of 2026) printed unconverted -- 1 John renders on 2 January but not 3 January. Two independent causes, both in the citation/siglum path, neither in the OF data itself: 1. Book.table only ever surveyed the three EF citation-bearing files, so 345 references citing a book no EF file happens to use (Job, Ruth, Judges, 1/2 Samuel, 1/2 Chronicles, 1/2 Maccabees, Baruch, Ecclesiastes, Habakkuk, Haggai, Nahum, Zechariah, Zephaniah, Deuteronomy, Amos, Micah, Lamentations, Ezra, Joshua, 2/3 John, Jude, Philemon, plus "Isaiah"/"Jeremiah"/"Ezekiel"/"Malachi"/"Mat"/ "The Acts"/"Tobit"/"Song of Solomon" spelling variants of books EF already knows) failed as "unknown book". Added as a new, separate of_lectionary_table rather than folded into the EF-surveyed table: none of these 25 new books is attested in the EF's own scans, and lang/la.ini's own header refuses to fabricate an uncited Latin title, so they are resolvable (parse + render, falling back to their own English spelling) but deliberately excluded from Book.all -- test_lang_coverage.ml's la.ini-completeness promise is preserved exactly for the ids it already covered, not silently weakened. 2. Parse's grammar could not read a verse number carrying a lectionary sub-verse letter ("11a", "1bcde") at all -- the dominant remaining failure shape once (1) was fixed. verse_range now carries a verse_num { n; suffix } on each boundary, PRESERVED through rendering rather than dropped (dropping would silently lose real precision the source text carries). Chapter numbers are untouched (nothing in the data ever attaches a letter to one). A third, subtler bug surfaced by (1): registering "jude"/"philemon"/ "2 John"/"3 John" exposed Parse's existing "leading comma-number is a chapter" heuristic misreading a single-chapter book's bare verse list ("Jude 17,20b-25") as chapter 17 -- a wrong PARSE, worse than the previous safe "unknown book" failure. Book.is_single_chapter now tells Parse to skip that heuristic for the four one-chapter books and default to chapter 1. Residual, honestly enumerated rather than forced to zero: 41 distinct references (of 1540) are hyphenated ranges crossing a chapter boundary ("2:29-3:6") -- a Parse.t shape verse_range/part do not represent, a type restructuring deliberately not attempted this task. Pinned exactly by the new test_citation_coverage_of.ml, both directions (a new failure or one of these 41 starting to convert both go red), and disclosed in data/of/lectionary.sexp's own regenerated provenance header (tools/ bootstrap_lectionary_of.ml now runs the same parser at generation time and names the count and the set). Verified EF-unaffected: git diff v1.0.0..HEAD -- lib/kernel/ lib/rites/rite_ef/ data/ef/ is empty, and `colitur day`/`readings` output for 2027 is byte-identical against the pre-fix binary.
Diffstat (limited to 'lib/citation/book.mli')
-rw-r--r--lib/citation/book.mli20
1 files changed, 19 insertions, 1 deletions
diff --git a/lib/citation/book.mli b/lib/citation/book.mli
index 0ca229c..4e91c6c 100644
--- a/lib/citation/book.mli
+++ b/lib/citation/book.mli
@@ -30,7 +30,18 @@ val to_string : id -> string
tradition-only targets [sirach]/[revelation] -- see those below. *)
val of_token : string -> id option
-(** Every id this build knows, for coverage checks. *)
+(** Every id surveyed against the EF's own three citation-bearing files
+ (lectionary, sanctoral propers, commons) -- for coverage checks: every
+ SHIPPED language file's [\[bible\]] section is asserted complete over
+ this list (test_lang_coverage.ml). NOT every id {!of_token} can resolve:
+ book.ml's own [of_lectionary_table] adds a further ~25 ids the OF's
+ English-canonical lectionary cites that no EF file ever needed and that
+ no primary EF source attests a Latin title for -- resolvable ([of_token]/
+ {!default_spelling} both cover them) but deliberately excluded here,
+ rather than either fabricating an uncited Latin name or weakening this
+ list's own completeness promise for the ids that DO have one. Such a
+ book still renders, in its own English spelling ({!default_spelling}'s
+ own fallback), never a raw internal id. *)
val all : id list
(** Every accepted spelling paired with its id. *)
@@ -77,3 +88,10 @@ val tradition_of_fields : (string * string) list -> tradition
val unknown_fields : (string * string) list -> string list
val map : tradition -> id -> id
+
+(** Whether [id] names a book with exactly one chapter (Jude, Philemon,
+ 2 John, 3 John), conventionally cited by verse alone with no chapter
+ number ("Jude 17", not "Jude 1:17"). {!Colitur_citation.Parse.parse}
+ consults this to avoid misreading a leading verse number as a chapter
+ -- see book.ml's own citation for the real citation this was found on. *)
+val is_single_chapter : id -> bool