bic-org-uk/bic-lcf

BIC Library Communication Framework

bic-lcf's Issues

Why do we define our own Date and DateTime types and not use the standard ones?

Date and DateTimes.

In the XSD schema we define our own date and datetime formats as:

<xs:simpleType name="dateFixedFormat">
    <xs:restriction base="xs:string">
        <xs:pattern value="2\d\d\d(0[1-9]|1[0-2])(0[1-9]|1[0-9]|2[0-8])"/>
        <xs:pattern value="200[048]0229"/>
        <xs:pattern value="2[1-9]0[48]0229"/>
        <xs:pattern value="2\d([2468][048]|[13579][26])0229"/>
        <xs:pattern value="2\d\d\d(0[13-9]|1[0-2])(29|30)"/>
        <xs:pattern value="2\d\d\d(0[13578]|1[02])31"/>
    </xs:restriction>
</xs:simpleType>

<xs:simpleType name="dateTimeFixedFormat">
    <xs:restriction base="xs:string">
        <xs:pattern
            value="2\d\d\d(0[1-9]|1[0-2])(0[1-9]|1[0-9]|2[0-8])T([01][0-9]|2[0-3])[0-5][0-9][0-5][0-9](Z|[+\-](0[0-9]|1[0-2])(00|15|30|45))?"/>
        <xs:pattern
            value="200[048]0229T([01][0-9]|2[0-3])[0-5][0-9][0-5][0-9](Z|[+\-](0[0-9]|1[0-2])(00|15|30|45))?"/>
        <xs:pattern
            value="2[1-9]0[48]0229T([01][0-9]|2[0-3])[0-5][0-9][0-5][0-9](Z|[+\-](0[0-9]|1[0-2])(00|15|30|45))?"/>
        <xs:pattern
            value="2\d([2468][048]|[13579][26])0229T([01][0-9]|2[0-3])[0-5][0-9][0-5][0-9](Z|[+\-](0[0-9]|1[0-2])(00|15|30|45))?"/>
        <xs:pattern
            value="2\d\d\d(0[13-9]|1[0-2])(29|30)T([01][0-9]|2[0-3])[0-5][0-9][0-5][0-9](Z|[+\-](0[0-9]|1[0-2])(00|15|30|45))?"/>
        <xs:pattern
            value="2\d\d\d(0[13578]|1[02])31T([01][0-9]|2[0-3])[0-5][0-9][0-5][0-9](Z|[+\-](0[0-9]|1[0-2])(00|15|30|45))?"
        />
    </xs:restriction>
</xs:simpleType>

