Not sure what the details of our issue was on Monday -- but we do have 
records that are supposedly encoded in UTF-8, but nonetheless contain 
invalid characters.

I think raising an exception is fine, as long as we can still continue 
to walk the records with the reader.  The right thing for application 
code to do then would be to catch the exception, log it, and continue to 
the next record.  The more information in the exception, the better.

-- Scott

> I am not sure how you ran into this problem on Monday with ruby-marc,
> since ruby-marc doesn't currently handle Marc8 conversion to UTF-8 at
> all -- how could you have run into a problem with Marc8 to UTF8
> conversion?  But that is what I am adding.
>
> But yeah, using a preprocessor is certainly one option, that will not be
> taken away from people. Although hopefully adding Marc8->UTF8 conversion
> to ruby-marc might remove the need for a preprocessor in many cases.
>
> So again, we have a bit of a paradox, that I have in my own head too.
> Scot suggests that "In either case, what we DON'T want is to halt the
> processing altogether."  And yet, still, that the default behavior
> should be raising an exception -- that, is halting processing
> altogether, right?
>
> So hardly anyone hardly ever is going to want the default behavior, but
> everyone thinks it should be default anyway, to force people to realize
> what they're doing? I am not entirely objecting to that -- it's why I
> brought it up here, but it does seem odd, doesn't it?  To say something
> should be default that hardly anyone hardly ever will want?
>
>
> On 11/20/13 10:10 AM, Scott Prater wrote:
>> We run into this problem fairly regularly, and in fact, ran into it on
>> Monday with ruby-marc.
>>
>> The way we've traditionally handled it is to put our marc stream through
>> a cleanup preprocessor before passing it off to a marc parser (ruby marc
>> or marc4j).
>>
>> The preprocessor can do one of two things:
>>
>>    1)  Skip the bad record in the marc stream and move on; or
>>    2)  Substitute the bad characters with some default character, and
>> write it out.
>>
>> In both cases we log the error as a warning, and include a byte offset
>> where the bad character occurs, and the record ID, if possible.  This
>> allows us to go back and fix the errors in a stream in a batch;
>> generally, the bad encoding errors fall into four or five common errors
>> (cutting and pasting data from Windows is a typical cause).
>>
>> In either case, what we DON'T want is to halt the processing altogether.
>>   Generally, we're dealing with thousands, sometimes millions, of MARC
>> records in a stream;  it's very frustrating to get halfway through the
>> stream, then have the parser throw an exception and halt.  Halting the
>> processing should be the strategy of last resort, to be called only when
>> the stream has become so corrupted you can't go on to the next record.
>>
>> I'd want the default to be option 1.  Let the user determine what
>> changes need to be made to the data;  the parser's job is to parse, not
>> infer and create.  Overwriting data could also lead to the misperception
>> that everything is okay, when it really isn't.
>>
>> -- Scott
>>
>> On 11/20/2013 08:32 AM, Jon Stroop wrote:
>>> Coming from nowhere on this...is there a place where it would be
>>> convenient to flag which behavior the user (of the library) wants? I
>>> think you're correct that most of the time you'd just want to blow
>>> through it (or replace it), but for the situation where this isn't the
>>> case, I think the Right Thing to do is raise the exception. I don't
>>> think you would want to bury it in some assumption made internal to the
>>> library unless that assumption can be turned off.
>>>
>>> -Jon
>>>
>>>
>>> On 11/19/2013 07:51 PM, Jonathan Rochkind wrote:
>>>> ruby-marc users, a question.
>>>>
>>>> I am working on some Marc8 to UTF-8 conversion for ruby-marc.
>>>>
>>>> Sometimes, what appears to be an illegal byte will appear in the Marc8
>>>> input, and it can not be converted to UTF8.
>>>>
>>>> The software will support two alternatives when this happens: 1)
>>>> Raising an exception. 2) Replacing the illegal byte with a replacement
>>>> char and/or omitting it.
>>>>
>>>> I feel like most of the time, users are going to want #2.  I know
>>>> that's what I'm going to want nearly all the time.
>>>>
>>>> Yet, still, I am feeling uncertain whether that should be the default.
>>>> Which should be the default behavior, #1 or #2?  If most people most
>>>> of the time are going to want #2 (is this true?), then should that be
>>>> the default behavior?   Or should #1 still be the default behavior,
>>>> because by default bad input should raise, not be silently recovered
>>>> from, even though most people most of the time won't want that, heh.
>>>>
>>>> Jonathan
>>
>>


-- 
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
[log in to unmask]
5-5415