Make encode-marc21 validation optional or optionally less strict

[TobiasNx]

Currently the marc encoder only serializes to marc21 if a lot of validations are true.

Hbz/Verbundgruppe has a use case where for the it is more important to change the form from marcxml to marc21 than having valid marc21.

The transformation breaks if the data is not valid at the moment.

I therefore suggest to make the validation of the leader and controllfields optional.

[TobiasNx]

Also the marcxml schema is less strict than the marc21 specification from LOC:

https://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd

Leader has to have 24 characters but the regex is the following: <xsd:pattern value="[\d ]{5}[\dA-Za-z ]{1}[\dA-Za-z]{1}[\dA-Za-z ]{3}(2| )(2| )[\d ]{5}[\dA-Za-z ]{3}(4500| )"/>

[TobiasNx]

I would suggest an option | handle-marcxml(validate="false")

[dr0i]

you mean encode-marc21 ? And I would opt for a more precise option name, like:
encode-marc21(validateLeader="false").

[TobiasNx]

you mean encode-marc21 ? And I would opt for a more precise option name, like: encode-marc21(validateLeader="false").

you are correct! is there any additional metadata beside the leader that is validated?

[dr0i]

Well, yes - somehow the input must be structurally representable as MARC...
Read the description section, e.g.

Top-level literals are encoded as reference fields. Their name must

• match the requirements for reference field tags in ISO 2709:2008 records.
  ...
  

  metafacture-core/metafacture-biblio/src/main/java/org/metafacture/biblio/marc21/Marc21Encoder.java

  Line 34 in 922dd0d

  * Encodes a stream in MARC21 format.

Of course we could also ignore that. Sparks the question: When is MARC MARC and when it isn't anymore?