[Koha-bugs] [Bug 11096] Koha cannot retrieve big records from Zebra

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11096

--- Comment #88 from David Cook <dcook at prosentient.com.au> ---
(In reply to Wolfram Schneider from comment #87)
> If marcxml + XSLT is to slow, then you might try to use turbomarc instead.
> It's a smaller XML for MARC and much faster to work with in XSLT.

http://www.indexdata.com/news/2014/06/turbomarc-faster-xml-marc-records

I can't imagine us using Turbomarc for anything but indexing, but then we'd
lose time converting from MARCXML to/from Turbomarc as well...

Personally, I like the idea of using our own intermediary format which can be
exported as MARCXML (or Turbomarc or whatever), although I suppose the problem
with that is our intermediary format could grow and then not be perfectly
exportable as MARCXML, which means lost data for users, although perhaps not a
big problem if you provide easy ways of customizing exports, so people could
export into fields like 9AA (see
http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd for valid tag
ranges) and then massage from there...

The intermediary format could also help us move away from XML and Zebra anyway,
so that we could use any indexing engine like Solr, ElasticSearch, or whatever.

Really, we only need MARC(XML) for interchange.

Consider this:

"2.1. The MARC 21 formats are communication formats, primarily designed to
provide specifications for the exchange of bibliographic and related
information between systems. They are widely used in a variety of exchange and
processing environments. As communication formats, they do not mandate internal
storage or display formats to be used by individual systems."
(https://www.loc.gov/marc/96principl.html)

I suppose my argument could be used to support turbomarc as well... although I
don't know how well turbomarc would work itself as a format (besides the
performance improvement for XSL transformations).

I suppose another argument against changing from MARC(XML) could be the need to
provide sufficient mechanisms for using AACR2 and RDA. MARC pretty much already
has that built in, but then it also has limitations. 

Anyway, that's all rather tangential.

I don't know about turbomarc. It seems like it would be a bit painful to work
with :/.

-- 
You are receiving this mail because:
You are watching all bug changes.