 |
 |
> > So would you use the Marc header payload instead? > Or you're just saying you wouldn't trust _any_ encoding declerations you > find anywhere? > This. The short version is that too many vendors and systems just supply some value without making sure that's what they're spitting out. I haven't had to mess with this stuff for a few years, so I'm hoping Terry Reese weighs in on this conversation -- he has a lot of experience dealing with encoding headaches. However, the bottom line is that the most reliable method is to use heuristics to detect what's going on. Yeah, that totally kills the point of listing encodings in first place, but just as is the case with any unreliably used data point, it's all GIGO. When writing a library to handle marc, I think the base line should be > making it do the official legal standards-complaint right thing. Extra > heuristics to deal with invalid data can be added on top. > I'm hoping things have improved, but if heuristics are more reliable than reading the right areas of the record, you have to ignore what's there (which makes even reading it pointless). I do think there is value in encouraging vendors to actually pay attention to this stuff as such basic screwups undermine both the the credibility of the data source and the service that depends on the data. > But my trouble here is I can't even figure out what the official legal > standards-compliant thing is. > > Maybe that's becuase the MarcXML standard simply doesn't address it, and > it's all implementation dependent. sigh. > > The problem is how the XML documents own char encoding is supposed to > interact with the MARC header; especially because there's no way to put > Marc8 in an XML char encoding doctype (is there?); and whether encodings > other than Marc8 or UTF8 are legal in MarcXML, even though they aren't in > MARC ISO binary. > > I think the answer might be "nobody knows, and there is no standard right > way to do it." Which is unfortunate. > A good summary of the situation as I understand it. kyle -- ---------------------------------------------------------- Kyle Banerjee Digital Services Program Manager Orbis Cascade Alliance [log in to unmask] / 503.999.9787