[Koha-bugs] [Bug 7345] Should be possible to export MARC records without private fields

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7345

--- Comment #29 from Jared Camins-Esakov <jcamins at cpbibliography.com> 2012-02-05 20:01:13 UTC ---
(In reply to comment #23)
> QA Comment:
> First, looks very good, but still have a few questions:
> 
> 1) Will a user know that marcstd means marc without private fields (9XX, X9X
> and XX9)? I did not realize it rightaway too ;) BTW Does not block this patch!

I still argue that this is primarily a developer-centric patch. It's needed so
that we can interoperate with the rest of the library world who do not speak
Koha. If you have a better idea for the label, please submit a follow-up patch
by all means. I do not have any better ideas. I would probably use jQuery to
call it "Raw MARC" because I don't see any use for the existing UTF-8 and
MARC-8 exports.

> 2) While testing it, I saw that the fields 952 and 999 are still included. Note
> that these are certainly no marc standard fields, so if any should be excluded,
> they should. Since your regex tests /9/, I do however not understand why they
> are still there. Do you? Note that a local field 942 and subfields 9 were
> correctly removed in my testing. Could you test this too? 

I did not have this problem, but your proposed fix worked, so I will attach the
revised patch momentarily.

> 3) I doubt if the encoding is 100% correct. When I opened the exported file in
> notepad, some characters with umlaut did not come up completely correct. But
> when copying them somewhere else, they were correct after all. When I commented
> the call to SetUTFFlag, the results in notepad were correct.
> Tested with title: Vorläufer, Schüler, Zeitgenossen.
> Please note that GetMarcBiblio is already calling _new_from_xml with a utf8
> parameter. 
> Also note that this remark also pertains to existing format utf8 in export
> scripts. (So formally, it could be a report on itself.) 
> Maybe Katrin can test it (probably she has the most experience with umlauts ;)

I think it is better not to fix this here, because I am not an expert in this,
and it would be better to have someone who understands the problem fix it in
both places than have me try to hack in a fix here.

> 4) Finally, elaborating on point 3: Not blocking this patch, but why would the
> marc2marc function not just demand a marc object (instead of optionally
> creating it). Note that the only call now already receives an object, created
> by GetMarcBiblio. And why not leave the call to as_usmarc to the export script,
> just as done in the case of format marc8, utf8 ?

I was using the existing marc2marc API, which specified that it should return
the results of as_usmarc.

> Changing status just to reflect need for some testing and answers..

-- 
Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.