http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12477
--- Comment #5 from Bernardo Gonzalez Kriegel <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
