Enticed away by the snappier titled, MARC Must Die, I temporarily set aside the somewhat dry, What is a Marc Record, and Why is it Important? This was a mistake.
Initially, I had thought that Marc seemed unnecessarily organized, with its pre-record record for its actual record (the three parts of Leader, Directory, and 008 field) and trying to keep the tag codes separate from the parallel tag codes, or even the indicators in my head made it slow reading. I assumed this was due to my lack of experience. Then, with MARC Must Die I felt vindicated – my raised eyebrows were echoed by the more experienced opinion of an actual legitimate librarian. Coming back to the original article then, it was especially difficult to read through and retain information without the constant background noise of my growing – well, disdain is too strong a word, but you get the idea. The one line that really sold me on the idea that MARC Must Die is the following, “By its very nature, Marc is flat, whereas a table of contents is hierarchical. This would be a breeze in XML.” I see the intention of interoperability between MARC hosting sites, with libraries exchanging cataloging data and having an (arguably) coherent streamlined process of encoding bibliographic data. Still, it doesn’t seem as flexible once you actually get into a single record.
Tennant goes on to suggest checking out the MarcXML website. When you get there, you’ll see its latest “News & Updates” is from 2002. It seems there’s been little progress made towards Tennant’s ideal. I sought some sort of confirmation from a cataloging librarian I know who says, even at her non-library publishing house cataloging job, she uses some sort of MARC based system for everything. I don’t know a ton about it, but I wonder if BibFrame is a sturdier replacement option than MARCXML?