Description

Document type-based submission

As outlined in https://wiki.duraspace.org/display/DSPACE/Document+Type+Based+Submission, many repositories deal with several document types and the only approach DSpace has to offer so far is a collection based form definition.
We found the following initiatives: https://jira.duraspace.org/browse/DS-464 and https://wiki.duraspace.org/display/DSPACE/Document+Type+Based+Submission , but they are very old and it is very hard to integrate one of them in our 1.8.0 DSpace. Along with this problematic integration we also need some other features to the submission process, which made the integration yet more complicated.
These initiatives propose to define a type-based form and/or pages, but we thought this would lead to a very complicated and redundant form definition, provided most document types share a lot of common fields. To avoid this replication, we propose to have a type-based field definition in the form configuration (input-forms.xml). That is, defining the forms and pages fields in the normal way, and only specify a type-restriction on those fields which are specific for some kind of document.

The following excerpt is an example o a form definition:
<form name="traditional">
<page number="1">
<field>
<dc-schema>dc</dc-schema>
<dc-element>type</dc-element>
<label>Document type</label>
<!-- other field properties -->
</field>
<!-- many others common metadata, like author, title, some date, language, etc -->
</page>

Considering we have now a type-based submission, we need to be able to define the same field for different document types, with different attributes. A clear example of this in our repository is the ISBN metadata: theses may have an ISBN metadata while books must have it. Also, the label and hint of these fields could be different. To achieve this we avoided the limitation on field duplicity, allowing to define the same field multiple times.
Another minor improvement proposed here was previously mentioned by Claudia Jürgen in https://jira.duraspace.org/browse/DS-334. We agree with Claudia in that the visibility and the required attribute are not related directly, so we removed that validation. We consider that the mandatory restriction makes sense only when the field is visible in a scope. Thus it is completely valid to define a visibility scope along with a required attribute.

Attachments

Here you can find two attachments: a zip containing the modified classes, and another zip containing the diff for all the modified classes (this diff was made against the 1.8.0 version).
We attached diff files for you to have a quick overview of the changes made.