All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
...
Code Block | ||
---|---|---|
| ||
<item-submission> <!-- Where submission processes are mapped to specific Collections --> <submission-map> <name-map collection-handle="default" submission-name="traditional" /> ... </submission-map> <!-- Where "steps" which are used across many submission processes can be defined in a single place. They can then be referred to by ID later. --> <step-definitions> <step id="collection"> <processing-class>org.dspace.submit.step.SelectCollectionStep</process;/processing-class> <workflow-editable>false</workflow-editable> </step> ... </step-definitions> <!-- Where actual submission processes are defined and given names. Each <submission-process> has many <step> nodes which are in the order that the steps should be in.--> <submission-definitions> <submission-process name="traditional"> ... <!-- Step definitions appear here! --> </submission-process> ... </submission-definitions> </item-submission> |
...
For example:
Code Block | ||
---|---|---|
| ||
<step-definitions>
<step id="custom-step">
...
</step>
...
</step-definitions> |
For example:
Code Block | ||
---|---|---|
| ||
<submission-process> <step> ... </step> </submission-process> |
...
For example, the following defines a Submission Process where the License step directly precedes the Initial Questions step (more information about the structure of the information under each <step> tag can be found in the section on Structure of the <step> Definition below):
Code Block | ||
---|---|---|
| ||
<submission-process> <!--Step 1 will be to Sign off on the License--> <step> <heading>submit.progressbar.license</heading> <processing-class>org.dspace.submit.step.LicenseStep</processing-classing-class> <jspui-binding>org.dspace.app.webui.submit.step.JSPLicenseStep</jspui-binding> <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.LicenseStenseStep</xmlui-binding> <workflow-editable>false</workflow-editable> </step> <!--Step 2 will be to Ask Initial Questions--> <step> <heading>submit.progressbar.initial-questions</heading> <processing-class>org.dspace.submit.step.InitialQuestionsStep</process;/processing-class> <jspui-binding>org.dspace.app.webui.submit.step.JSPInitialQuestionsSteonsStep</jspui-binding> <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.InitialQutialQuestionsStep</xmlui-binding> <workflow-editable>true</workflow-editable> </step> ...[other steps]... </submission-process> |
...
The structure of the <step> Definition is as follows:
Code Block | ||
---|---|---|
| ||
<step> <heading>submit.progressbar.describe</heading> <processing-class>org.dspace.submit.step.DescribeStep</processing-classing-class> <jspui-binding>org.dspace.app.webui.submit.step.JSPDescribeStep</jspuilt;/jspui-binding> <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.DescribeScribeStep</xmlui-binding> <workflow-editable>true</workflow-editable> </step> |
...
For example, the following fragment shows how the collection with handle "12345.6789/42" is assigned the "custom" submission process:
Code Block | ||
---|---|---|
| ||
<submission-map> <name-map collection-handle=" 12345.6789/42" submission-name=" custom" /> ... </submission-map> <submission-definitions> <submission-process name=" custom"> ... </submission-definitions> |
...
The XML configuration file has a single top-level element, input-forms, which contains three elements in a specific order. The outline is as follows:
Code Block | ||
---|---|---|
| ||
<input-forms> <-- Map of Collections to Form Sets --> <form-map> <name-map collection-handle="default" form-name="traditional" /> ... </form-map> <-- Form Set Definitions --> <form-definitions> <form name="traditional"> ... </ </form> ... </form-definitions> <-- Name/Value Pairs used within Multiple Choice Widgets --> <form-value-pairs> <value-pairs value-pairs-name="common_iso_languages" dc-term="language_iso"> ... </value-pairs> ... </form-value-pairs> </input-forms> |
...
For example, the following fragment shows how the collection with handle "12345.6789/42" is attached to the "TechRpt" form set:
Code Block | ||
---|---|---|
| ||
<form-map> <name-map collection-handle=" 12345.6789/42" form-name=" TechRpt"/> ... </form-map> <form-definitions> <form name="TechRept"> ... </form-definitions> |
It's a good idea to keep the definition of the default name-map from the example input-forms.xml so there is always a default for collections which do not have a custom form set.
...
A form must contain at least one and at most six pages. They are presented in the order they appear in the XML. Each page element must include a number attribute, that should be its sequence number, e.g.
Code Block | ||
---|---|---|
| ||
<page number="1"> |
The page element, in turn, contains a sequence of field elements. Each field defines an interactive dialog where the submitter enters one of the Dublin Core metadata items.
...
...
This feature is currently only available for use with the XMLUI since DSpace 3.0 and with JSPUI since 3.1. A field can be made visible depending on the value of dc.type. A new field element, <type-bind>, has been introduced to facilitate this. In this example the field will only be visible if a value of 'theses' or 'ebook' "thesis" or "ebook" has been entered for into dc.type on an earlier page:-
Code Block | ||
---|---|---|
| ||
<field> |
...
<dc-schema>dc</dc-schema> |
...
<dc-element>identifier</dc-element> |
...
<dc-qualifier>isbn</dc-qualifier> |
...
<label>ISBN</label> |
...
<type- |
...
bind>thesis,ebook</type-bind> |
...
</field> |
...
You may notice that some fields are automatically skipped when a custom form page is displayed, depending on the kind of item being submitted. This is because the DSpace user-interface engine skips Dublin Core fields which are not needed, according to the initial description of the item. For example, if the user indicates there are no alternate titles on the first "Describe" page (the one with a few checkboxes), the input for the title.alternative DC element is automatically elidedomitted, even on custom submission pages.
...
The answers to the first two questions control whether inputs for certain of the DC metadata fields will displayed, even if they are defined as fields in a custom page. Conversely, if the metadata fields controlled by a checkbox are not mentioned in the custom form, the checkbox is elided omitted from the initial page to avoid confusing or misleading the user.
The two relevant checkbox entries are "The item has more than one title, e.g. a translated title", and "The item has been published or publicly distributed before". The checkbox for multiple titles trigger the display of the field with dc-element equal to '"title' " and dc-qualifier equal to '"alternative'". If the controlling collection's form set does not contain this field, then the multiple titles question will not appear on the initial questions page.
...
The taxonomies are described in XML following this (very simple) structure:
Code Block | ||
---|---|---|
| ||
<node id="acmccs98" label="ACMCCS98"> |
...
<isComposedBy> <node id="A." label="General Literature"> |
...
<isComposedBy> <node id="A.0" label="GENERAL"/ |
...
> <node id="A.1" label="INTRODUCTORY AND SURVEY"/> |
...
... |
...
</isComposedBy> |
...
</node> |
...
... |
...
</isComposedBy> |
...
</node> |
Your You are free to use any application you want to create your controlled vocabularies. A simple text editor should be enough for small projects. Bigger projects will require more complex tools. You may use Protegé to create your taxonomies, save them as OWL and then use a XML Stylesheet (XSLT) to transform your documents to the appropriate format. Future enhancements to this add-on should make it compatible with standard schemas such as OWL or RDF.
...
Vocabularies need to be associated with the correspondant DC metadata fields. Edit the file [dspace]/config/input-forms.xml
and place a "vocabulary"
tag under the "field"
element that you want to control. Set value of the "vocabulary"
element to the name of the file that contains the vocabulary, leaving out the extension (the add-on will only load files with extension "*.xml"). For example:
Code Block | ||
---|---|---|
| ||
<field> |
...
<dc-schema>dc</dc-schema> |
...
<dc-element>subject</dc-element> |
...
<dc-qualifier></dc-qualifier> |
...
<repeatable>true</repeatable> |
...
<label>Subject Keywords</label> |
...
<input-type>onebox</input-type> |
...
<hint>Enter appropriate subject keywords or phrases below.</hint> |
...
<required></required> |
...
<vocabulary>srsc</vocabulary> |
...
</field> |
The vocabulary element has an optional boolean attribute closed that can be used to force input only with the javascript Javascript of controlled-vocabulary add-on. The default behaviour (i.e. without this attribute) is as set closed="false". This allow the user also to enter the value in free way.
...
Here is a menu of types of common identifiers:
Code Block | ||
---|---|---|
| ||
<value-pairs value-pairs-name="common_identifiers" dc-term="identifier"> <pair> <displayed-value>Gov't Doc #</displayed-value> <stored-value>govdoc</stored-value> </pair> <pair> <displayed-value>URI</displayed-value> <stored-value>uri</stored-value> </pair> <pair> <displayed-value>ISBN</displayed-value> <stored-value>isbn</stored-value> </pair> </value-pairs> |
It generates the following HTML, which results in the menu widget below. (Note that there is no way to indicate a default choice in the custom input XML, so it cannot generate the HTML SELECTED attribute to mark one of the options as a pre-selected default.)
Code Block | ||
---|---|---|
| ||
<select name="identifier_qualifier_0"> <option VALUE="govdoc">Gov't Doc #</option> <option VALUE="uri">URI</option> <option VALUE="isbn">ISBN</option> </select> |
...
org.dspace.submit.AbstractProcessingStep
class. In this class add any processing which this step will perform.Code Block | ||
---|---|---|
| ||
<step> <processing-class>org.dspace.submit.step.MyNonInteractiveStep</processing-class> <workflow-editable>false</workflow-editable> </step> |
...