Koha::RecordProcessor is designed to apply the right filters to records, depending on the declared schema. This means that a Dummy filter named like this: Koha::Filter::$schema::Dummy is going to be applied to records, based on the $schema param. It is a smart design, but in order to use this more broadly we need to remove the ambiguity between the metadata schema (for example: MARC21, UNIMARC, DublinCore, DarwinCore, MODS, etc) and the serialization format (for example USMARC/ISO, XML, JSON, etc). This will let us make better decisions on how to apply filters to records, and also provide us with enhanced flexibility on writing filters, because MARC is not enough information, you know? :-D With that in mind, I proposed extending the Koha::MetadataRecord object (I even included the record id, which could be retrieved from the search engine so less useless processing) on bug 14639, and now propose we make Koha::RecordProcessor work on Koha::MetadataRecord objects instead of just MARC::Record objects.
Hi, Tomás, I'm working in Dublin Core with serialization formats in bug <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13642>. With a DublinCore.pm module, my question is if I go in the right way and can continue with this bug or I can help you in something in this new bug? Right now i'll upgrade the code for Dublin Core since some new modules had been added to Koha. Regards PS: Also I want to start working with the RDA Registry metadata <http://www.rdaregistry.info/> to serialize in constrained and unconstrained metadata. I will start to work with mapping MARC with BIBFRAME <http://bibframe.org/> in the near future. I filed a new bug for RDA Registry at <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14745>
A BIBFRAME bug has been filed by Nicole at <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14239>
Magnus opened up a bug about serialization too. <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7236>
I wonder too if we could implement a Koha::Filter::XML::XSLT class. Unfortunately, since XML::LibXSLT returns a new XML::LibXML::Document object and Koha::RecordProcessor returns the original object, we'd need to do something like this to make that work: sub filter { my $self = shift; my $record = shift; my $xslt = XML::LibXSLT->new(); my $style_doc = XML::LibXML->load_xml(location => "path_to_xslt.xsl"); my $stylesheet = $xslt->parse_stylesheet($style_doc); my $filtered_record = $stylesheet->transform($record); my $new_root = $filtered_record->documentElement; my $newest = $new_root->cloneNode(1); $record->removeChildNodes(); $record->setDocumentElement($newest); return $record; } I imagine cloneNode isn't very efficient, although I don't know the specifics. I thought about implementing this class for my work on bug 10662, but I think I'll just write my own few lines for now...