>> 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