-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Partial record return #115
Comments
To implement this the URL query parameter "detail-requested" introduced in issue #191 would be applicable to entity GET requests using the appropriate code list for the entity. This will need additional code lists for all entities. Implementations would only need to support 01 (default\all details) from these code lists. |
We agreed that issue #191 should be resolved by introducing a new code list. We can therefore decide either to do nothing about partial records (this feature is not currently supported in the REST implementation), or to deprecate the feature in the Data Framework. My understanding is that there is a use case (of sorts) for this feature in SIP2, so while deprecating it would be safe, removing it entirely in a future major revision of LCF would possibly involve removing functionality that is used in SIP2 implementations. |
Agreed at technical panel to closed as a specific solution to #218 |
Removing milestone "someday.minor" as any resolution to this issue will be considered under #218 |
the LCF specification includes the ability to request partial records via Q02D03 and codelists IMD, MND and PNT. Currently this is not implemented in the REST specification which always returns full records.
There are at least two scenarios for returning partial records:
a) limited capacity either in transmission bandwidth or client processing power
b) privacy\security concerns (e.g. limiting information returned about patrons).
However, (a) is increasingly irrelevant as network and device capacities increase. and (b) should be controlled by the server based on user\device authentication not based on a client initiated request.
If there are still good reasons to include this functionality in the base LCF specification then these should also apply to the REST implementation. If this functionality is no longer required then it should be deprecated from the base LCF specification.
The text was updated successfully, but these errors were encountered: