 |
 |
On 4/6/2011 2:43 PM, William Denton wrote: > > "Validity" does mean something definite ... but Postel's Law is a good > guideline, especially with the swamp of bad MARC, old MARC, alternate > MARC, that's out there. Valid MARC is valid MARC, but if---for the sake > of file and its magic---we can identify technically invalid but still > usable MARC, that's good. Hmm, accept in the case of Web Browsers, I think general consensus is Postel's law was not helpful. These days, most people seem to think that having different browsers be tolerant of invalid data in different ways was actually harmful rather than helpful to inter-operability (which is theoretically the goal of Postel's law), and that's not what people do anymore in web browser land, at least not to the extremes they used to do it. So Postel's Law may not be a universal. Although marc data may or may not be analagous to a web browser/html. :) It doesn't _really_ matter, cause we're stuck with the legacy we're stuck with, there's no changing it now. But there are real world negative consequences to it, some of which I've tried to explain in previous messages. (And still don't call it "validity" if it's not please! But yes, sometimes insisting on strict validity is not the appropriate solution). Also note that assuming that byte 20-21 is "45" even when it's something else is possibly not something Postel would accept as an application of his law -- unless you document your software specifically as working only with Marc21, and not any Marc. [Postel's Law: "Be conservative in what you send; be liberal in what you accept." http://en.wikipedia.org/wiki/Robustness_principle . That wiki page also notes the general category of downside in following Postel's law, which is what was encountered with HTML, and which _I've_ encountered with MARC: "For example, a defective implementation that sends non-conforming messages might be used only with implementations that tolerate those deviations from the specification until, possibly several years later, it is connected with a less tolerant application that rejects its messages. In such a situation, identifying the problem is often difficult, and deploying a solution can be costly. " Yes, identifying the problem and deploying the solution was costly, in my MARC case, although it definitely could have been worse. ]