Lutaml integration - #123
Open
andrew2net wants to merge 24 commits into
Open
andrew2net wants to merge 24 commits into
andrew2net wants to merge 24 commits into
Conversation
…for 2.1.0 release
* Preserve XML-fragment markup in Bibcollection title/author Port of fd20c9d (#125) to the v2/lutaml-integration branch. Switch Bibcollection.from_xml to read the collection title and author via inner_html instead of Nokogiri's .text, so the in-memory strings keep their XML-fragment form (markup + entities intact). Apply the strip_html Liquid filter on the HTML <title> tag position so the browser tab title stays plain text. Adds find_html to ElementFinder alongside find_text. Adds a regression spec with markup and & in both the collection title and the author name. Refs metanorma/isodoc#785.
Port the write-path fix from #128 to v2/lutaml-integration. The read-path half of #128 (find_html + strip_html) was already ported via #127; this commit ports the remaining to_xml escaping. bibcollection.rb to_xml was writing the collection title and author directly into XML without escaping, producing bare & in the output when the values came from YAML (e.g. name: "A test & playground ..."). A bare & is invalid XML; libxml2 in recovery mode emits FATAL "xmlParseEntityRef: no name" and then silently drops all subsequent & entities in the same document — corrupting every individual document title's & in the collection index HTML output. Add a private xml_escape helper that escapes only unencoded & (not already-encoded &, &#nnn;, &#xhh;) and leaves inline markup tags (<em>, <strong>, etc.) untouched, so valid HTML fragments round-tripped via find_html pass through unchanged. Fixes metanorma/isodoc#785: metanorma/isodoc#785 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The gemspec referenced the pre-move location (github.com/metanorma/relaton-cli).
The tight ~> 2.1.0 pin prevents the relaton v3 monogem (3.0.0.pre.alpha.x) from resolving anywhere relaton-cli appears in the graph, blocking the relaton-v3 / pubid-v2 stack migration. Widen the range; CI keeps testing the usual v2 resolution via the lockfile until the v3 port lands.
relaton v3 moved the top-level Relaton::Registry to Relaton::Db::Registry (the Db singleton registry with the same processors/by_type/ find_processor_by_dataset surface). Every CLI call site now goes through Relaton::Cli.registry, which resolves the v3 constant first and falls back to the v2 constant, so the CLI works with both released v2 and the v3 monogem (site generation crashed with 'uninitialized constant Relaton::Registry' under v3).
The dependency floor becomes relaton >= 3.0.0.pre.alpha (the monogem) and Relaton::Cli.registry resolves Relaton::Db::Registry directly — the v2 fallback stays on the 2.x line (PR #132).
The released 3.0.0.pre.alpha gems lag relaton main (the pubid v2 base_identifier rename), so CI resolves main until the next pre ships.
…d iso_2146 cassette - version: drop the relaton-bib line and only print processor gems that are actually loaded — the v3 monogem ships every flavor, so neither relaton-bib nor per-flavor gems exist anymore - fetch specs: derive the Recognised types expectation from the registry instead of the hardcoded v2 flavor list - iso_2146.yml: re-record against the v3 index-v2.zip fetch flow. Recorded out-of-band with stdlib psych (yeptris#168 makes any dump through the rebind emit unparseable/mangled bytes): the zip body is byte-identical to the live download (sha-verified) and carried as a core !binary scalar
…s deterministic - fetch_document rescues Parslet::ParseFailed and reports "<code>" is not a recognized standards identifier (port of relaton 05add9456, which landed on the monorepo's gems/relaton-cli after this branch forked) — an unparseable reference was an uncaught pubid ParseError with exit 1 on the v3 line - the acceptance shell-outs invoke bundle exec relaton instead of the ambient binstub, so they exercise this branch's exe rather than whatever gem is installed; the undefined-standard expectation moves to the friendly message
Adapter selection is an end-user concern: relaton-cli owns its choice the same way the library stopped owning it. Pins nokogiri for now (lutaml-model#856 blocks leptris for derived map_content).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.