pubid 2.0.20 → 2.0.22

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 5bf271d5120b52861eb84e3c8cf375c0bdcebf61ecf3c5666af4a888590ccbc7
-  data.tar.gz: 2516fdc850d72aab4de4a589a9187d840d685cc2bc101f1a501e088a43d6287e
+  metadata.gz: 48dbbe488a6339c779e17067ea3ff034db07d1c2ae636d802cc43d4f96a3506e
+  data.tar.gz: 2b557f9660b432e698af587c79c8c8a40f4dd66dcf52475f3b5d6cc1b16ef08a
 SHA512:
-  metadata.gz: 7127733e72ab23c53b55b62bc17258bd936055fef0a3840d61ef81d66dc98d193a9e30cedab3d1178e50b51a26021a8b13c91141b1a9c49e4c5b67448b346987
-  data.tar.gz: b19d01682a51d7b7864643b093e3379fe273fa34370c1f151809e0f84d82f965501dd14a6e95d0956ee9f2206d9e9757eb24c89eec166c8fa7395ed2c7bd6bd6
+  metadata.gz: f2f9c0e44fd4c976a403586366360ea6d4df2f2e3f51a3a584f06e676545b38cbac9e796e5caf611f67218706c3c54f20bf43fdb0e23c953253a580a96209d98
+  data.tar.gz: d98b1a76dd898d51afca3e70972949d9a5fd741deef5e69d73c2200dbff1eb69fd645f6b3806052dd390a362cd87a6497cf8f07de591e6f7592eedc2aa2867f6

data/README.adoc

@@ -7,10 +7,13 @@ image:https://img.shields.io/github/commits-since/metanorma/pubid/latest.svg["Co
 
 == Quick Start
 
-[source,ruby]
+[source,shell]
 ----
 gem install pubid
+----
 
+[source,ruby]
+----
 require 'pubid/iso'
 
 # Parse an identifier
@@ -18,13 +21,13 @@ id = Pubid::Iso.parse("ISO 9001:2015/Amd 1:2020")
 
 # Access components
 id.publisher.body  # => "ISO"
-id.number.number   # => "9001"
+id.root.number     # => "9001"
 
 # Render back to string (round-trip)
 id.to_s  # => "ISO 9001:2015/Amd 1:2020"
 
 # Generate URN
-id.to_urn  # => "urn:iso:std:iso:9001:amd:2020:v1"
+id.to_urn  # => "urn:iso:std:iso:9001:amd:1:2020:v1"
 ----
 
 == Overview
@@ -78,12 +81,15 @@ README.
 |link:docs/flavor-guides/iec.md[IEC: TRF format grammars]
 |IECEE and IECEx Test Report Form patterns — the `&` part join, the
 `F_II`-style sub-versions, the `_EMC`/`_PS`/`_SOF` test-type suffixes, and the
