Comment 3 for bug 1477252

As you point out, right now, we use the type+blvl to decide how to read the 006 (inherited from the way we decide on the 008), but we otherwise have all the infrastructure to properly define the positions. I think all we need is to map the value in 006/00 to the type map (BKS,COM, etc) when pulling info from the 006, and everything will just work.

Looking at https://www.oclc.org/bibformats/en/fixedfield/006.html (yes, it's OCLC docs, but they use the same mnemonics we do ... because of reasons) we see that it should be trivial to "switch" the contextual record type when evaluating the 006.

I don't think this looks like a lot of code, really. In fact, because 's' is the old, deprecated code for SER in the LDR, and is the correct value for SER in the 006/00, we can just change the config.marc21_rec_type_map entry of type_val to be 'as'. The rest of the type_val values in that table already describe the correct mapping for the 006/00. We will need an order-by on the code column to make sure that 006/00=a is looked up correctly, but bad specs are bad. This has the benefit of always working for the record-wide value, and even expanding the reach to catch old, crufty records that use the deprecated 's' value.

We could make it config-dependent by adding a table that says "these tags carries their own record type value; also, use (or don't use) the type_val and/or blvl_val fields", and creating a simple function akin to vandelay.marc21_record_type(). But, I don't think that's necessary, really. We already embed lots of marc21 info in stored proc logic, and if we continue to cordon of that mess into functions with "marc21" in their names then we're no worse off WRT alternate formats down the road. (Also, same goes for the order-by stuff I mentioned above). We just see we're dealing with an 006 and do the right thing...

Thoughts?