https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674

--- Comment #10 from Phan Quang Minh <[email protected]> ---
Thank you for pointing that out — you are right, and I should have checked
which schema revision the core work targets rather than assuming. For the
record, illtransactions.org currently publishes five: v1_1, v1_2, v1_3, 2021-2
(June 2022) and 2021-3 (December 2025). We built against v1_2, which is two
revisions behind the one you used. That is on us and we are moving to 2021-3.

I have now diffed the two. None of the three reports changes:

Envelope (this bug). 2021-3 declares ISO18626Message identically, same
namespace, same required version attribute, wrapping the same xs:choice of six
message types. Your patch is correct against 2021-3 as well as v1_2.

Element order (bug 43694). 2021-3 uses xs:sequence throughout — 68 of them — so
order is still significant. The reproduction in that bug stands unchanged.

Agency identifiers (bug 43695). type_agencyId still carries agencyIdType and
agencyIdValue. Worth noting that 2021-3 is stricter here than v1_2 was: in
type_supplyingAgencyMessageHeader both supplyingAgencyId and requestingAgencyId
are
mandatory, so the hardcoded values are not an optional field being filled in
with a
placeholder — they are required content that currently carries no information.

Where the revisions do differ, and it affects us rather than you:

  - v1_2 has a single shared header element. 2021-3 splits it into
    type_requestHeader, type_requestingAgencyMessageHeader and
    type_supplyingAgencyMessageHeader, with different content models. Notably
the
    supplying header has no requestingAgencyAuthentication, which matches what
I said earlier about there being nothing in a supplyingAgencyMessage to
authenticate the sender with — it is explicit in 2021-3.
  - multipleItemRequestId is mandatory in v1_2 but optional in 2021-3. We had
been
    filling it with a copy of requestingAgencyRequestId to satisfy v1_2, which
was always a bit of a fiction; under 2021-3 we can simply omit it.
  - confirmationHeader drops multipleItemRequestId; messageInfo loses
offeredCosts,
    retryAfter and retryBefore to the new retryInfo; serviceInfo renames
preferredFormat to itemFormat and gains preferredEdition and loanCondition;
supplyingAgencyMessage gains retryInfo and shippingInfo; consortialId is new.

So the remaining timestamp issue I mentioned in comment #6 is unaffected by any
of this:
xs:dateTime means the same thing in every revision.

Noted that you have made 43694 depend on this one. That ordering makes sense to
me — the envelope patch touches the same serialisation path an ordering fix
would have to change.

-- 
You are receiving this mail because:
You are watching all bug changes.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Reply via email to