[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 #3 from David Cook <dcook at 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.