deprecating zebra grs1 one day?
Hi As you know, making patches for Zebra has always be a nightmare. Now that DOM indexing is possible, it is a double nightmare, because you need to change 2 mores files (sometimes 4 more files when the bug is related to Marc21 and Unimarc). Unimarc conf files are not yet DOM compliant, but I have made some bugs which were signed off recently, and I hope they will soon pass QA. So, when it is done, so you think we could some day (for 3.14 ? 3.16?) get rid of Zebra GRS1 ? It could make simple further improvements. For example, I would like to make a page for configuring zebra indexes from staff interface. I think it can be done by parsing bib1, ccl.properties and xml DOM conf files. But I don't want to parse record.abs... Regards, M. Saby -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
Hi, On Sun, Sep 22, 2013 at 10:55 AM, Mathieu Saby <mathieu.saby@univ-rennes2.fr
wrote:
So, when it is done, so you think we could some day (for 3.14 ? 3.16?) get rid of Zebra GRS1 ? It could make simple further improvements. For example, I would like to make a page for configuring zebra indexes from staff interface. I think it can be done by parsing bib1, ccl.properties and xml DOM conf files. But I don't want to parse record.abs...
I don't think there's anything GRS-1 does that DOM cannot do. It's too late by far to consider removing GRS-1 support for 3.14, but it is not too late to make a deprecation announcement with the release of 3.14 and plan on having it be removed in the release after 3.14 (or the release after that). Consequently, I hereby open a straw poll for folks to indicate whether or not they think that announcing a deprecation is sensible. Regards, Galen -- Galen Charlton Manager 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
+1 for deprecation On Mon, Sep 23, 2013 at 8:42 PM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Sun, Sep 22, 2013 at 10:55 AM, Mathieu Saby < mathieu.saby@univ-rennes2.fr> wrote:
So, when it is done, so you think we could some day (for 3.14 ? 3.16?) get rid of Zebra GRS1 ? It could make simple further improvements. For example, I would like to make a page for configuring zebra indexes from staff interface. I think it can be done by parsing bib1, ccl.properties and xml DOM conf files. But I don't want to parse record.abs...
I don't think there's anything GRS-1 does that DOM cannot do. It's too late by far to consider removing GRS-1 support for 3.14, but it is not too late to make a deprecation announcement with the release of 3.14 and plan on having it be removed in the release after 3.14 (or the release after that).
Consequently, I hereby open a straw poll for folks to indicate whether or not they think that announcing a deprecation is sensible.
Regards,
Galen -- Galen Charlton Manager 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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Jared Camins-Esakov <jcamins@cpbibliography.com> wrote:
+1 for deprecation
+1 from me too Chris
On Mon, Sep 23, 2013 at 8:42 PM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Sun, Sep 22, 2013 at 10:55 AM, Mathieu Saby < mathieu.saby@univ-rennes2.fr> wrote:
So, when it is done, so you think we could some day (for 3.14 ? 3.16?) get rid of Zebra GRS1 ? It could make simple further improvements. For example, I would like to make a page for configuring zebra indexes from staff interface. I think it can be done by parsing bib1, ccl.properties and xml DOM conf files. But I don't want to parse record.abs...
I don't think there's anything GRS-1 does that DOM cannot do. It's too late by far to consider removing GRS-1 support for 3.14, but it is not too late to make a deprecation announcement with the release of 3.14 and plan on having it be removed in the release after 3.14 (or the release after that).
Consequently, I hereby open a straw poll for folks to indicate whether or not they think that announcing a deprecation is sensible.
Regards,
Galen -- Galen Charlton Manager 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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Greetings, +1 for announcing deprecation with release of 3.14 Announcing is sensible. Giving people an idea of the development path ahead of time allows for people to plan. GPML, Mark Tompsett
Hi, also for me +1 for announcing deprecation with release of 3.14 Cheers Zeno Tajoli -- Dr. Zeno Tajoli Dipartimento Gestione delle Informazioni e della Conoscenza z.tajoli@cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate
I appreciate your enthousiam :-) , but to deprecate grs1, we need to have DOM indexing for UNIMARC. So, these patches (and maybe others) need to be QAed http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10037 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8252 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7421 And for http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8252, if my logic is good, further developement is needed for editing indexdefs-to-zebra.xsl : I had to edit biblio-zebra-indexdefs.xsl by hand, because etc/zebdradb/xml/koha-indexdefs-to-zebra.xsl does only support "substring" in handle-one-index-control-field template. It is good for MARC21, but not for UNIMARC : in MARC21, indexing substrings is needed for controled field (001-009, with no subfields) But in UNIMARC it is needed for subfields of 1XX fields. So if DOM indexing is working with these new files, we may need to change koha-indexdefs-to-zebra.xsl. Not sure I will have time to do that (maybe someone else could devote some hours to that point?), so I need to have the opinion of QA team. M. Saby Mark Tompsett a écrit :
Greetings,
+1 for announcing deprecation with release of 3.14 Announcing is sensible. Giving people an idea of the development path ahead of time allows for people to plan.
GPML, Mark Tompsett ------------------------------------------------------------------------
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
On 24 September 2013 19:49, Mathieu Saby <mathieu.saby@univ-rennes2.fr> wrote:
I appreciate your enthousiam :-) , but to deprecate grs1, we need to have DOM indexing for UNIMARC.
Yep that's why we are just voting on announcing the deprecation, for 3.16. IE we aren't deprecated for 3.14, but announcing with the release that we plan to deprecate it. Chris
So, these patches (and maybe others) need to be QAed http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10037 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8252 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7421
And for http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8252, if my logic is good, further developement is needed for editing indexdefs-to-zebra.xsl :
I had to edit biblio-zebra-indexdefs.xsl by hand, because etc/zebdradb/xml/koha-indexdefs-to-zebra.xsl does only support "substring" in handle-one-index-control-field template. It is good for MARC21, but not for UNIMARC : in MARC21, indexing substrings is needed for controled field (001-009, with no subfields) But in UNIMARC it is needed for subfields of 1XX fields. So if DOM indexing is working with these new files, we may need to change koha-indexdefs-to-zebra.xsl.
Not sure I will have time to do that (maybe someone else could devote some hours to that point?), so I need to have the opinion of QA team.
M. Saby
Mark Tompsett a écrit :
Greetings,
+1 for announcing deprecation with release of 3.14 Announcing is sensible. Giving people an idea of the development path ahead of time allows for people to plan.
GPML, Mark Tompsett
________________________________ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Oh, ok I did not read all the messages... So +1 for announcing deprecation. Mathieu Chris Cormack a écrit :
On 24 September 2013 19:49, Mathieu Saby <mathieu.saby@univ-rennes2.fr> wrote:
I appreciate your enthousiam :-) , but to deprecate grs1, we need to have DOM indexing for UNIMARC.
Yep that's why we are just voting on announcing the deprecation, for 3.16. IE we aren't deprecated for 3.14, but announcing with the release that we plan to deprecate it.
Chris
So, these patches (and maybe others) need to be QAed http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10037 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8252 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7421
And for http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8252, if my logic is good, further developement is needed for editing indexdefs-to-zebra.xsl :
I had to edit biblio-zebra-indexdefs.xsl by hand, because etc/zebdradb/xml/koha-indexdefs-to-zebra.xsl does only support "substring" in handle-one-index-control-field template. It is good for MARC21, but not for UNIMARC : in MARC21, indexing substrings is needed for controled field (001-009, with no subfields) But in UNIMARC it is needed for subfields of 1XX fields. So if DOM indexing is working with these new files, we may need to change koha-indexdefs-to-zebra.xsl.
Not sure I will have time to do that (maybe someone else could devote some hours to that point?), so I need to have the opinion of QA team.
M. Saby
Mark Tompsett a écrit :
Greetings,
+1 for announcing deprecation with release of 3.14 Announcing is sensible. Giving people an idea of the development path ahead of time allows for people to plan.
GPML, Mark Tompsett
________________________________ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
I had to edit by hand, because etc/zebdradb/xml/koha-indexdefs-to-zebra.xsl does only support "substring" in handle-one-index-control-field template. It is good for MARC21, but not for UNIMARC : in MARC21, indexing substrings is needed for controled field (001-009, with no subfields) But in UNIMARC it is needed for subfields of 1XX fields. So if DOM indexing is working with these new files, we may need to change koha-indexdefs-to-zebra.xsl.
In which patch have you modified koha-indexdefs-to-zebra.xsl file directly? The 'normal' way to modifiy Zebra DOM indexes is a two step process: 1. Edit indexes defintion in biblio-koha-indexes.xml file. 2. Generate Zebra index building XSL file koha-indexdefs-to-zebra.xsl from indexes defintion file biblio-koha-indexdes.xml. If you bypass step 1, it means that index definition XML file is not necessary anymore, and so must be removed/deprecated.
Hi It is http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8252 Read all the comments, I think you will understand the problem. To make it short : I think koha-indexdefs-to-zebra.xsl is wrong, because it does not take into account 1XX coded position UNIMARC fields. (in MARC21, only 0XX fields could have coded position values) That's why 1XX were broken in DOM UNIMRAC So I first try to write directly a "right" xsl file, and if it works, it means my intuition about koha-indexdefs-to-zebra.xsl is good and that it needs to be updated (and I don't know how to do that) Mathieu Frédéric Demians a écrit :
I had to edit by hand, because etc/zebdradb/xml/koha-indexdefs-to-zebra.xsl does only support "substring" in handle-one-index-control-field template. It is good for MARC21, but not for UNIMARC : in MARC21, indexing substrings is needed for controled field (001-009, with no subfields) But in UNIMARC it is needed for subfields of 1XX fields. So if DOM indexing is working with these new files, we may need to change koha-indexdefs-to-zebra.xsl.
In which patch have you modified koha-indexdefs-to-zebra.xsl file directly?
The 'normal' way to modifiy Zebra DOM indexes is a two step process:
1. Edit indexes defintion in biblio-koha-indexes.xml file. 2. Generate Zebra index building XSL file koha-indexdefs-to-zebra.xsl from indexes defintion file biblio-koha-indexdes.xml.
If you bypass step 1, it means that index definition XML file is not necessary anymore, and so must be removed/deprecated.
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
So I first try to write directly a "right" xsl file, and if it works, it means my intuition about koha-indexdefs-to-zebra.xsl is good and that it needs to be updated (and I don't know how to do that)
You have 3 files: 1. xsl/koha-indexdefs-to-zebra.xsl 2. marc_defs/unimarc/biblios/biblio-koha-indexdefs.xml 3. marc_defs/unimarc/biblios/biblio-zebra-indexdefs.xsl If you modify DOM indexing, you edit file 2, and then you generate file 3 from 2 using 1, using a XSLT processor, for example xsltproc: xsltproc xsl/koha-indexdefs-to-zebra.xsl \\ marc_defs/unimarc/biblios/biblio-koha-indexdefs.xml \\ > marc_defs/unimarc/biblios/biblio-zebra-indexdefs.xsl
Yes, I know that :-) , but it won't work, because xsl/koha-indexdefs-to-zebra.xsl is probably wrongly coded. So one of the aim of my patch was to be sure it needed to re-written. My patch is signed off, so it the changes I made to biblio-zebra-indexdefs.xsl were probably right. That means koha-indexdefs-to-zebra.xsl must probably be fixed to manage 1XX fieds. But I want somebody to comment the bug to confirm it. Mathieu Frédéric Demians a écrit :
So I first try to write directly a "right" xsl file, and if it works, it means my intuition about koha-indexdefs-to-zebra.xsl is good and that it needs to be updated (and I don't know how to do that)
You have 3 files:
1. xsl/koha-indexdefs-to-zebra.xsl 2. marc_defs/unimarc/biblios/biblio-koha-indexdefs.xml 3. marc_defs/unimarc/biblios/ biblio-zebra-indexdefs.xsl
If you modify DOM indexing, you edit file 2, and then you generate file 3 from 2 using 1, using a XSLT processor, for example xsltproc:
xsltproc xsl/koha-indexdefs-to-zebra.xsl \\ marc_defs/unimarc/biblios/biblio-koha-indexdefs.xml \\ > marc_defs/unimarc/biblios/biblio-zebra-indexdefs.xsl
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
Hi, On Tue, Sep 24, 2013 at 2:32 AM, Mathieu Saby <mathieu.saby@univ-rennes2.fr>wrote:
** Yes, I know that :-) , but it won't work, because xsl/koha-indexdefs-to-zebra.xsl is probably wrongly coded. So one of the aim of my patch was to be sure it needed to re-written. My patch is signed off, so it the changes I made to biblio-zebra-indexdefs.xsl were probably right. That means koha-indexdefs-to-zebra.xsl must probably be fixed to manage 1XX fieds. But I want somebody to comment the bug to confirm it.
Speaking in general terms (I haven't looked at the particular bug), modifying koha-indexdefs-to-zebra.xsl to add or modify a template for extracting substrings from the UNIMARC 1XX fields is definitely the way to go, IMO. Regards, Galen -- Galen Charlton Manager 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
We had a discussion with Frederic under the bug 8252 I added some information about the issue, but I am not sure of the exact way of correcting it (add a new template maybe?) To put in a few words : - in Marc21 you can have 001-009data where "data" is a fixed string where each letter has a meaning - in UNIMARC you can have 001-009 data and 1XX$a/c/d/e....data where "data" is a fixed string where each letter has a meaning Galen Charlton a écrit :
Hi,
On Tue, Sep 24, 2013 at 2:32 AM, Mathieu Saby <mathieu.saby@univ-rennes2.fr <mailto:mathieu.saby@univ-rennes2.fr>> wrote:
Yes, I know that :-) , but it won't work, because xsl/koha-indexdefs-to-zebra.xsl is probably wrongly coded. So one of the aim of my patch was to be sure it needed to re-written. My patch is signed off, so it the changes I made to biblio-zebra-indexdefs.xsl were probably right. That means koha-indexdefs-to-zebra.xsl must probably be fixed to manage 1XX fieds. But I want somebody to comment the bug to confirm it.
Speaking in general terms (I haven't looked at the particular bug), modifying koha-indexdefs-to-zebra.xsl to add or modify a template for extracting substrings from the UNIMARC 1XX fields is definitely the way to go, IMO.
Regards,
Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com <mailto: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
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
participants (8)
-
Chris Cormack -
Chris Cormack -
Frédéric Demians -
Galen Charlton -
Jared Camins-Esakov -
Mark Tompsett -
Mathieu Saby -
Zeno Tajoli