[
https://jira.duraspace.org/browse/DS-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24894#comment-24894
]
Mark Diggory commented on DS-1173:
----------------------------------
I would recommend that we want to have separate and clearly defined code for
MetadataImport and MetadataSchema registry updates.
I also dislike binding all "concepts" of a registry into one update codebase,
I feel MetadataImport, BitstreamFormats and Metadata Registries should be
treated conceptually separate.
Likewise, wouldn't it be more wise to select some common DDL language for
populating database tables that can be used across various DSpace tables rather
than writing custom xml formats and inflexible parsing procedures syntaxes for
this stuff?
Finally, I hope we can see some better designs for the metadata registry not
get bound up in complying with code or xml formats that are here to load them.
> registry loader does not employ the more flexible MetadataImporter
> ------------------------------------------------------------------
>
> Key: DS-1173
> URL: https://jira.duraspace.org/browse/DS-1173
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.8.2
> Environment: All
> Reporter: Richard Jones
>
> There is a registry loader command:
> ./dspace load-registry -dc [file path]
> which loads dspace metadata registry format files into the registry. There
> is a superior implementation of the metadata registry loader in
> org.dspace.administer.MetadataImporter, and the registry loader does not use
> this, but replicates old functionality which the MetadataImporter was written
> to replace. The current registry loader, for example, dies if schema or
> metadata entries are repeated, while the MetadataImporter simply skips
> repeated options.
> This is useful if you have a number of applications for your DSpace instance,
> and metadata schemas for each of these applications (e.g. theses management,
> research information data feeds, etc). With the MetadataImporter you can
> maintain separate complete schemas for each application, load them all
> sequentially (on top of the default dspace registry), and be sure that your
> resulting registry is the super-set of all required metadata. With the
> existing registry loader you must maintain exactly one de-duplicated schema
> which covers all possible uses, which is inconvenient.
> The ideal thing to do would be to wire the registry loader into the
> MetadataImporter
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
