http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12477
--- Comment #3 from David Cook <dc...@prosentient.com.au> --- Sorry for my delayed response! Competing priorities... (In reply to Bernardo Gonzalez Kriegel from comment #2) > If the field/subfield is missing, adding it as 'hidden' does not affect > present fw. And you can always preserve liblibrarian/libopac as they are... > except when they change, as in last update (Bug 12435, bib 347$f). > > As in other updates I proposed, I never try to update existing fw, for > the problems that you commented. > It's a tough one. I'm thinking that there should be some mechanism for updating an existing framework. It might need to be triggered by library staff, so that they understand what is being updated, but there should be something there. Otherwise, if you're on Koha for a long time, you'll get stale frameworks. Since Koha used outdated frameworks for a long time, it's possible (re: probable) that many Koha users are using very out of date frameworks that need to be updated in a user-friendly way. > And there is a bigger problem: translations > I haven't done anything with translations, but I'm in favour of anything that makes translations easier. > > We could actually just store this MARC-specific data in the YAML file, and > > then build the Default and other Custom frameworks based on a Perl script, > > which would probably be easier to maintain than the SQL that we maintain > > now. > > If it's agreed to store fw in other format, I propose we use XML (example > attached). And the reason is translations. > 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). > We need a way to ease the translation of all configuration and sample data > we have as SQL. I'm working intermittently on this, now I'm stuck with > sample notices, but have worked out most sql files as XML and a script to > build sql from them. And unless we propose another way, we need translated > sql files at web install time. It's not practical that each language other > than english have a lang dir commited to git. > Now that I think about it... are "liblibrarian" and "libopac" the only fields that need to be translated? > Talking again about frameworks, Bug 10963 is waiting for a review :) It looks good! I'll have to look at it soon. -- More thoughts that I'm having... marc_tag_structure: 1) MARC: tagfield, liblibrarian, libopac, repeatable 2) Koha: mandatory, authorised_value, frameworkcode 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 I'm wondering if it makes sense to maintain 2 separate sources of data. The first XML file would be the data that comes from the actual MARC specification (denoted by the "MARC:" tag above. The second XML file would be what Koha should do with the incoming data. -- 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. >From there...we could use scripts to transform XML to SQL or to parse the XML and do the database updates via Perl. Anyway...just some thoughts for now. Have to run! -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org 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/