I think it would make far more sense to use the standard XSD Date and DateTime types (defined here http://www.w3schools.com/schema/schema_dtypes_date.asp). The advantage of this is many software libraries written in different programming languages will parse and build standard XSD date and datetime values. This would mean implementors would not need write custom parsing and building code for these fields. Defining our own DateTime type also makes the interface confusing (since when implementors see "DateTime" type in the entity document they will assume this means the standard XSD DateTime type).

Entity documentation incorrect when compared with XSD schema

In the XSD schema the Patron entity has a 1-1 relationship with a Contact-ref (i.e. a cardinality of 1). Yet in the entity documentation the cardinality is specified as "0-1".

Similarly in the XSD schema a Contact entity has a 1-1 relationship with a Patron-ref (i.e. a cardinality of 1). Yet in the entity documentation the cardinality is specified as "1-n".

Could the entity documentation be updated to reflect the current schema?

Patron Authorisations Request

Reviewed with the attendees of the PlugFest#2 event.

The proposal is to add in a process to validate and retrieve the authorisations for a Patron, allowing consumers to determine whether a Patron should have access to a specific 3rd party service or resource.

The group reviewed the following specification, and agreed this would meet the use case described.

GET /lcf/1.0/patrons/{unique-id}/authorisations
patron-pin: 1234 <--- use the same encoding as for HTTP/BASIC "unique-id:pin" BASE64 or encoded with a pre-shared secret

Reponds with:

HTTP/200

...

-- or --

HTTP/4xx - go get your access token from the IdP again.

Various enumeration issues in xml schema

The following I presume are just errors in the xml schema enumerations and I'll just fix unless anyone shout:

circulation-status goes up to 13 in xml schema but 16 in the code list
charge-type goes up to to 10 in xml schema but 13 in code list

However, slightly less obvious:

charge-status goes up to 04 in the xml schema but only 01, 02 and 03 are defined in the code list, is this an error in the schema or is there a 04 which hasn't been added to the code list?

Are any of the repeatable elements of LCF 'flagable' as PRIME

The recent plugfest was an absolute delight. The organisers got it absolutely right: right size, right place, right content. Thank you.

HOWEVER a spark is now growing into a bit of a burning issue:

A BORROWER may have a number of repeatable elements: Contact and Email Address to name but two.

Where does the responsibility lie to designate which of any repeated elements is prime so that (for example) self-service doesn't have to take on the unenviable and ergonomically poor task of asking a user to choose between alternatives, for example when choosing to receive receipts via email?

I hope I'm not being a bit thick. Maybe I'm missing something.

All the best. MikeC 2CQR Ltd.

Contact vs Patron name confusion?

While working through a PoC implementation of LCF, it became aparent that "Patron" does not mean a Person in the real world. This was my expectation at first seeing that word. The "Contact" entity is actually a Person in the real world.

I wonder whether this may lead to confusion within the library community, since i've already had conversations with Bibliotheca, who also seemed to have the understanding that Patron was a person?

OAuth for authentication of terminal applications

We currently recommend the use of HTTP challenge response, IP restriction or PKI authentication for terminal applications wishing to use LCF services. We should include OAuth (oauth.net) as a web authentication standard.

"As a self service device developer I would like to be able to verify that the ID and PIN that a patron has provided are correct."

"As a self service device developer I would like to be able to verify that the ID and PIN that a patron has provided are correct."

This has some overlap with the earlier discussion about "Authentication & Access Logs"...

I need to be able to verify if the credentials provided by a user are correct. Considering REST and that earlier discussion it appears that this shouldn't be a GET as the PIN needs to be safely encrypted in the body of the message. I don't want to do an update or a create of the user, so it's not a POST or a PUT of the Patron entity.

I'd be in favour of this being a new small service/interface of its own, adding functionality to the interface and not just CRUD. I've been circling DDD for a while, and so functional interfaces appeal to me.

This is a key part of what our software needs to be able to do, and I suspect that it's not an uncommon requirement.

Plural vs Singular entity names in REST URIs

When retrieving an entity the "Format for URI" section specifies that the "key-entity-type" should be set to the alpha code value from the code list ENT. Therefore if following this exactly to create a URI to retrieve a manifest I would create:

/lcf/1.0/manifestation/{manifest-id}

This contains "manifestation" (singular)

There is then an example URI in the standard which is:

GET http://192.168.0.99:80/lcf/1.0/manifestations/1234567890

This contains "manifestations" (plural)

The examples in the standard do not have consistent use of plural or singular

Retrieve: GET http://192.168.0.99:80/lcf/1.0/manifestations/1234567890 (plural)
Retrieve list: http://192.168.0.99:80/lcf/1.0/manifestations (plural)
Create: POST http://192.168.0.99:80/lcf/1.0/manifestation (singular)
Modify: PUT http://192.168.0.99:80/lcf/1.0/manifestation/1234567890 (singular)
Delete: DELETE http://192.168.0.99:80/lcf/1.0/manifestation/1234567890 (singular)

I think it would make more sense to always use plural and make it clear that the plural should always be used. This is because a RESTful URIs should be structured so each part is an element of the previous part.

In the retrieve, modify and delete URI examples the manifestation "1234567890" is an element of the "manifestations" collection.
In the retrieve list URI, the collection of "manifestations" is being retrieved
In the create URI a new manifest is being added to the "manifestations" collection

Authentication & Access Logs

When we're looking to use a Patron's barcode and PIN within a web service call, the LCF standard currently mandates that these values should be passed on the query string to the request. This would be insecure, since the query string will be recorded in plain text in access logs throughout the proxies and servers before the service is processed. In effect this means that the Barcode and PIN would be captured in a file in plain text, which is a violation of OWASP guidelines.

We need to ensure that these details are only ever passed within the body of the request, typically as FORM POST parameters, or we find an alternative machanism completely.

XML schema for LCF entities contains redundant code

In reviewing the changes from proprietary date-time formats to use the standard xs:dateTime, I notice that there are some redundant element definitions that are never used in entities. These include (this list may not be exhaustive):

• due-date-time
• fee-description
• fee-due-date-time
• fee-limit

Note that the redundant fee elements were at some point re-named as charge elements. Only fee-type and fees-due-items are still used in entities.

Encryption

We need to make it clear in the web service implementation documentation that, because LCF communication may contain personal data, communication must/should (which?) be encrypted. The place for this is probably in the implementation notes.

Numeric entity codes values versus alpha values in lcf-entity-list-response

As far as I can tell the only place the numeric code values for ENT code is used is in the entity-type element of the lcf-entity-list-response (as the REST urls use plural versions of the alpha values).

For consistency, would it be better to specify that the entity-type used the alpha value?

If we do use the alpha value should this be the singular or plural form?

(I'm loath to suggest implementations can use either as this added additional complexity)

TEst ISsue

This is a test

"As a self service device developer I need to be able to determine the age of a patron."

"As a self service device developer I need to be able to determine the age of a patron."

We will process a patron according to their age, or borrower category, so that children, teens and adults can be handled differently. At present the standard doesn't appear to offer this.

It is something that various flavours of SIP2 have offered and handled in different ways, so this has been a requirement of other systems in the past.

Need a security-resensitize field in lcf-checkin-response

lcf-checkout-respnse has a security-desensitize field to instruct a self issue kiosk to disable any security tag.

Shouldn't lcf-checkin-response have a corresponding security-resensitize field to instruct the kiosk to re-enable the security tag?

Why is loan-status within the loan entity repeatable

Why is the loan-status field within the loan entity repeatable. Surely only one status can be applicable at any one time?

Providing entity identifiers upon creation

The LCF specification does not specify which of the following is true when creating a new entity via a HTTP POST request:

a) The client should never provide an entity's identifier, as all entity identifiers should be generated by the server. Or:
b) The client should always provide an entity's identifier, and the server will then be forced to use this identifier. Or:
c) The client should provide an identifier when creating certain entities, but not provide an identifier when creating others.

