[Koha-bugs] [Bug 12477] We need better ways to manage MARC Frameworks

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

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

--- Comment #5 from Bernardo Gonzalez Kriegel <bgkriegel at gmail.com> ---
(In reply to David Cook from comment #3)
> Sorry for my delayed response! Competing priorities...
No problem :) This task will take some time

> I'm happy to go with XML. I suppose my only reservations are about the
> brittleness of XML and processing time involved in parsing a huge XML file.
> I suppose the brittleness shouldn't be a factor...we could validate the XML
> before committing it and parsing errors are very loud so there probably is
> no danger there. As for processing time...it's not like installing or
> updating frameworks would be a frequent operation so lengthy processing time
> might not matter (if it is even a thing).

I used XML::Simple to load and build sql files from the attached examples. It
does not take to much time, and anyway is something to use at install time or
when updating frameworks, not frequent tasks :)

> 
> Now that I think about it... are "liblibrarian" and "libopac" the only
> fields that need to be translated? 

Yes, and in EN and ES they are the same text. I wonder if there are libraries
using different labels for opac/staff
In french UNIMARC frameworks I found that libopac is shortened or empty in most
cases.

> marc_tag_structure:
> 1) MARC: tagfield, liblibrarian, libopac, repeatable
> 2) Koha: mandatory, authorised_value, frameworkcode

In this case authorised_value... is not used, or can't be used. FW editor
allows to set this to an authorised value, supposedly to list allowed values
for indicators, but this is not used on editor (there is another bug that
mentions this) 

> marc_subfield_structure:
> 1) MARC: tagfield, tagsubfield, liblibrarian, libopac, repeatable, maxlength
> 2) Koha: mandatory, kohafield, tab, authorised_value, authtypecode,
> value_builder, isurl, hidden, frameworkcode, seealso, link, defaultvalue

In this case seealso is not used anymore (or that is implied by
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6007#c3)

> 
> Oooh. Brain wave...we could use XSLT! We'd have a XML file containing the
> MARC specification data. Then we pass that through an XSLT which adds the
> relevant "Koha" data.
> 
> Think about it...in most cases those "Koha" fields are "null" or "". The
> most important fields are probably "tab" and "hidden". If we use defaults
> for most cases, but define exceptions in the XSLT on a field/subfield and
> framework basis...that would be much easier to maintain!
> 
> I don't know if that paragraph makes sense to anyone else...but I like this
> idea. It's easier to maintain exceptions rather than a whole comprehensive
> list, which can be dynamically generated.
> 
> Bernardo, if you could post an up-to-date XML file with that MARC data I
> mentioned above, I would be willing to take a look at creating a XSLT that
> adds the relevant Koha data and produces a final "Koha MARC framework" XML
> document in the end.
> 

On the attached file there are XMLs for tags and subtags, with/without Koha
proper fields. They are at least well formed (xmllint --noout file.xml)

There's another thing to take into account: when MySQL 5.6 arrives to new
debian/ubuntu versions, we'll have a problem. 5.6 client complains a lot to be
used on CLI with password as argument, so Koha installer fails miserably
because it uses 'mysql' command to load mandatory/optional values in database.
Another reason to find other way.

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