Releasing v1.2.0

Tasks overlooked.

Patches after release v1.2.0

Support for using a payment to make a donation.

Adding code list PYP for use by new element E08D12 Payment purpose.

See issue #80.

Includes correction of element IDs and inconsistent naming of data types.

Corrected reference to ONIX code list 11 in LCF code list UNC. Reference should be to ONIX code list 19.

These changes are as a result of the decision to implement ONIX code lists 5, 15 and 19 in place of LCF code lists MNI, TTL and UNC respectively.

Removed LCF code lists MNI, TTL and UNC.

Schema changes consequent upon replacing LCF code lists MNI, TTL and UNC with the corresponding ONIX code lists 5, 15 and 19.

Corrected property IDs in E14. See issue #263.

Fixing styling of some composite elements, e.g. R11C02, which should be italicised.

Corrected 'R12C09' to 'R11C02' as the element reference for a loan record in the check-in response.

Fixed some styling inconsistencies.

The Core Profile is to be simplified to only require support for retrieval of entities.

With reference to issue #269, I am adding E08D12 to the Data Framework and the XML binding.

Added E08D12 `authorisation-ref`. Note the name originally proposed in #269 was `authorisation-reference`, but this was inconsistent, since the suffix 'ref' should be used when making reference to an LCF entity.

Removing an inconsistency between the Data Framework and the REST implementation. See issue #265.

Add E08D12 and E08D13

Added generated OpenAPI specification

Add structured personal names to Patron entity

Minor editorial nits

Remove code lists MNI, TTL and UNC

Update LCF-DataFrameworks.md

Simplification of Core Profile P00

Add authorisation reference to E08 Payment

Modifications to R11D03 and R11D04

Modifications to E01 Manifestation to allow it to describe a serial title, a serial issue or a bound set, and to enable association of related manifestations.

Added code lists MNA (Manifestation association type) and MNT (Manifestation type).

Added elements E01D22 manifestation-type, E01D23 serial-holding-statement, E01C24 associated-manifestation (and child elements), E01D25 serial-issue-enumeration and E01D26 serial issue chronology.

The notes have been extended to explain that a confirmation request implements the SIP2 "no block" flag for use when confirming items that were checked out or in while the terminal application was off-line.

Modified the introductory descriptions of the circulation functions 11 (check-out) and 12 (check-in), to clarify the use of RQT02 confirmation request as being equivalent to the SIP2 "no block" flag.

Notes added to clarify the use of the confirmation query parameter with check-out and check-in requests.

This addresses the issue raised by #268.

Added E08D15 deposit-type to E08.

Adding Note under section 11 Check-out / renewal, resolving issues #116 and #117 and partially resolving issue #118.

Modifications made to the descriptions of elements Q11D04, Q11D05, R11D01, R11C02, R11D03, R11D04 and R11D05 in 11 Check-out / renewal request and response, to resolve in part issue #118.

Fixing inconsistencies in responses to check-out and check-in requests. See issue #276.

Handling serials/periodicals

Update LCF-RESTWebServiceSpecification.md

Allow deposits against future charges

…ation

Clarification of RQT02 confirmation request

Improving clarity of changes.

Revised Note under Check-out / renewal, to provide an explanation as to why the "renew all" request types are not implemented in a REST web service implementation.

Implementing changes agreed to resolve issue #266 and in partial resolution of issue #258.

Update LCF-ImplementationProfiles.md

Resolving issues 116, 117 and 118

Change agreed in issue #84, to require that the client acknowledge that a request has been accepted. Note that the proposed change corrects a typo in the issue discussion: 'in the description of R00D06.3, 'R00D06.1 contains '10' " should read "R00D05.2 contains '10' ".

Code list changes associated with the addition of R00D06.3.

With the addition of R00D06.3, MGT01 specifically does not require acknowledgement, to differentiate it from new code MGT04.

See issue #281.

Adding the ability to associate a pickup location with a manifestation or item.

Adding E01C27 Associated location to E01 Manifestation in the Data Framework, to support the association of a pickup location with a manifestation.

Adding E01C27 associated-location to the XML binding, to support association of a pickup location with a manifestation.

The Implementation Notes section of the REST web service specification is revised to make it explicit that alternative standard authentication methods, such as the bearer token method, may be used for terminal application authentication or patron authentication.

Adding E13D05 to Data Framework and to the XML Binding, to allow one or more library locations to be associated with an Authorisation of type AUT03 (consent to gain access to the location when un-staffed).

Acknowledgement required

Add value '17' to code list PNS

Pickup location

Alternative authentication methods

The element is already non-mandatory in the XML binding, so making it non-mandatory in the data framework eliminates an inconsistency. See issue #293.

E01C02 made non-mandatory

See issue #286.

Same note added to XML binding as added to the data framework.

See issue #295. Adds a location reference to the Authorisation entity.

Add note to E03C36

Location associated with an authorisation type

Adding Q00D10 (acknowledgement code) for use in requests, and R00C06.4 (applicable charge) for use in exception responses. See issues #84 and #292.

Adding R00C063 (acknowledgement-code) and R00C06.4 (applicable-charge) to exception conditions.

Adding notes and examples relating to exception responses requiring acknowledgement codes in check-out and reservation requests.

Adding documentation of Q00D10 and an example of multiple acknowledgement codes in a request. Also changed 'item' to 'title' in examples.

…tinued)

Resolving issues #84 and #292

Editorial tidy-up of Code Lists for release of Issue 5 / LCF v1.3.0.

Most of the changes replace references to LCF version numbers (e.g. *Added in v1.2.0*) with references to Issue numbers (e.g. *Added in Issue 4*). Rationale: Code Lists are identified by Issue number, not by LCF version number.

Updating the LCF version number and the link to the BIC license.

Simplifying link to BIC license.