I would assume point c above is true, but I am worried it will cause interoperability problems if not specified in detail, since LMS vendors may assume different entities should have their identifiers generated by the client.

I think entity identifiers should always be generated on the server side, except in the case of an Item entity or a Patron entity (since I am assuming the patron and item identifier will always be their barcodes as is the case in SIP). The reasons for allowing the client to specify the identifier is it would be useful if the LCF could be used in the following scenarios:

• An item which has already has been barcoded is being added to library via an LCF client , therefore it is important that the LCF client can specify the barcode on creation.
• A member of Library staff is using an LCF client to add a borrower. The staff member might take the next free library card out a drawer or cupboard and assign it to the borrower.

Therefore it is essential that LCF servers allow clients to specify the patron and item identifiers. However the scenario may also take place where a new patron is using an LCF client (imagine this is a page on the library website) to join the library. In this case the library might post the patrons library card to them through the mail, in which case the LCF server would need to generate the patron barcode itself. Therefore maybe LCF servers should be able to generate a patron barcode if not specified by the client.

I am asking this question in the hope it will provoke discussion. I think the simplest solution to allow all implementations to be interoperable would be for LCF servers to allow clients to specify identifiers for both Patron and Item entities, but not require them to do so, as well as agreeing that the LCF server will be responsible for generating identifiers on all other entities.

