jorol
commented
2 years ago Thanks for your comments.
... should be fixed also for the other modules before a release?
As these special characters comply with the MARC standard and occur in my data, I would say yes.
What should an importer do when a subfield is found that doesn't match the allowed subfields
I don't think we have currently a general rule for that. Some will accept those fields (XML), some will ignore those fields (Line) and give a warning,
I would wish:
- default: ignore invalid (sub)fields and throw warnings
- add an option to keep invalid (sub)fields
... but I really don't want to touch MARC::File. Perhaps the easiest solution is to allow special characters in Catmandu::Exporter::MARC::XML and Catmandu::Exporter::MARC::ALEPHSEQ for a consistent behavior, as these are under our source control. We should allow any subfield codes, like MARC::File or yaz-marcdump, and not restrict them to the codes documented in the MARC standard. I would adapt Catmandu::Importer::MARC::Line.
MARC files could/should be validated with MARC::Schema, which will throw warnings for these invalid (sub)fields.
phochste
MARC 21 allows some special (!"#$%&'()*+'-./:;<=>) characters as subfield codes in local defined fields, see https://www.loc.gov/marc/96principl.html#eight 8.4.2.3.. I've fixed Catmandu::Importer::MARC::Line and included these codes.