......  Maybe we have different understandings of "valid".
>
> If leader bytes 20-23 are not "4500", I suggest that is _by definition_ not
> a "valid" Marc21 file. It violates the Marc21 specification.
>
> Now, they may still be _usable_, by software that ignores these bytes
> anyway or works around them. We definitely have a lot of software that does
> that.
>
> Which can end up causing problems that remind me of very analagous problems
> caused by the early days of web browsers that felt like being 'tolerant' of
> bad data. "My html works in every web brower BUT this one, why not? Oh,
> becuase that's the only one that actually followed the standard, oops."
>

There is some question as to what value there is in validating fields that
have no meaning by definition. What benefit does validating an undefined
value have other than create an opportunity to break things and slow the
process down just a little? The entire concept of an invalid entry in an
undefined field (e.g byte 23) is oxymoronic.

I'd go so far as to question the value of validating redundant data that
theoretically has meaning but which are never supposed to vary. The 4 and
the 5 simply repeat what is already known about the structure of the MARC
record. Choking on stuff like this is like having a web browser ask you want
to do with a page because it lacks a document type declaration.

Garbage data is the reality, so having parsers stop when they encounter data
they don't actually need unnecessarily complicates things. That kind of
stuff should generate a warning at worst.

kyle