Why is location-ref repeatable under associated-location

I can understand why associated-location is repeatable under patron, item etc. e.g. in the following xml

     <patron>
.    ..
       <associated-location>
         <association-type>03</association-type>
         <location-ref>http://someserver/lcf/1.0/location/someid</location-ref>
       </associated-location>
       <associated-location>
         <association-type>03</association-type>
         <location-ref>http://someserver/lcf/1.0/location/someotherid</location-ref>
       </associated-location>
     </patron>

However, in the schema location-ref is repeatable within a single associated-location element permitting the following:

     <patron>
.    ..
       <associated-location>
         <association-type>03</association-type>
         <location-ref>http://someserver/lcf/1.0/location/someid</location-ref>
         <location-ref>http://someserver/lcf/1.0/location/yetanotherid</location-ref>
       </associated-location>
       <associated-location>
         <association-type>03</association-type>
         <location-ref>http://someserver/lcf/1.0/location/someotherid</location-ref>
         <location-ref>http://someserver/lcf/1.0/location/yetanothersomeotherid</location-ref>
       </associated-location>
     </patron>

Is this intentional or just an error in the schema?

Patron-id-type incorrectly mapped to code list IMI?

Within the documentation for the Patron entity
https://github.com/anthonywhitford/bic-lcf/wiki/LCF-1.0.1-Information-Entity-XML-bindings#e03-patron
element E03D27.1 is listed as code list IMI, which is Item Identifier Types. This seems to be incorrect, adn it should map to a code list for Patron Identifier Types, which does not currently exist.

Entity/record references: strings or URIs?

Entity/record references, such as 'loan-ref', are used to link entities together. These are defined in LCF v1.0 and in the XML bindings to be of type 'string', because how an entity/record is referenced will be implementation-dependent. However, in the RESTful web service implementation we may be able to agree that all such references will always be URIs, in which case this should be documented. The XSD for the XML bindings should probably continue to define the data type to be 'xs:string', rather than 'xs:anyURI', because these XML bindings might be used in other kinds of implementation. We might therefore wish to define an XSD specifically for the RESTful web service implementation in which these strings are constrained to be URIs.

Clarification of E01D18 - Number of copies in stock

Can I clarify what is meant by

E01D18 Number of copies in stock

Is it the number of items the library currently owns - i.e. would exclude items with the status of lost, missing, on order.

Or is it the number of items currently available for loan - i.e. would exclude items already on loan or reserved.

Or is it the number of items immediately available for loan - i.e. would exclude those on waiting to be reshelved or in transit between locations

What about items temporarily withdrawn from circulation e.g. for repair? Or permanently withdrawn from circulation but still owned (e.g. reference only items)?

Inform a patron of their position in a reservation queue

I suggest the addition of a field to the Reservation entity to indicate the patron's current position in the queue for that Manifestation or Item.

How do I set a PIN for a borrower

Only required where the BARCODE/PIN authentication is required, and there is a need to reset / change a Patron's PIN.

POST /lcf/1.0/patron/{unique-id}/pin
456576

PIN value passed over an encrypted channel in plain text, such that the enforcing system has the original value in order to apply the system's hashing.

Who/what creates the identifier of an entity instance?

When an entity item, e.g. a new manifestation, is created by a request, should the identifier be excluded from the request? At present the identifier is a mandatory element for all entity items, but I think that maybe the one occasion on which it should be possible for the LMS to ignore it is when the function is 'create' and the LMS assigns the identifier.

If I'm right, I think we can address this point by extending Note [4] in the main LCF spec to explain that entity identifiers are mandatory in responses, and are mandatory in requests except when creating a new entity, in which case the LMS may ignore the identifier if included in the request.

Exception conditions

