https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43694 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=43674 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43694 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also|https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=43674 | Depends on| |43674 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 [Bug 43674] ISO 18626 messages are missing the mandatory ISO18626Message envelope -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43694 --- Comment #1 from Phan Quang Minh <minhpq@tinhvan.com> --- Correction to my own report, after testing the patch on bug 43674 against our implementation. I wrote that a conformant receiver rejects an out-of-order message at parse time. That is too strong, and in our case it was wrong. Retesting with the same message content in two element orders: - correct schema order -> our parser reads it; XSD validation passes - scrambled order -> our parser still reads it, with no data loss; XSD validation fails So .NET's XmlSerializer, which is what our implementation uses, matches child elements by name and tolerates sequence violations. A validating parser does reject the message — XSD validation fails exactly as described — but a receiver that only deserialises will not notice. I also traced what actually broke our first exchange with Koha, which I attributed to ordering in the original report. It was the timestamp format, not the order: <timestamp>2026-09-30 10:23:41</timestamp> A space instead of T, and no timezone, so not a valid xs:dateTime. That one does throw on deserialisation and does fail XSD validation. Ordering was a red herring in the failure I described. What still stands, and why I think this is worth fixing anyway: - The XML Koha emits is objectively schema-invalid, verifiably so against the official XSD, and invalid differently on each run. - Any partner that validates against the schema — which is a reasonable thing for an ILL system to do, and arguably what Koha should do to its own output — will reject the message, intermittently. - A defect that appears and disappears between runs is expensive for whoever meets it next. We only found it because we were looking at the XML rather than at whether the exchange happened to work. The reproduction script in the original report is unaffected: five runs still produce five different element orders. Sorry for the overstated impact claim. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43694 --- Comment #2 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Created attachment 207109 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207109&action=edit Bug 43694: Emit ISO 18626 elements in schema order Koha::REST::V1::to_xml builds XML from Perl hashes, so child elements come out in random hash order. ISO 18626 uses xs:sequence, so element order is significant and schema-conformant partners rejected the messages, differently on each attempt. xml_with_envelope now puts every element's children in the order of ISO-18626-2021-3.xsd before adding the envelope. Elements the schema does not define come last, sorted by name. Koha::REST::V1::to_xml is unchanged. Test plan: 1) Apply patch and restart_all 2) Run this a few times and note the element order is the same every time, and matches the schema (header, messageInfo, statusInfo): perl -MKoha::ILL::ISO18626 -e 'print Koha::ILL::ISO18626::xml_with_envelope({ supplyingAgencyMessage => { statusInfo => { status => "Loaned" }, messageInfo => { reasonForMessage => "StatusChange" }, header => { timestamp => "2026-09-30T00:00:00Z", requestingAgencyRequestId => 1 } } })' 3) prove t/db_dependent/Koha/ILL/ISO18626.t t/db_dependent/api/v1/iso18626/request.t Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43694 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #207109|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43694 Phan Quang Minh <minhpq@tinhvan.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #4 from Phan Quang Minh <minhpq@tinhvan.com> --- Signed off. Tested on Koha 26.05.02 with the bug 43674 patches applied. Determinism. Ran the test plan's one-liner six times: identical output every run, and in schema order. header, messageInfo, statusInfo header, messageInfo, statusInfo header, messageInfo, statusInfo header, messageInfo, statusInfo header, messageInfo, statusInfo header, messageInfo, statusInfo Before the patch the same six runs gave six different orders, only one of which was valid. Schema validation. A supplyingAgencyMessage produced by xml_with_envelope now validates clean against ISO-18626-2021-2.xsd. That is the strongest check I can make from here, and it passes. Interoperability. Our third-party implementation keeps a compatibility shim that logs every correction it has to make to an incoming Koha message. The entry for element reordering has disappeared from the log. What is left is only the two outstanding defects: before any patches: missing envelope; timestamp format; element order; agency id after bug 43674: timestamp format; element order; agency id after this patch: timestamp format; agency id which correspond to bug 43701 and bug 43695. Two of the four workarounds are now gone. Same caveat as bug 43674: this is a package install, so I cannot run the prove step. Everything else in the test plan passes. One thing you will want to know, since this patch sorts by that schema ISO-18626-2021-3.xsd as published does not compile. Line 270: <xs:element name="sentToPatron" type="xs:type_yesNo" minOccurs="0"/> The type is in the ISO 18626 namespace, but the reference carries the xs: prefix, so it resolves to {http://www.w3.org/2001/XMLSchema}type_yesNo, which does not exist. Two independent processors refuse to load the file: XML::LibXML: element decl. 'sentToPatron', attribute 'type': The QName value '{http://www.w3.org/2001/XMLSchema}type_yesNo' does not resolve to a(n) type definition .NET: Type 'http://www.w3.org/2001/XMLSchema:type_yesNo' is not declared It is a one-character typo introduced in 2021-3 — 2021-2, v1_2 and v1_3 are all clean — and dropping the xs: prefix makes the file load and my validation above pass against it too. It does not affect your patch, which only reads the element ordering, and it does not affect messages on the wire. But it does mean nobody can currently validate against 2021-3 as published, which is worth someone raising with the schema maintainers. You are far better placed than I am to know who that is. -- You are receiving this mail because: You are watching all bug changes.