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.