We should review implementation note 4 in the LCF 1.0 Web Services Implementation documentation to make sure that it is fit for purpose. We should also review The LCF Exception Conditions XML schema and its documentation in the LCF 1.0 Information Entity XML Bindings documentation, together with the associated code lists (EXC and RDN), to make sure that these are also fit for purpose. This is probably not a top priority task, but will become so if implementing a web service throws up the possibility of business logic exceptions that we haven't thought of yet.

Communication locator might not always be a single string

In folding Contact properties back into the Patron entity it probably makes sense for a Patron address to become simply another instances of Communication Details (currently E09C05), in which case Communication Locator (currently E09D05.2) would need to contain multiple address lines. This suggests that Communication Locator should become a composite property containing 1-n Communication Locator Line properties. We would need to provide some guidance on how to use this, since Locator Lines make sense for some Communication Types but not for others.

Untidy MarkDown in specs

I'm probably being anal, but it offends me that the tables are so hard to read in the wiki editor. So I'm in the process of tidying it up. This shouldn't affect the normal layout, just when I'm editing. But my hope is that it will also make it easier for me to generate PDF documentation for the BIC site in due course. So far I have completed the tidy-up of the XML bindings spec and am about two-thirds of the way tidying-up the main LCF specification. I think that the code lists are probably OK the way they are.

ENT codes do not match entities

The Entity document lists 12 Entities, while the Codes document lists11 ENT codes. The first 9 ENT codes match the first 9 entities, however the last few seem out of sync.

The final 4 entities defined in the entity document are:
E09 - Contact
E10 - Title Classification Scheme
E11 - Title Classification Term
E12 - Selection Criterion

The final 3 ENT codes defined in the codes document are

ENT09 - Class scheme
ENT10 - Class code
ENT11 - Property

I suspect the codes document just needs updating to contain consistent information to the Entity document.

Add support for family/group patron accounts

To allow a 'lead' patron to view their family's/group's loans, etc. and borrow, renew , etc. for them, I suggest adding a repeatable 'associated patron' field to the Patron entity.

Discovering if an entity element is updatable

Currently there is nothing in LCF entities indicating if an element of an entity is updatable. In an ideal world all elements of all entities will be editable, however in practice different LMS vendors store different data which will therefore be mapped to the LCF entities differently. (For example one LMS vendor may support notes on loans while another may not). Not allowing a client to know what is uneditable is likely to result in problems. For example imagine if an LCF implementation does not support updating borrowers address (via a POST to the Contact entity), and a very clever self service machine (or other client) connected attempts to do this. It would be very frustrating for the end user to type in their new address only to be informed that the address could not be updated afterwards.

Therefore I think it would be beneficial to add an "updatable" (and possibly "deleteable") attribute to each XML element indicating if clients are able to update (or delete) the element. This solution does not fully address the problem of clients sending updates which can not carried out on the underlying LMS, but I would expect it would prevent the majority of unsupported entity update requests. It would still be a problem where for example an LMS supported mobile phone numbers (CMT code 04), but not work phone numbers (CMT code 03) and client attempted to add a work number.

Another similar idea I had was elements with a 1-n cardinality could also have an optional max-size attribute. For example some LMS implementations may support a loan having no notes, a single note, or an unlimited number of notes. On implementations which support up to one note per loan the "notes" element could contain the attribute "max-size="1"".

Explain "selection criterion" (filtering???) on "Retrieve entity instance list" section in "LCF 1.0 REST Web Service Specification" document

In section "Retrieve entity instance list" of the document "LCF 1.0 REST Web Service Specification" there is a table describing the "Format for request URI". Row 8 in this table table appears to be a way to specify filter criteria and references “Q02D02.2” which as far as I can see does not exist.

None of the URI examples below the table use this parameter, and it is definitely not obvious how it should be used. If we are to keep this URI parameter in the standard I think the following should be added:

