Do we really need separate code lists for RVQ, RQT, and RNQ

[mdovey]

RVQ is not used in the LCF 1.0.1 specification, as Q16D01 for reservation requests references RQT rather than RVQ. In any case the overlap is substantial (and it could be argued that RQT02 - none blocking confirmation request should exist in RVQ, and RVQ02 - modify previous should exist in RQT02).

Depending on whether we review the mechanisms for third party requests (see issue #116) which should really apply to all requests not just renewal ones and renew all requests (see issue #117), it is possible that the overlap between RNQ and RQT is also substantial and these three code lists could be merged into a single one.

[franciscave]

I agree that code list RVQ isn't used and should therefore be deprecated, but that RVQ02 would be potentially useful in code list RQT, i.e. as a generic "modify previous request" option.

I also agree that the use of RNQ to indicate "renew all" type requests and third party requests could be handled in more generic ways that could be applicable to some other requests. In both cases a flag similar to Q11D07 (Charge acknowledged) might be more appropriate, i.e. a "applies to all" flag and a "request from third party" flag. These would only be meaningful in certain requests.

We could therefore consider adding an "applies to all" flag to the following requests:

• Q11 Check-out/renewal - for use with renewals only, and applying to all items currently on loan to that Patron
• Q12 Check-in - applying to all items currently on loan to that Patron
• Q13 Patron payment - applying to all charges currently on the Patron's account - the LMS would need to check that the payment amount was sufficient to cover all charges, but that is a relatively simple extension to checking that a payment is sufficient to cover a specific charge
• Q16 Reserve manifestation/item - for use only when cancelling reservations, applying to all reservations currently on the Patron's account.

A "request from third party" flag would presumably apply to much the same range of requests, i.e. Q11 (renewals only), Q12, Q13, Q16.

If these flags are added, RNQ can be deprecated.

[franciscave]

The Technical Panel has agreed that "renew all" functionality is not going to be provided in the REST web service implementation, but should probably be retained in the LCF Data Framework for compatibility with SIP2. See #117.

However, the code values available in list RNQ can certainly be slimmed down. Code values RNQ05 and RNQ06 appear to duplicate code values RQT04 and RQT03 respectively and should probably be retired/removed.

If code list RNQ is to be retained in the Data Framework and code values RNQ01 and RNQ02 in particular are to be retained for compatibility with SIP2, the description of element Q11D04 must be changed, to allow it to be omitted when the renewal type is RNQ01 or RNQ02, since requiring a single item reference in this case doesn't make any sense.

[franciscave]

Data framework revised. See pull request #277.

[franciscave]

Schema may need revising to allow multiple loan records in the response to a "renew all" request, although in practice the REST web service implementation isn't using the "renew all" functionality, so a schema change may not be advisable.