https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #6 from Phan Quang Minh <minhpq@tinhvan.com> --- Tested both patches on Koha 26.05.02 against a third-party ISO 18626 implementation — the .NET one that originally surfaced this bug, generated from the official v1.2 XSD. What I ran Steps 1-4 of your test plan pass. The response to the minimal request is wrapped: <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" xmlns:ill="http://illtransactions.org/2013/iso18626" ill:version="1.2"><requestConfirmation>... and the BadlyFormedMessage errors are the expected ones for that deliberately minimal body. Backwards compatibility holds. Both of these are still accepted: - a bare <request> in the ISO 18626 namespace - a bare <request> with no namespace at all, which is what unpatched Koha sends I could not run step 5. This instance is a package install, so it has neither t/ nor the test harness. That is the only part of your plan I have not verified, which is why I am not setting the status to Signed Off — someone with ktd should do that. Third-party interoperability, which is the part I can contribute Our implementation sends and expects fully conformant messages. Before the patch it could not talk to Koha at all. After the patch: - Koha -> us: ten supplyingAgencyMessage exchanges, all accepted. The compatibility shim on our side no longer reports a missing envelope, which it did on every single message before. - us -> Koha: ten requests sent with our compatibility shim switched off entirely, so fully standard XML — envelope, correct namespace, schema element order — all ten accepted by the patched endpoint. So this patch is what lets a conformant implementation reach Koha at all. Thank you for turning it round so quickly. Two things still needed before the shim can go away Not objections to this patch, just reporting what is left, since I happen to have the only setup that can see it: 1. Timestamp format. Koha emits <timestamp>2026-09-30 10:23:41</timestamp> and <lastChange> likewise — a space instead of T, no timezone. That is not a valid xs:dateTime, and unlike element order it genuinely stops a parser: our deserialiser throws on it, and XSD validation rejects it. This is the one remaining defect that actually blocks the exchange. Already reported against the plugin at https://github.com/openfifth/koha-ill-iso18626/issues/7, but Koha/ILL/ISO18626/Request.pm has the same problem in core. 2. Agency identifiers. Core still sends supplyingAgencyId = 'sup_agency_value' and requestingAgencyId = 'req_agency_value' (Koha/ILL/ISO18626/Request.pm lines 352, 359). We cannot match an incoming supplyingAgencyMessage to a partner, so we fall back to matching on requestingAgencyRequestId alone — which means we cannot verify who sent it. See my earlier comment on this bug. Element order (bug 43694) turned out not to block us in practice — see my correction there. The XML is still schema-invalid, but our parser happens to tolerate it. Happy to re-test any further patch on the same setup. -- You are receiving this mail because: You are watching all bug changes.