Skip to content
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

[Meta] Records #88

Open
7 tasks
netsensei opened this issue Jan 25, 2019 · 0 comments
Open
7 tasks

[Meta] Records #88

netsensei opened this issue Jan 25, 2019 · 0 comments

Comments

@netsensei
Copy link
Contributor

netsensei commented Jan 25, 2019

This is a meta issue. This issue groups all issues regarding the "Records" (Record management, API's, formats, validation, etc.)

Detailed description

Support for records is only partially implemented in version 1.0.0. However, it's only a very basic implementation that only supports these features:

  • A basic REST API with HATEAOS support.
  • A single OAI-PMH endpoint without supports for set or deletions.
  • Only support for LIDO XML format.

There are a few major hurdles that need to be tackled:

  • The RecordsController code is wired up into FOSRestBundle and isn't well implemented at all (no DTO's, abstraction leakage, etc.)
  • The logic is split out over three separate bundles: OAIBundle, ResourceAPIBundle and ResourceBundle which semantically and architecturally doesn't make much sense.
  • The REST API returns the XML data as in Clark notation. However, this representation of the data isn't usable at all. We need a better way of representing ingested data, or decouple the representation of XML ingested data from the REST API entirely.
  • The REST API only accepts XML formatted data. Not JSON formatted data. This drastically limits the number of business cases that could benefit from the application.
  • The lack of proper Records management in the dashboard limits the appeal of the Datahub even more. That is, management of the records, not on a per-field level.

Context

We need to revise and overhaul the entire Records component in order to make it more maintainable, more versatile, extendable and attractive for new users.

Possible implementation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants