Hi Jay, Il giorno gio, 10/06/2010 alle 22.39 +0200, Jay Luker ha scritto: > I think regardless of whether you decide to make use of pymarc in the > future, the lack of a leader is the main compatibility blocker. There > are some parsers/converters in the wild for aleph sequential format > but they too expect a leader value.
There is indeed a Savannah task still opened to have Invenio to support the leader: :-) <https://savannah.cern.ch/task/?4787> Currently when you use xmlmarc2textmarc utility, and you export to Aleph, a dummy leader is generated, which proved to be enough for Aleph. I am currently not an expert on the leader subject, but to me it seems that the leader makes sense mostly in the MARC21 binary format, and when dealing with plain library records. And it exists in MARCXML just as a conversion consequence. Is this correct? Proof is that Invenio can do powerful and extremely flexible things without any need for the leader. In particular if Invenio has to support the leader in MARCXML how can we map its workflows with the rigid schema of the leader: Also what is the meaning of certain bytes of the leader in MARCXML: (from <http://www.loc.gov/marc/bibliographic/bdleader.html>): [...] Character Positions 00-04 - Record length [...] 12-16 - Base address of data [...] In the end, probably the best thing is still to put a fake leader like xmlmarc2textmarc currently does, with the most neutral values. It is true that, on the other hand, when Invenio records have been imported from original MARC21 or from MARCXML with a leader, Invenio should not throw away such information. What do you think? Cheers, Sam
