Hi all, In an effort to put my money where my mouth is regarding my remarks about MARC-in-JSON vis-a-vis a Pairs version, I've uploaded some modules under the MARC::Utils namespace:
http://search.cpan.org/dist/MARC-Utils-MARC2MARC_in_JSON/ http://search.cpan.org/dist/MARC-Utils-MARC2Pairs/ http://search.cpan.org/dist/MARC-Utils-MARC2Ini/ The first will convert from a MARC::Record object to a MARC-in-JSON data structure and back. (Note that it doesn't actually convert to JSON -- but that's easy to do yourself.) The second will convert to and from a Data::Pairs structure, and the third, to and from an Ini file string. I'm not sure what your interface for MARC-in-JSON in MARC::Record will look like, so maybe this is in conflict with that -- or maybe not. Anyway, my reasoning is to provide more than one way to represent MARC data outside of the usual, but still be easy to convert back. My motivation is primarily to be able to present a human-readable/editable version of MARC data that I can then read back and process. I've already talked about the "pairs of pairs" idea that I think presents a nice interface in YAML. The MARC2Ini introduces another idea: one can faithfully represent MARC data using an Ini file format. The caveat is that you must process this as if it were a "pairs of pairs" representation. What I mean is that most Ini file processing will treat this: [600] a = Judith Smith [610] a = Andrew Jackson [600] a = Bill Wyatt the same as this: [600] a = Judith Smith a = Bill Wyatt [610] a = Andrew Jackson The module I uploaded does not. Since it's easier to explain an idea with a working example, I thought I'd upload these modules to show what I'm thinking of. Error checking and tests are sparse yet. They assume they're getting good data. I have no plans to appropriate MARC::Utils itself, i.e., I won't create a MARC/Utils.pm file (but I can imagine other from/to variations, e.g., MARC::Utils::MARC_in_JSON2Ini). But I'm also not wedded to having these in the MARC::Utils namespace. If the modules look at all useful, I'd be glad to hear suggestions for a better location and/or for better names. Regards, Brad
