http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12477 --- Comment #5 from Bernardo Gonzalez Kriegel <bgkriegel@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.