DOM Indexing--why several config files from which generating indexes XSL?
Zebra DOM model indexing had been introduced into Koha, deprecating GRS-1 model. With GRS-1, we used to have a records.abs file defining Koha indexes. With DOM model, an XSL file transforms MARCXML biblio records into Zebra indexes. This file is named biblio-zebra-indexdefs.xsl, and is stored in marc_defs/[marc21|unimarc]/biblios directory. But it seems that this file is not supposed to be modified directly. Going to DOM model, records.abs had been transformed into a biblio-koha-indexdefs.xml. This transformation is done with a XSL koha-indexdefs-to-zebra.xsl. Then biblio-koha-indexdefs.xml is transformed into biblio-zebra-indexdefs.xsl with biblio-koha-indexdefs.xml We have this chain of transformations: records.abs >>> XSLT koha-indexdefs-to-zebra.xsl biblio-koha-indexdefs.xml >>> XSLT biblio-koha-indexdefs.xml biblio-zebra-indexdefs.xsl The question is, using Zebra in DOM mode, why should we continue to modify records.abs file, and then cascading generating following files? Or even, why should we modify biblio-koha-indexdefs.xml, and then create from it biblio-zebra-indexdefs.xsl? Why not modifying from now directly biblio-zebra-indexdefs.xsl. -- Frédéric DEMIANS http://www.tamil.fr/u/fdemians.html
Frédéric, We have this chain of transformations:
records.abs >>> XSLT koha-indexdefs-to-zebra.xsl biblio-koha-indexdefs.xml >>> XSLT biblio-koha-indexdefs.xml biblio-zebra-indexdefs.xsl
The question is, using Zebra in DOM mode, why should we continue to modify records.abs file, and then cascading generating following files? Or even, why should we modify biblio-koha-indexdefs.xml, and then create from it biblio-zebra-indexdefs.xsl? Why not modifying from now directly biblio-zebra-indexdefs.xsl.
We should absolutely NOT recreate the DOM configuration from record.abs. That was a one-time transformation, and must not be repeated, or bug 8665 is liable to recur, as well as various other regressions. As for why we use biblio-koha-indexdefs.xml to generate biblio-zebra-indexdefs.xsl, I admit I don't actually know. Galen? Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Thanks for your response.
We should absolutely NOT recreate the DOM configuration from record.abs.
Yes, I was assuming that.
As for why we use biblio-koha-indexdefs.xml to generate biblio-zebra-indexdefs.xsl, I admit I don't actually know. Galen?
So what? Galen? For my libraries, I'm inclined to tweak locally the .xsl file rather than the .xml file. Any reason no to do so?
Frédéric,
As for why we use biblio-koha-indexdefs.xml to generate
biblio-zebra-indexdefs.xsl, I admit I don't actually know. Galen?
So what? Galen? For my libraries, I'm inclined to tweak locally the .xsl file rather than the .xml file. Any reason no to do so?
I tend to tweak the xsl instead of xml file as well for purely local changes. I was hoping Galen had some input on this, since he's the original architect of all the DOM configurations in Koha. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Hi, On Thu, Dec 27, 2012 at 11:48 AM, Frédéric Demians <frederic@tamil.fr>wrote:
As for why we use biblio-koha-indexdefs.xml to generate biblio-zebra-indexdefs.xsl, I admit I don't actually know. Galen?
So what? Galen? For my libraries, I'm inclined to tweak locally the .xsl file rather than the .xml file. Any reason no to do so?
Admittedly, it's a near thing, but biblio-koha-indexdefs.xml is more concise and expresses the *intention* of the indexes -- the XSL we're just stuck with since that's what Zebra needs. Of course, since it's XML, it's not all that more concise, but at least it admits of the possibility of creating a base index definition language in JSON or YAML that would actually be concise. My practice has always been to update the XML, then generate the XSL. YMMV, but arguably {authority,biblio}-zebra-indexdefs.xsl should be kept out of the source tree and just generated when needed. Regards, Galen -- Galen Charlton Director of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
participants (3)
-
Frédéric Demians -
Galen Charlton -
Jared Camins-Esakov