 |
 |
> Well, the problem is when the original Marc4J author took the spec at it's > word, and actually _acted upon_ the '4' and the '5', changing file semantics > if they were different, and throwing an exception if it was a non-digit. > At least the author actually used the values rather than checking to see if a 4 or 5 were there. I still don't see what the point of looking for a 0 in an undefined field would be. I'm wondering what kind of nut job would write this into the standard, but that's not the author's problem. > Do you think he got it wrong? How was he supposed to know he got it wrong, > he wrote to the spec and took it at it's word. Are you SURE there aren't any > Marc formats other than Marc21 out there that actually do use these bytes > with their intended meaning, instead of fixing them? I wouldn't call it wrong -- the spec is a logical point of departure. MARC21 derives from an ISO standard that does not use those character positions and which otherwise requires the same data layout, but the author wouldn't necessarily know that. Standards have something in common with laws in that how they are used in the real world is as or more important than what is actually defined -- what's written and what's done in practice can be very different. Everyone here who has parsed catalog data who has done an ILS migration knows better than to just think for a second that fields can be assumed to be used as defined except for very basic stuff. > How was the Marc4J author supposed to be sure of that, or even guess it > might be the case, and know he'd be serving users better by ignoring the > spec here instead of following it? There might not have been a good way to know. With data, one thing you always want to do is ask a bunch of people who work with it all the time about anomalies in the wild. Many great works of fiction masquerade as documents which supposedly describe reality. > Ie: I _thought_ I was writing only for Marc21, but then it turns out I've > got to accept records from Outer Weirdistan that are a kind of legal Marc > that actually uses those bytes for their intended meaning.... Any such MARC as it would be noncompliant with the ISO standard from which MARC21 hails. If working from the MARC21 standard and weird records are in question, there would be a greater chance of choking on nonumeric tags as those are allowed by the ISO standard. Ignoring that MARC21 would need to be redefined to be able to take on other values, one can safely conclude that such a redefinition could only be written by totally deranged individuals. Values lower than 4 and 5 respectively would limit record length to the point little or no data could be stored, and greater values would be completely nonsensical as the MARC record length limitation would mean that the extra space allocated by the digits could only contain zeros. In any case, MARC is a legacy standard from the 60's. The chances of new flavors emerging are dismal at best. > Again, I realize in the actual environment we've got, this is not a luxury > we have. But it's a fault, not a benefit, to have lots of software > everywhere behaving in non-compliant ways and creating invalid (according to > the spec!) data. > Creating is another matter entirely. Since we can control what we create ourselves, we make things a little better every time we make things comformant. However, we can't control what others do and being able to read everything is useful, including stuff created using tools/processes that aren't up to scratch. kyle