My understanding has always been that xsl files are used to 'format' or 'transform' xml files. I've never gone the other direction from xml to xsl. But then again, Koha's index creation is not my forte.
On Thu, Dec 24, 2015 at 11:10 AM, Ian Bays <[email protected]> wrote: > On 24/12/2015 17:46, Ian Bays wrote: > > Hi Joy, > Thanks for this. However I think it works the other way around (use the > xml file to generate the xsl file). I had a clue that the xsl file was > being used for rebuild when I introduced a syntax error in the xsl file and > rebuild threw an error. > The command to recreate the xsl (as per comments in header) is roughly: > > xsltproc ../../../xsl/koha-indexdefs-to-zebra.xsl > authority-koha-indexdefs.xml > authority-zebra-indexdefs.xsl > > but that does not put the normalize-space around the 010$a. So I suspect > I need to inspect the koha-indexdefs-to-zebra.xsl to see when and why it > inserts the normalize-space stanza. > > If anyone else has this problem with dom indexing on dev install at > roughly this version I would be happy to raise a bugzilla entry for it. > > Strangely if I do an authority search and capture the URL, then change the > "mainentry" to be "LC-card-number" and the search term to be "n 90628286" > and resubmit the changed URL it will find the correct record. This leads > me to think that the search request from the staff client and the search > interface from the matching algorithm is asking zebra for different > things. Here is (most of) the changed URL as I don't know of any way in > the staff client to search authorities for contents of LC-card-number: > > /cgi-bin/koha/authorities/ > authorities-home.pl?op=do_search&type=intranet&authtypecode=PERSO_NAME&marclist=LC-card-number&and_or=and&excluding=&operator=is&value="n > 90628286"&orderby=HeadingAsc > > Thanks again. > > Ian > > On 24/12/2015 15:14, Joy Nelson wrote: > > Hi Ian- > If you are editing the .xsl file be sure to use xsltproc to recread the > indexdefs.xml file also. (then reindex your auths, naturally :-) ) > > I suspect that you are correct that there is some stripping of spaces, but > not to the extent you are looking for. i.e. Koha is removing 1 space, but > not multiple spaces If this is the case, someone with some more > expertise would need to weigh in on the behind the scenes code. > > If you have some perl proficiency you can use perl scripts to pull out, > modify the 010$a (stripping out spaces) from your authority records in Koha > if that would help make them match the incoming records. But from a true > catalogers perspective you want the 010$a in your system to be the 'right > value' spaces or no spaces, so using a script to modify your 010$a's may or > may not be desirable. > > joy > > > -- > Ian Bays > Director of Projects, PTFS Europe Limited > Content Management and Library Solutions > > > > -- > Ian Bays > Director of Projects, PTFS Europe Limited > Content Management and Library Solutions > > -- Joy Nelson Director of Migrations ByWater Solutions <http://bywatersolutions.com> Support and Consulting for Open Source Software Office: Fort Worth, TX Phone/Fax (888)900-8944 What is Koha? <http://bywatersolutions.com/what-is-koha/> _______________________________________________ Koha mailing list http://koha-community.org [email protected] https://lists.katipo.co.nz/mailman/listinfo/koha