-IECEx `_`/`v` separator. Ported from the archived pubid-iec README.
+IECEx `_`/`v` separator — plus the general IEC forms (supplement faces,
+CSV/CMV/RLV wrappers, standalone supplements). Ported from the archived
+pubid-iec README.
 
 |link:docs/flavor-guides/plateau.md[PLATEAU: the Handbook #11 edition split]
 |Why an edition-1–3 "Handbook #11" reference with a part suffix parses as
-Handbook #06 / #04 (the rule encoded in `data/plateau/update_codes.yaml`).
-Ported from the archived pubid-plateau README.
+Handbook #06 / #04 (the rule encoded in `data/plateau/update_codes.yaml`),
+and the Handbook volume label (本編 / 本編＋付録). Ported from the
+archived pubid-plateau README.
 
 |link:docs/RENDERING_GUIDE.md[Advanced Rendering Styles Guide]
 |ISO short/long supplement abbreviation preservation and IEC `AMD1` vs
@@ -192,23 +198,22 @@ PubID V2 implements RFC 5141-bis compliant URN generation for ISO and IEC identi
 
 [source,ruby]
 ----
-require 'pubid/iso'
-require 'pubid/iec'
+require 'pubid'
 
 # ISO: Parse and generate URN
 id = Pubid::Iso.parse("ISO/IEC 13818-1:2015/Amd 3:2016")
 id.to_urn
-# => "urn:iso:std:iso-iec:13818:-1:amd:2016:v3"
+# => "urn:iso:std:iso-iec:13818:-1:amd:3:2016:v1"
 
 # IEC: Parse and generate URN
 id = Pubid::Iec.parse("IEC 60068-2-2:1974/Amd 1:1993")
 id.to_urn
-# => "urn:iec:std:iec:60068-2-2:1974:amd:1993:v1"
+# => "urn:iec:std:iec:60068-2-2:1974:::::amd:1:1993"
 
 # Round-trip: parse URN back to identifier
-id = Pubid::Iso.parse_urn("urn:iso:std:iso:9001:amd:2020:v1")
-id.to_s  # => "ISO 9001/Amd 1:2020"
-id.to_urn  # => "urn:iso:std:iso:9001:amd:2020:v1"
+id = Pubid::Iso.parse_urn("urn:iso:std:iso:9001:amd:1:2020:v1")
+id.to_s  # => "ISO 9001/AMD 1:2020"
+id.to_urn  # => "urn:iso:std:iso:9001:amd:1:2020:v1"
 ----
 
 === Features
@@ -228,9 +233,9 @@ id.to_urn  # => "urn:iso:std:iso:9001:amd:2020:v1"
 `#to_urn` follows the registered grammar of the organization, which can
 drop values (RFC 5141 has no year). `#to_pubid_urn` is pubid's own URN: it
 carries every value, always round-trips through `Pubid.parse_urn`, and is
-safe to use as an HTTP path. ISO, IEEE, ANSI, ITU, NIST, ASTM, API, ASHRAE,
-ASME, JCGM, OIML, ETSI, GOST and PLATEAU support it now; the other flavors follow
-(link:docs/URN-SCHEMES.adoc[URN schemes]).
+safe to use as an HTTP path. Every flavor supports it (the per-flavor
+schemas live in `lib/pubid/<flavor>/pubid_urn_schema.rb`;
+link:docs/URN-SCHEMES.adoc[URN schemes] documents each).
 
 [source,ruby]
 ----
@@ -410,6 +415,9 @@ Pubid::Ecma.parse("ECMA-418") === Pubid::Ecma.parse("ECMA-418-1")
 # => false (ECMA-418 has no part)
 Pubid::Ecma.parse("ECMA-418-1") === Pubid::Ecma.parse("ECMA-418-1 ed1")
 # => true
+Pubid::Ecma.parse("ECMA-262 Edition 5.1") === Pubid::Ecma.parse("ECMA-262 ed5.1")
+# => true (the human edition faces — "Edition 5.1", "ed 5.1", a bare
+# trailing edition — parse in as aliases of the canonical " ed<N>" face)
 ----
 
 A reference asks for every part of a document with `all_parts`:
@@ -480,15 +488,18 @@ backend, without parsing.
 ----
 require 'pubid'
 
+Pubid.eager_load_flavors!  # flavor modules register lazily; load them all
+
 Pubid::Iso.prefixes
-# => ["ISO", "ISO/IEC", "IEC/ISO", "ISO/IEC/IEEE"]
+# => ["ISO", "ISO/IEC", "IEC/ISO", "ISO/IEC/IEEE", "ISO/IEEE"]
 
 Pubid::Bsi.prefixes
-# => ["BS", "BSI", "DD", "PD", "PAS", "NA", "TS", "HB", ... , "BS EN ISO"]
+# => ["BS", "BSI", "DD", "PD", "PAS", "NA", "TS", "HB", "PP", "BIP", "EP",
+#     "BS EN", "BS ISO", "BS IEC", "BS EN ISO", "BS EN IEC"]
 
 # Look up a single flavor by name
 Pubid.prefixes(:iec)
-# => ["IEC", "CISPR", "IECEE", "IECEx", "IECQ", "ISO/IEC", "IEC/ISO", "ISO/IEC/IEEE"]
+# => ["IEC", "CISPR", "IECEE", "IECEx", "IECQ", "ISO/IEC", "IEC/ISO", "ISO/IEC/IEEE", "IEC/IEEE"]
 
 # Reverse index: prefix token => owning flavor(s)
 Pubid.prefix_flavors["ISO/IEC"]       # => [:iec, :iso]
@@ -1012,7 +1023,7 @@ require 'pubid'
 id = Pubid::Nist.parse("NIST SP 800-53r5")
 
 # Access components
-id.series    # => "SP"
+id.series.to_s # => "SP"
 id.number    # => "800-53"
 id.revision  # => "r5"
 
@@ -1021,7 +1032,7 @@ id.to_s      # => "NIST SP 800-53r5"
 
 # Parse historical NBS patterns
 id = Pubid::Nist.parse("NBS LCIRC 1019r1963")
-id.to_s      # => "NBS LCIRC 1019r1963"
+id.to_s      # => "NBS LC 1019r1963"
 
 # CSM volume-number format
 id = Pubid::Nist.parse("NBS CSM v6n1")
@@ -1029,7 +1040,22 @@ id.to_s      # => "NBS CSM v6n1"
 
 # Supplement with revision
 id = Pubid::Nist.parse("NBS CIRC 154supprev")
-id.to_s      # => "NBS CIRC 154supprev"
+id.to_s      # => "NBS CIRC 154sup"
+
+# FIPS PUB printed form: the official FIPS face is "FIPS PUB <number>"
+# ("PUB" is part of the Federal Information Processing Standards
+# PUBlication designation); every printed spelling parses to the same
+# identity (same hash, URN and MR string as the canonical parse)
+id = Pubid::Nist.parse("FIPS PUB 205")
+id.to_s      # => "FIPS PUB 205"
+id = Pubid::Nist.parse("NIST FIPS PUB 205")
+id.to_s      # => "FIPS PUB 205"
+
+# Hyphenated numbers and the revision forms ride the alias too
+id = Pubid::Nist.parse("FIPS PUB 180-4")
+id.to_s      # => "FIPS PUB 180-4"
+id = Pubid::Nist.parse("FIPS PUB 140-3 rev1")
+id.to_s      # => "FIPS PUB 140-3r1"
 ----
 
 **Language:**
@@ -1039,20 +1065,34 @@ id.to_s      # => "NBS CIRC 154supprev"
 
 ==== IEC
 
-The IEC parser handles complex patterns including adopted standards and dual-published identifiers:
+The IEC parser handles the supplement faces, the value-added wrappers, the
+project-committee working documents, and the standalone supplements:
 
 [source,ruby]
 ----
 require 'pubid'
 
-# Parse standard IEC identifier
-id = Pubid::Iec.parse("IEC 62014-5 IEEE Std 1734-2011")
-id.class  # => Pubid::Iec::Identifiers::DualPublished
-id.to_s   # => "IEC 62014-5 and IEEE Std 1734-2011"  # normalized
+# Supplements render the compact official face (AMD1 vs the long "Amd 1")
+id = Pubid::Iec.parse("IEC 60050-351:2013/AMD1:2016")
+id.to_s   # => "IEC 60050-351:2013/AMD1:2016"
+
+# Value-added editions are VapIdentifier wrappers (+AMD… CSV)
+id = Pubid::Iec.parse("IEC 60950-1:2005+AMD1:2009+AMD2:2013 CSV")
+id.class  # => Pubid::Iec::Identifiers::VapIdentifier
+id.to_s   # => "IEC 60950-1:2005+AMD1:2009+AMD2:2013 CSV"
 
-# Space-separated dual identifiers are auto-detected
-id = Pubid::Iec.parse("ANSI C37.61-1973 and IEEE Std 321-1973")
-id.to_s   # => "ANSI C37.61-1973 and IEEE Std 321-1973"
+# Working documents
+id = Pubid::Iec.parse("1/2457/FDIS")
+id.class  # => Pubid::Iec::Identifiers::WorkingDocument
+id.to_s   # => "1/2457/FDIS"
+
+# A standalone supplement (a supplement face without its base) parses on
+# its own, is == its from_hash(to_hash) round trip, and its root is the
+# bare base number
+id = Pubid::Iec.parse("IEC/FDAM 60038-1")
+id.to_s   # => "IEC FDAM 60038-1"
+Pubid.from_hash(id.to_hash) == id  # => true
+id.root.to_s  # => "IEC60038"
 ----
 
 ===== Pattern 4: Relationship Identifiers ✨
@@ -2206,12 +2246,14 @@ require 'pubid/nist'
 id = Pubid::Nist.parse("NIST SP 800-53r5")
 
 # Access components
-id.series    # => "SP"
+id.series.to_s # => "SP"
 id.number    # => "800-53"
 id.revision  # => "r5"
 
 # Render to string
 id.to_s      # => "NIST SP 800-53r5"
+----
+
 ==== OIML
 
 OIML supports 9 identifier types with edition and supplement support:

data/data/iec/legacy-notation.md

@@ -0,0 +1,298 @@
+# IEC legacy notation — old faces, modern counterparts, and the DAM family
+
+**Status: RULED and LANDED (owner ruling 2026-11-12, "Yes, do this now").**
+Sections 1–6 are the research record the ruling was made on; section 7
+records the disposition as implemented. Companion to
+`data/iec/stage-codes.md` (same precedent: provenance, sources, tables,
+reconciliation with the pubid registry).
+
+The owner's refined ruling holds that the base-less publisher-slash input
+`IEC/FDAM 60038-1` is not garbage to reject: it is the **old face** of
+`IEC 60038-1/FDAM 1`, the way old ISO printed parts with a slash and years
+with a dash before the modern `-part` / `:year` convention settled. This
+document collects the evidence for that mapping, the exact behaviour of the
+current model, the gaps, and the disposition options.
+
+## Sources (all local; the IEC site is WAF-gated and yields no identifier-format examples)
+
+| Source | What it evidences | Freshest state used |
+|---|---|---|
+| `pubid-iec` **1.15.21** installed gem (the v1 reference implementation; parslet grammar `lib/pubid/iec/parser.rb`) | the historical grammar's treatment of every face probed below | probed live 2026-11-12 |
+| `relaton-data-iec` (33k records; local clone, main @ `04a8dc449` "update documents") | the real stored docidentifiers and the serialized shapes the consumer reads | 2026-11-12 |
+| `relaton-data-iso` (local clone) | the modern stored docidentifiers of the joint (ISO/IEC) documents behind the owner-cited forms | 2026-11-12 |
+| pubid `main` @ `be6a43c2` (2.0.21) — `grammars/iec.parg` edition-2 artifact, builder, `SupplementIdentifier#ensure_base` | the current decode of every face probed below | probed live 2026-11-12 |
+| `spec/fixtures/iec/**` (full 12,534 inputs, pass/ and fail/ mined raw) | what the corpus pins | 2026-11-12 |
+| `IEC-ISO Harmonized APIs` v0.0.8 (2023-06) / v0.0.7 (2021-05) PDFs | stage codes only (see `stage-codes.md`); **no identifier-format examples** | 2026-10-22 extract |
+
+Historical background (not locally citable — needs the owner's citation if
+this doc ships): IEC moved onto the 60000–69999 namespace in 1997 under the
+ISO/IEC agreement; old `IEC 68` became `IEC 60068` (number += 60000, parts
+unchanged).
+
+## 1. Old IEC numbering (the 60000-namespace move)
+
+- **Fixtures:** `spec/fixtures/iec/**` carries **zero** old-number inputs
+  (`IEC 68`, `IEC 65`, `IEC 68-1` … appear nowhere in full/, pass/ or fail/).
+  The only sub-1000 numbers in the fixtures are joint ISO/IEC documents
+  (`ISO/IEC 9594-*`, `ISO/IEC 9075-*`, `ISO/IEC 9899`, `ISO/IEC 8825-*`),
+  which are ISO-side numbers and were never IEC-old numbers.
+- **v1 gem:** old numbers parse and render round-trip: `IEC 68:1980` →
+  `IEC 68:1980`, `IEC 68-1:1988` → number `68`, part `1`.
+- **pubid 2 (current):** identical — `IEC 68:1980` → number `68`,
+  `IEC 68-1:1988` → number `68` part `1`. Old numbers still parse; there is
+  no 60000-offset inference anywhere in either implementation.
+- **relaton-data-iec:** the crawler stores the **modern** number even for
+  pre-1997 editions — `data/iec-60068-1-1960.yaml` is stored as
+  `IEC 60068-1:1960` (1960 edition, modern number). Exactly one short-number
+  file exists (`iec-112-2021.yaml`, a genuinely modern number). **No record
+  carries an old number; the old→new mapping is never encoded in the corpus** —
+  the crawler resolved designations to the modern namespace at crawl time.
+- Parts: old `IEC 68-1` style == modern `IEC 60068-1` style; the part
+  separator was already `-` on both sides of 1997. No `IEC 68/1` slash-part
+  face exists in any local source.
+
+## 2. The old supplement faces and the DAM family
+
+### 2.1 The JTC1/ISO-style prefix face (the DAM family)
+
+The letters **DAM / PDAM / FDAM / FPDAM** (Draft / Proposed Draft / Final
+Draft / Final Proposed Draft Amendment) are JTC1 ballot faces: the type
+token (with its amendment number) is printed **before** the base
+designation.
+
+Owner's rule under verification: **DAM/PDAM/FDAM/FPDAM without a number
+means Amendment 1.**
+
+Evidence:
+
+- **relaton-data-iec, exhaustive scan:** across all 32,835 records the
+  letters PDAM/FPDAM/FDAM appear in **exactly one file**
+  (`iso-iec-21000-14-2007.yaml`) — a **joint** record, and only inside an
+  abstract that cites sibling drafts (`ISO/IEC 21000-4:2006/FPDAM 1`,
+  `ISO/IEC 21000-5:2004/FDAM 2`) — never in a docidentifier. Word-bounded
+  bare `DAM`: **zero occurrences**. **IEC-only records never use the DAM
+  letters.** The DAM family is JTC1/ISO ballot vocabulary that rides only on
+  joint (and pure-ISO) work; IEC's own catalogue never printed it.
+- **"No number means Amendment 1":** consistent with the joint corpus —
+  `ISO/IEC PDAM 12207` names the ballot that became
+  `ISO/IEC 12207:1995/Amd 1:2002` (the first amendment; stored docidentifier
+  in relaton-data-iso). Every one of the 7,366 published supplement records
+  in relaton-data-iec (4,923 AMD + 2,306 COR + 137 ISH) carries its **own
+  number** (`number: '1'` …), so the published corpus never contradicts the
+  rule; the numberless face exists only at ballot time.
+- **v1 gem:** the prefix face was never decoded — `IEC/FDAM 1 60038-1:2004`
+  raised, and the joint forms "parsed" only by the catch-all number rule
+  swallowing the tokens whole (`ISO/IEC FDAM 1 14496-12:2004` → number
+  `"FDAM 1 14496-12"`, type `:is`) — a mangle, not a decode.
+- **pubid 2 (current):** the prefix face raises in both the iec and iso
+  flavors (see the coverage table).
+
+### 2.2 IEC's own historical amendment faces
+
+The stored docidentifiers of real IEC amendments are uniformly the modern
+on-base slash form, with the base designation whole and the supplement
+numbered: `IEC 60038:1983/AMD1:1994`, `IEC 60038:2009/AMD1:2021`,
+`CISPR 1:1961/AMD1:1967`, chained `ISO/IEC 9075-1:1999/Amd 1:2001/Cor 1:2003`
+(relaton-data-iso), consolidated `+AMD1:1994+AMD2:1997` (file
+`iec-60038-1983+amd1-1994+amd2-1997-csv.yaml`), titles "Amendment 1".
+**No IEC-only record carries a numberless supplement** (checked across all
+7,366 supplement rows).
+
+### 2.3 The publisher-slash face `IEC/FDAM 60038-1`
+
+- **v1 gem (1.15.21):** the face **did not parse at all** —
+  `IEC/FDAM 60038-1`, `IEC/DCOR 60038-1`, `IEC/DISH 60038-1`,
+  `IEC/CD 60038`, `IEC/FDIS 60038` all raised `ParseError`. v1's
+  `std_document_body` accepted `( "/" | space ) >> type` for **types**
+  (TS/TR/PAS/GUIDE: `IEC/TS 80000-1` parsed, `IEC CD 60038` parsed), but
+  FDAM/DCOR/DISH/CD are **stage** abbreviations, not types, so the slash
+  forms never reached a rule. The space-stage forms were mangled in v1
+  (`IEC FDAM 60038-1` → number `"FDAM 60038-1"`, type `:is`;
+  `IEC DISH 60038-1` → `/DISH60038`).
+- **pubid 2 (current):** the `standalone_supplement` grammar rule accepts
+  `publisher / TYPE number` for **any** table token and `#ensure_base`
+  resolves it. See §3 for the resolution — which is the load-bearing finding.
+- **relaton-data-iec:** **zero** docidentifiers of this shape (the pattern
+  `IEC/FDAM`-family or any `ORG/STAGE number` face: 0 of 32,835). The face
+  exists in no real record.
+
+### 2.4 The old dotted on-base spelling `/Amd.1`
+
+`IEC 60068-1:1988/Amd.1:1992` raises in **both** v1 and pubid 2. The dotted
+spelling (real on ISO covers, and inside IEC abstracts citing joint work,
+e.g. `ISO/IEC 21000-5:2004/Amd.1:2007`) was never accepted by the IEC
+flavor. ISO flavor accepts it; IEC does not. Recorded as a gap, not chased
+here.
+
+## 3. How the current model resolves the old face (the load-bearing answer)
+
+Probed on `main` @ `be6a43c2` (2.0.21):
+
+| Input | base in to_hash | supplement own fields | to_s |
+|---|---|---|---|
+| `IEC/FDAM 60038-1` | `{"number" => "60038"}` | `{"stage"=>"fdamd", "number"=>"1"}` | `IEC FDAM 60038-1` |
+| `IEC FDAM 60038-1` | `{"number" => "60038"}` | `{"stage"=>"fdamd", "number"=>"1"}` | `IEC FDAM 60038-1` |
+| `IEC 60038-1/FDAM 1` (modern) | `{"number" => "60038", "part" => "1"}` | `{"stage"=>"fdamd", "number"=>"1"}` | `IEC 60038-1/FDAM1` |
+| `IEC 60038-1/FDAM1:2021` | `{"number" => "60038", "part" => "1"}` | `stage fdamd, number 1, year 2021` | `IEC 60038-1/FDAM1:2021` |
+| `IEC 60038:2009/AMD1:2014` | `{"number" => "60038", "year" => "2009"}` | `number 1, year 2014` | unchanged |
+
+**The current model resolves the old form to "base 60038 with FDAM number
+1": the bound hash captures `supp_number_with_part = "60038-1"`, the
+builder splits it into number `60038` + part `1` on the supplement, and
+`SupplementIdentifier#ensure_base` moves `@number` onto the synthetic base
+while `@part` becomes the supplement's own number.** The base loses its
+part; the "1" migrates into the supplement slot.
+
+**Under the owner's reading this is wrong.** The old face names **FDAM of
+60038-1**: the whole `60038-1` is the base designation, the type token is
+unnumbered (→ Amendment 1 per the DAM rule), and the modern counterpart is
+`IEC 60038-1/FDAM 1` — where the printed "1" after FDAM is the supplement
+number the old face left implicit. The two faces must decode to the same
+identifier, and today they do not (the space form of the old face and the
+modern on-base form disagree on where the `1` lives — `{"number" => "60038"}`
+vs `{"number" => "60038", "part" => "1"}`).
+
+Note this correction touches the **space form too** (`IEC FDAM 60038-1`
+would re-resolve to base 60038-1), and with it the #693-era equality work
+and the six fixtures in `full/iec-pubid.txt` (rows 2195–2200) plus the
+three normalization pairs the testsuite mirror carries (`FDAM/DCOR/DISH
+60038-1`). The render would move from `IEC FDAM 60038-1` to the modern
+on-base face (`IEC 60038-1/FDAM…` spelling per the ruling) or keep the old
+render as a facet — an owner call (see §5).
+
+## 4. Coverage table — the owner-cited forms (I own the ISO/IEC joint rows)
+
+"Decode" = parses today under the current grammar, either flavor
+(`Pubid::Iec.parse` / `Pubid::Iso.parse`; `ISO/IEC` routes to both via
+`JOINT_PREFIXES`). Modern target = the stored docidentifier of the same
+document in the joint corpus, where one exists.
+
+| Input (historic face) | Decode today? | Historic identity (owner scheme) | Modern counterpart (evidence) |
+|---|---|---|---|
+| `ISO/IEC FDAM 1 14496-12:2004` | **no** (raises, both flavors) | FDAM **1** of base `14496-12:2004` | `ISO/IEC 14496-12:2005/Amd 1:2007` (corpus; the ballot predates the final edition year) |
+| `ISO/IEC FDAM 19776-2:2005/Am1:2006` | **no** | FDAM (unnumbered → **1**) of base `19776-2:2005`, amendment already stamped `/Am1` on the base | `ISO/IEC 19776-2:2005/Amd 1:2008` (corpus) |
+| `ISO/IEC FPDAM 10373-6/Amd 9:2001` | **no** | FPDAM (unnumbered → **9**, stated on-base) of base `10373-6` | `ISO/IEC 10373-6:2001/Amd N` family (corpus stores amd-1…7 of the 2001 edition) |
+| `ISO/IEC FPDAM 9075/1` | **no** | FPDAM (unnumbered → **1**) of base `9075/1` — old slash-part spelling → base `9075-1` | `ISO/IEC 9075-1:1999/Amd 1:2001` (corpus) |
+| `ISO/IEC 19772:2009/DAM 1:2019(E)` | **yes** (both flavors; on-base DAM) | DAM **1** of base `19772:2009` | none — the amendment died in ballot (corpus has only `Cor 1:2014`, then the 2020 edition) |
+| `ISO/IEC PDAM 2 10646:2012` | **no** | PDAM **2** of base `10646:2012` | `ISO/IEC 10646:2012/Amd 1:2013` (corpus; Amd 2 followed) |
+| `ISO/IEC PDAM TR 9573-11/Amd.1` | **no** | PDAM (unnumbered → **1**) of base `TR 9573-11`, amendment stamped on-base | TR amendment family (corpus: `iso-iec-tr-9573-11-*`) |
+| `ISO/IEC PDAM 9541-1/Amd.4` | **no** | PDAM (unnumbered → **4**, stated on-base) of base `9541-1` | `ISO/IEC 9541-1:1991/Amd 4:2009` (corpus) |
+| `ISO/IEC PDAM 12207` | **no** | PDAM (unnumbered → **1**) of base `12207` | `ISO/IEC 12207:1995/Amd 1:2002` (corpus) |
+
+Pure-ISO rows of the owner's list (`ISO/FDAM 19119:2005/Amd.1`,
+`ISO/PDAM 19110:2005/Amd.1`, `ISO 15877-5:2009 FDAM 1`, `ISO/PDAM 19973-2`)
+belong to the ISO-side study; the DAM-letter evidence in §2.1 covers them
+symmetrically (zero IEC-only usage).
+
+Cross-cutting: the **on-base** DAM form already decodes (`19772` row) via
+the same grammar branch as `/AMD1` — only the **prefix** (type-before-base)
+faces and the old slash-part spelling are gaps.
+
+## 5. Gap list (current grammar/model vs the historic scheme)
+
+1. **Prefix supplement faces raise**: `[P|F]?DAM [N] BASE` — no rule in
+   `grammars/iec.parg` (joint or IEC-only; both flavors raise). Historic
+   face per the owner's scheme; zero published corpus occurrences
+   (ballot-time only), so the blast radius is inputs typed by humans, not
+   stored records.
+2. **The old publisher-slash face mis-resolves**: `IEC/FDAM 60038-1` /
+   `IEC FDAM 60038-1` put the base's part into the supplement's number
+   (§3). The modern and old faces disagree on the same document's identity.
+3. **Old slash-part spelling** (`9075/1`): never handled by either
+   implementation; the owner's ISO analogy places it in the same
+   historic-notation family.
+4. **Dotted on-base `/Amd.1`**: raises in the IEC flavor (both
+   implementations); ISO accepts it. Abstracts of joint records cite the
+   dotted spelling.
+5. **No old-number ↔ 60000-mapping knowledge** in either implementation:
+   old numbers parse as opaque numbers (`IEC 68` stays `68`); the corpus
+   never needs the mapping (crawler resolved at crawl time).
+
+## 6. Disposition options (two house precedents) and recommendation
+
+**Option A — ISO `original_abbr` spelling-facet style** (root CLAUDE.md,
+"Spelling is not identity"): parse the historic face, store the modern
+identity, keep the input's spelling as an `equality_ignored` facet so
+`to_s` can reproduce it. Fits when both spellings live in the wild and
+round-tripping the input spelling matters. Cost: a facet on
+`TypedStage`/supplement components plus render plumbing in both flavors.
+
+**Option B — IHO legacy-decode-to-modern style** (the IHO edition ruling):
+decode the legacy face straight to the modern canonical identity, no
+spelling kept. Fits when the legacy face is a ballot/era artefact that the
+modern catalogue never stores. Cost: grammar decode + the identity
+correction of §3; render emits the modern face.
+
+**Option C — drop**: keep raising on the prefix faces and leave the
+publisher-slash face as #693 left it. Contradicts the refined ruling.
+
+**Recommendation: B, with one owner call.** The DAM-family faces and the
+old slash-part spelling are ballot-era artefacts with **zero** published
+corpus occurrences (measured above), so a spelling facet (A) buys nothing
+for matching; decode-to-modern gives one identity per document. The decode
+rule: `[P|F]?DAM [N] BASE` → supplement (P|F)DAM, number `N` defaulting to
+**1** (the owner's rule), base designation kept **whole** (parts and
+slash-parts resolved per the modern separator convention). The owner call:
+whether the already-accepted faces (`IEC/FDAM 60038-1`, the on-base
+`/AMD1`, the dotted `/Amd.1`) also move to the corrected base-whole
+resolution — §3 shows the space form shares the defect, so the correction
+cannot be scoped to the slash form alone. This doc records the evidence
+for that decision; no implementation is proposed until the owner rules.
+
+## 7. Disposition as implemented (the owner's ruling)
+
+**Option B — IHO-style decode-to-modern — on ALL the already-accepted
+faces too** (the §6 owner call): `IEC/FDAM 60038-1` and `IEC FDAM 60038-1`
+both decode to the modern identity; the space form shares the defect, so
+the correction is not scoped to the slash form alone.
+
+The decode rule, as landed:
+
+- **Base kept whole.** The designation after the stage token is the BASE's:
+  number, part, subpart and the date (old notation prints the base's year;
+  a draft supplement carries no publication date of its own). The base is a
+  concrete InternationalStandard, so the legacy face hash-matches — and
+  equals — the modern on-base parse: `parse("IEC/DCOR 60038-1") ==
+  parse("IEC 60038-1/DCOR 1")`.
+- **Unnumbered = 1.** The supplement's number is the captured N, defaulting
+  to 1 (the DAM-family no-number rule, extended to the DCOR/DISH faces the
+  fixtures carry).
+- **Draft-ness preserved.** Each face keeps its own stage: FDAM → `fdamd`
+  (50.xx), DAM → `damd` (40.xx), DCOR → `dcor`, DISH → `dish`, CDISH →
+  `cd`, FDCOR → `fdcor`; the joint ladder's PDAM (30.xx, CD level) and
+  FPDAM (50.xx, FDIS level) registered with the circulation slots 30.20 /
+  50.20 leading their harmonized lists (CDAM and FDAM own the
+  (type, leading-code) URN keys 30.00 / 50.00).
+- **Slash-part.** `FPDAM 9075/1` — the `/1` is the base's part (base
+  9075 part 1), consistent with the ISO-side reading of the old
+  slash-part spelling.
+- **Modern canonical face emitted.** `IEC/FDAM 60038-1` → `IEC 60038-1/FDAM1`;
+  the legacy face is decoded, not preserved as a spelling facet.
+- **Stays untouched:** the modern on-base forms — `IEC 60038:1983/AMD1:1994`,
+  `IEC 60038-1/FDAM 1`, `ISO/IEC 19772:2009/DAM 1:2019(E)` — and the true
+  standalone self-base (`IEC/AMD 1:2017` → `IEC Amd 1-1:2017`).
+
+Split of labour: the DAM-family prefix faces needed a new grammar rule
+(`legacy_supplement`, pubid-grammar) — they raised before; the DCOR/DISH
+(and CDISH/FDCOR/CDCor) faces already parsed through the standalone and
+typed branches and were corrected in the builder
+(`SupplementIdentifier#ensure_base`: the part-to-number move deleted, the
+designation moved whole onto a concrete base, the supplement numbered 1).
+A bare number after a DAM-family token is a base designation under the
+JTC1 reading (`IEC FDAM 60038` → `IEC 60038/FDAM1`); a bare ordinal after
+a non-DAM token stays the supplement's own number.
+
+Replay gate (all 26,838 full-fixture inputs, main baseline vs the branch):
+byte-identical everywhere except the six §3 rows (rows 2195–2200 of
+`full/iec-pubid.txt`), which re-resolve; 0 inputs stopped parsing; the
+prefix faces go raise→parse (pass 12,337 → 12,359 of 12,491; fail steady
+at 132). The testsuite mirror normalization pairs
+(FDAM/DCOR/DISH `60038-1`) flip to the corrected identities in the same
+round.
+
+Still raising, deliberately (gap 4 of §5, not chased here): the dotted
+on-base `/Amd.1` spelling, and the stamped prefix faces whose base
+designation carries an amendment stamp (`FPDAM 10373-6/Amd 9:2001`,
+`PDAM 9541-1/Amd.4`, `FDAM 19776-2:2005/Am1:2006`, `PDAM TR
+9573-11/Amd.1`) — they need the dotted/ISO stamp spellings the IEC flavor
+does not carry; the ISO-side study owns that family.

data/data/iho/s4-reserved-specs.yaml

@@ -0,0 +1,15 @@
+# IHO S-4 reserved specification numbers ("NOT CURRENTLY USED" in the
+# publication's contents), keyed by the S-4 edition whose contents list
+# them, then by the citation's Part letter. A reserved number parses and
+# resolves AS RESERVED, never invalid (issue #691): the identifier is
+# well-formed, the number just names no specification in that edition.
+#
+# Provenance:
+# - Ed 4.10.0: the owner's list in pubid/pubid#691.
+# - Ed 4.9.0 (March 2021): verified against the publication's Part B
+#   contents (reference-docs/iho/S-4_Ed4.9.0_March_2021.pdf) — the same
+#   four numbers print "NOT CURRENTLY USED".
+"4.10.0":
+  B: ["170", "230", "305", "323"]
+"4.9.0":
+  B: ["170", "230", "305", "323"]