Closed Daniel-KM closed 9 years ago
I think I'm going to move to a filter like this, but extend it slightly so it's where metadata prefixes and schemas and such, the various data required by the plugin, are all provided in the filter. Right now those things are loaded in a somewhat awkward way out of each class. Instead of living in a nonstandard "metadata" folder, the formats would be located in the libraries folder at the standard location and be autoloaded rather than explicitly included.
This "everything in the filter" method is basically what's used for a similar purpose in Exhibit Builder 3, and it seems to work well.
I'd have to think over whether it makes more sense to have a QDC format live in DublinCoreExtended or in the Repository. Under the new filter-based system, the plugin would just statically define the default pre-filtering set of formats, and it would be easy in that system to have a QDC format within the Repository itself, but have it only be included if Dublin Core Extended is installed.
I've been mulling the filtering change for a little while. I'll try to get the changes up relatively soon.
Hi,
Ok.
Note that a filter is needed somewhere to modify xml: French National Library wants a field dc:relation
for the default thumbnail like that: vignette : http://example.com/files/thumbnails/mythumbnail.jpg
and I don't want to add such data in the record, so I need to modify the processed xml.
Sincerely,
Daniel Berthereau Infodoc & Knowledge management
Okay, I've done the bulk of the initial refactoring I was intending to get to.
As part of this, note the 'oai_pmh_repository_metadata_formats'
filter and the new array-based format for specifying a metadata format.
Hi,
I updated the DublinCoreExtended pull request to comply with the new format.
Sincerely,
Daniel Berthereau Infodoc & Knowledge management
Hi,
I added a filter to facilitate new metadata formats. This is needed to expose Qualified Dublin Core with the plugin Dublin Core Extended.
Sincerely,
Daniel Berthereau Infodoc & Knowledge management