You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
There are a few major hurdles that need to be tackled:
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
The text was updated successfully, but these errors were encountered: