Structural Validation
Title (Goal) | Support Fedora 3-style object classes (content models) - Structural Validation |
---|---|
Primary Actor | Repository architect & implementer |
Scope | Data architecture and access |
Level | High |
Story (A paragraph or two describing what happens) | As a repository manager,
|
Examples
- I have a myns:image asset type that is auto-assigned to assets ingested by Imaging department.
- myns:image has mandatory properties and/or children such as a master datastream, of type nt:file or a subtype thereof.
- myns:image assets can only have children of nt:file type. Ideally, that nt:file should be within a range of defined MIME types (not a critical feature for now)
- I need a validation mechanism that throws an error if an user adds or updates a child or property that doesn't conform to that definition.
Issues / limitations
- The default primary type, nt:folder, allows all Fedora nodes to have children of any type, with any name, in any number. There is no way to restrict that with Fedora's current tools.
- The auto-assigned mixin type, fedora:resource, allows nodes to have properties of any type, with any name, in any number. Ditto as above.
- If a mix-in is removed that defines some properties and/or child nodes, currently these properties/child nodes are not removed. It is not easy to find which properties/child nodes were introduced by a content model, in order to "cleanly" remove it.
- Bad solution: mirror the content model schema in the client systems that are adding/removing content models so they know which properties/children can be removed along with the content model.
- Better solution: provide content model introspection methods via the REST API
- Another solution: provide a REST API method that automatically removes all properties/children before removing the content model (in one transaction, so no mandatory constraints are violated).