• An example GET list URI which uses filtering
• A list of what is valid filtering criteria for each entity containing the exact strings which should be used as parameters in the URI.

The answer to the second question is not obvious (It is not possible to just use the name of each element in an entity which is what I expect the designers initially thought). What if I wanted to filter Contacts on a specific phone number or email address. A phone number is stored in element “locator” which is a child element of “communication-detail” (which is an element of contact entity). “communication-detail” elements only contain phone numbers in their “locator” element if their “communication-type” element has a value of “01”, “02”, ”03”, or “04”. An email address is similar except will have its “communication-type” element set to “05”. There is no obvious way to achieve filtering on these things. (And no clearly defined way to use this parameter to filter on anything at all)

I think this parameter should be removed from the standard (since if it is included different implementations are almost sure to support filtering on different things leading to inconsistencies between implementations)

The standard already provides filtering on element-ref fields by supporting URI's in the format:

/lcf/1.0/manifestations/1234/items

The above example would return a list of items for manifestation ID 1234. Being able to support URIs in this format means the standard already provides filtering for most common use-cases without the need for this "selection criterion" parameter in the URI.

Broken links to BIC LCF web pages in LCF v1.0 (and v1.0.1) main documentation

There are still some old links to 'http://www.bic.org.uk/lcf'. They should be 'http://www.bic.org.uk/114/LCF/'. I'll fix this.

Retrieve the ISBN associated with an Item

Would it be reasonable for the ISBN to be returned in the E02C02 Additional identifier field of an Item record or would an additional call to retrieve the Manifestation record be required?

Datatype for code lists in entities XML schema

The use of xs:token as the base datatype for most of the LCF code lists in the entities XML schema means that XML parsers will ignore white space around code values in the affected elements. For interoperability it would probably be better if the base datatype were xs:string, as parsers will then not ignore white space and this reduces the scope for variation among implementations.

Suggestion to reserve -ref suffix for the names of elements which contain a REST url reference to a LCF entity

I think the following XML elements are meant to contain a (locally defined) LMS identifier:

transaction-ref in the payment entity
pickup-institution-ref in the reservation entity
pickup-location-ref in the reservation entity

Although the last one might be meant to refer to a location entity?

I would recommend that these elements are renamed so that the suffix -ref is only used for elements which contain a LCF actionable URL which resolves to a LCF entity

Providing a patrons user password upon creating a patron

When creating a patron there is no where on the entity for an LCF client to specify the patrons password. Also at the time the patron is created there are no contact details therefore generating a password randomly and emailing it, is not an option. Web services use the "user-pwd" query parameter (See LCF 1.0.1 REST Web Service Specification section 01 Retrieve entity item information) to pass the patrons password for authentication. I wonder if the authors intended implementors to also use this query parameter to set a patron password when creating a borrower via a HTTP POST requests to "/lcf/1.0/patrons"?

The answer to the question may be affected by the outcome of issue #19

New note type for promotional messages

To distinguish a note in a Patron entity as being for a promotion, I suggest the addition of a new 'Promotion' note type.

Purpose and content of lcf-reservation-response

Why does lcf-reservation-response apparently contain both a reference to the reservation entity record and also a copy of the reservation entity record?

For that matter, it isn't clear what additional information is in the lcf-reservation-response which isn't already in the reservation entity (i.e. what purpose is serve by returning lcf-reservation-response over just returning the reservation entity?)

Additional SIP2 64 Patron Response Fields

Under SIP2, many implementations extended message 64 (Patron Information response) to return additional fields that were not defined in the original specification. Although the field identifier differed between implementations, most LMS providers added, as a minimum, fields for Borrower Category and Internet Flag (a field denoting whether the borrower had signed a parental consent form to permit access to the Internet).

Looking specifically at entity E03 Patron in the current version of the documentation, I see that these fields have not been included.

Presuming that most customers will expect the same level of functionality as they currently receive under SIP2, is there any intention to include those additional fields that were added to SIP2 message 64 or have these been omitted intentionally?

xsd.exe treats element 'card-status' in Patron entity as mandatory

Microsoft xsd.exe appears to treat element 'card-status' in the Patron entity as mandatory. This may be because the element 'card-status' appears to xsd.exe to be mandatory, even though it is inside an xs:sequence grouping element which has minOccurs="0" specified. Unless there's a work-around, this would imply that a patron cannot be created without 'card-status', which is not the intention of the standard. Although we have specified this element to be read-only, so it will be ignored if included when creating a new patron, it would be better if a way could be found to ensure that the element can be excluded when creating a new patron.

REST responses schema does not define elements 'reason-denied' and 'element-ref'.

When the response is to report an exception condition, an XML payload providing details of the exception condition may be included in the response. This would use the element lcf-exception, defined in the schema lcf-v1.0-rest-responses.xsd. However, two elements that are used in exception condition responses are not fully defined: reason-denied and element-ref. The former should use the code list RDN. The latter should be a string.

Alerting a patron to the fact that their account is about to expire

I suggest the addition of a new field, ExpiryDate, to the Patron entity. Related to this, an addition to the PNS code list of 'Expired' would be required.

Additional Message display type to MGT code list for diagnostic information

Additional value to the MGT code list

MGT03 | 03 | System message (not normally for display)

This is intended for diagnostic display which may be of use by developers or engineers configuring client applications\kiosks but not intended for end user display

Investigate vCard support for Patron/Contact entity

Raised on the LCF Technical Panel Call.

mandatory ‘version’ attribute

The XML Bindings in the wiki state that top level elements have a "mandatory ‘version’ attribute" (version="1.0")

Firstly, this is not present the XML schema, so implementations currently based on this will not be including this attribute. This is of course easily fixed by adding

<xs:attribute name="version" type="xs:string" use="required" fixed="1.0"/> 

to the top level elements.

However, this raises two questions:

i) as we include a version number in the namespace http://ns.bic.org/lcf/1.0 do we need this version attribute

ii) how do we handle minor updates (e.g. 1.0.1). Given this includes schema changes should this be in the namespace (i.e. http://ns.bic.org/lcf/1.0.1)

Is E11 class-code or class-term

E11 is called class code in the main document, and also class-code in the ENT code list so for the web service access is via the URL /lcf/1.0/class-code

However, E11 is called class-term in the XML schema document and the XSD.

For all other entities the ENT code and schema name is consistent (modulo punctuation characters).

Selection Criteria Use Case - Offline Kiosk Patron Validation

A self issue kiosk which supports offline mode, may wish to validate patrons by storing a local cached copy of valid patron records\barcodes.

Whilst offline, the kiosk could periodically update the local cache of patron records\barcodes by using a retrieve patron instance list.

In a federal library system (e.g. within a collegiate university), it may be the case that a member of one location (branch, department, college etc.) would not have borrowing rights in another location. In this scenario, the self-issue kiosk would require to retrieve patron instance list with a selection criteria of a given location

Alerting a patron to a new note

I suggest the addition of an extra field, e.g. E03D21.4 - Acknowledged, to the Patron entity. This would enable a kiosk to alert users when a note has been added to their account that they haven't already marked as being read.

How can I make a credit payment against a Patron?

Discussed in the LCF Review Panel Meeting 2017-03-22.

Westmister have the wish to remove cash handling from their libraries. We discussed whether this would be a good reference implementation for LCF, however we need to ensure that the following are possible:

Scenarios:

• Authenticate an end user terminal ensuring they have permission to access Patron Charges
• Authenticate an end user terminal ensuring they have permission to apply new Patron Charges
• Find a Patron
• Add a charge to a Patron
• List charges against a Patron
• Pay a single charge against a Patron using new money
• Pay a single charge against a Patron using money already on account
• Pay multiple charges against a Patron using new money
• Pay multiple charges against a Patron using money already on account