[ https://jira.duraspace.org/browse/DS-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19017#action_19017 ]
Mark Diggory edited comment on DS-164 at 2/16/11 7:35 PM: ---------------------------------------------------------- Having participated in GSOC as a mentor for this project. I can comment that what the student created for inputforms was a functional solution that enabled support only for the forms. I challenge what we need here though, is an overall reconsideration of Item Content Modeling and Validation for DSpace 1. Of what value are the input-forms in their current design? We repeatedly find our team using inputforms as a form of pseudo schema for validation of user input. I would recommend that we need to separate the concepts of visualization of input forms from the validation of the assigned metadata, so that validation can be applied at the time of review and archiving (possibly a curation task) rather than as a Submission Activity 2. Of what value are the Controlled Vocabularies in their current form, again we in @mire tend to repurpose these files during import/export to validate and transform fields from other systems into expected CV values in DSpace. In recent projects, we have actually replaced the CV and InputForms with Authority Controls and more specifically, should we work to deprecate CV's and Value Lists in favor of the AUthority control abstraction? TBH, we all know these UI that utilize popup windows are rather antiquated. DSpace Needs a Validation "Engine" for Items that meets the following Criteria * Associates Validation Rules with DSpace Item "Content Types" independent of Submission * Can be used by InputForms and Submission to define appropriate forms. * Can be called after Packager and ItemImport tool processing to flag Items that are in an invalid state. * We can then associate those Content Types with Collections rather than InputForms. * Ideally this is considered part of the DSpace Domain Model and is persisted into either DB and/or Assetstore as a formal attribute of the Collection and/Community. * Ideally this is architected using the DSpace II Services Approach to allow its implementation to be an independent addon to the dspace core. * Ideally, this validation engine is content centric rather than collection centric, an this also pertains to the allowed metadata fields being associated with the Item Content Model, it would be best to consider it as an extension of the MetadataRegistry such that the Registry can be customized and made specific to different Item Types. was (Author: mdiggory): Having participated in GSOC as a mentor for this project. I can comment that what the student created for inputforms was a functional solution that enabled support only for the forms. I challenge what we need here though, is an overall reconsideration of Item Content Modeling and Validation for DSpace # Of what value are the input-forms in their current design? We repeatedly find our team using inputforms as a form of pseudo schema for validation of user input. I would recommend that we need to separate the concepts of visualization of input forms from the validation of the assigned metadata, so that validation can be applied at the time of review and archiving (possibly a curation task) rather than as a Submission Activity # Of what value are the Controlled Vocabularies in their current form, again we in @mire tend to repurpose these files during import/export to validate and transform fields from other systems into expected CV values in DSpace. In recent projects, we have actually replaced the CV and InputForms with Authority Controls and more specifically, should we work to deprecate CV's and Value Lists in favor of the AUthority control abstraction? TBH, we all know these UI that utilize popup windows are rather antiquated. DSpace Needs a Validation "Engine" for Items that meets the following Criteria * Associates Validation Rules with DSpace Item "Content Types" independent of Submission * Can be used by InputForms and Submission to define appropriate forms. * Can be called after Packager and ItemImport tool processing to flag Items that are in an invalid state. * We can then associate those Content Types with Collections rather than InputForms. * Ideally this is considered part of the DSpace Domain Model and is persisted into either DB and/or Assetstore as a formal attribute of the Collection and/Community. * Ideally this is architected using the DSpace II Services Approach to allow its implementation to be an independent addon to the dspace core. > Deposit Interface > ----------------- > > Key: DS-164 > URL: https://jira.duraspace.org/browse/DS-164 > Project: DSpace > Issue Type: New Feature > Reporter: Charles Kiplagat > Priority: Major > > Suggestions included: a web interface for altering input-forms.xml, being > able to select an input form "on the fly" based on the type of item being > deposited, a web interface to the Configurable Submission System, eliminating > the need to restart the server after changes to input-forms.xml and the > Configurable Submission System, allowing more configuration (e.g. > input-forms.xml, Configurable Submission) and command-line actions (e.g. > batch imports) to be pushed down to community and collection administrators, > allowing metadata specific to an eperson (e.g. name, metadata fields to > exclude) to be stored in that eperson's profile, It was noted that the lack > of a web interface to many DSpace configuration files means that repository > managers who are not also systems administrators may not be able to configure > their installations fully. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel