[Koha-bugs] [Bug 6681] When importing a biblio record via Z39.50, authority links and items also get imported

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

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

--- Comment #28 from David Cook <dcook at prosentient.com.au> ---
(In reply to Frédéric Demians from comment #27)
> For the future, a better way for storing XSL could be designed. In the
> disorder: - a z3950severs table new field, - a new db table for XSL, - a
> centralized repository, - a link to a Koha community page (like for SQL
> report library).

I've been thinking about this for a little while as well. I've been working
again on an OAI harvester which uses XSLTs to filter out the 952, 999, and $9,
and I figure "koha-tmpl\intranet-tmpl\prog\en\xslt" isn't always the best place
to put these things.

I'm intrigued by the idea of using a db field or db table. If we allowed
uploads, that would make it easier for libraries to add their own XSLTs (for
better or worse) without meddling around on the file system. 

Actually, a db table could be interesting. We could have the blob, the
filename, an id... and then have a db field in z3950servers (or whatever other
server config table) that has a foreign key to the primary key id in the XSLT
table. 

I'd kind of like the ability to set defaults as well though... so you could set
up XSLT profiles to apply on import (rather than having a string of filenames).
 Of course, we'd probably need a linking table then for profiles to files. 

I think that'd be a good way to go about setting up defaults though. You could
have a "Default Z3950" profile (and maybe a "Default OAI" table). 

--

Actually, as I work on this OAI client, I start thinking about ways to
integrate code and storage of Z3950 and OAI targets. I'm trying to think if
there are other protocols we use for importing records as well... and how
instead of making more tables, we could make some tables more generic.

I wonder too about using XSLTs when importing records via the batch import,
although that would probably slow things down a lot as you'd be going from Iso
Marc to Marc Object to MARCXML to XSLT to MARCXML. 

I suppose I like the idea of making storage and code more generalizable...

</ramble>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are watching all bug changes.