Bug 14645 - Koha::RecordProcessor should deal with Koha::MetadataRecord objects
Summary: Koha::RecordProcessor should deal with Koha::MetadataRecord objects
Status: ASSIGNED
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Tomás Cohen Arazi
QA Contact: Testopia
URL:
Keywords:
Depends on: 14639 14646
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-04 16:22 UTC by Tomás Cohen Arazi
Modified: 2016-06-06 05:09 UTC (History)
4 users (show)

See Also:
Change sponsored?: Seeking cosponsors
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomás Cohen Arazi 2015-08-04 16:22:24 UTC
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.
Comment 1 Héctor Eduardo Castro Avalos 2015-08-27 16:36:50 UTC
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>
Comment 2 Héctor Eduardo Castro Avalos 2015-08-27 16:39:52 UTC
A BIBFRAME bug has been filed by Nicole at <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14239>
Comment 3 Héctor Eduardo Castro Avalos 2015-08-27 16:48:23 UTC
Magnus opened up a bug about serialization too. <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7236>
Comment 4 David Cook 2016-06-06 05:09:23 UTC
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...