>> Actually -- I'd disagree because that is a very narrow view of the
>> specification.  When validating MARC, I'd take the approach to validate
>> structure (which allows you to then read any MARC format) -- then use a
>> separate process for validating content of fields, which in my opinion,
>> is more open to interpretation based on system usage of the data.

Wait, so is there any formal specification of "validity" that you can 
look at to determine your definition of "validity", or it's just "well, 
if I can recover it into useful data, using my own algorithms"

I think we computer programmers are really better-served by reserving 
the notion of "validity" for things specified by formal specifications 
-- as we normally do, talking about any other data format.   And the 
only formal specifications I can find for Marc21 say that leader bytes 
20-23 should be 4500. (Not true of Marc in general just Marc21).

Now it may very well be (is!) true that the library community with Marc 
have been in the practice of tolerating "working" Marc that is NOT valid 
according to any specification.   So, sure, we may need to write 
software to take account of that sordid history. But I think it IS a 
sordid history -- not having a specification to ensure validity makes it 
VERY hard to write any new software that recognizes what you expect it 
to be recognize, because what you expect it to recognize isn't formally 
specified anywhere. It's a problem.  We shouldn't try to hide the 
problem in our discussions by using the word "valid" to mean something 
different than we use it for any modern data format. "valid" only has a 
meaning when you're talking about valid according to some specific 
specification.