adding fields in XSLT (bug 7332)
Hello, The bug 7332 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7332) add a new (242) field on the XSLT display. The question is: the XSLT does not contain all the fields we have in MARC21, so what must drive the content of XSLT ? Should we accept any patch (and have a huge XSLT at the end) ? Should we refuse any patch -except a bugfix- (and have a basic-but-enough XSLT) An Option between those 2 extreme positions ? I open the question, let me know your opinion !!! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hello Paul, in my opinion, it would be nice to have 1) an eventually huge XSLT file. It's probably easier for most people to comment out or tweak things that are already there than to add the "extra" fields they need from scratch. 2) a "local" XSLT file that survives updates unharmed where people can put the files they tweaked to their likings (I think this was talked about while ago, I don't know if it exists already). Cheers, Mirko Paul Poulain schrieb am 15.12.2011 17:55:56
Hello,
The bug 7332 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7332) add a new (242) field on the XSLT display.
The question is: the XSLT does not contain all the fields we have in MARC21, so what must drive the content of XSLT ? Should we accept any patch (and have a huge XSLT at the end) ? Should we refuse any patch -except a bugfix- (and have a basic-but-enough XSLT) An Option between those 2 extreme positions ?
I open the question, let me know your opinion !!!
Paul, My vote will surprise no one.
in my opinion, it would be nice to have
1) an eventually huge XSLT file. It's probably easier for most people to comment out or tweak things that are already there than to add the "extra" fields they need from scratch.
+1 The other option would quickly make it impossible for people who are concerned about MARC display (people like me, for example) to contribute what you call "bugfixes". I use fields most other libraries do not, so my stylesheets will diverge. Also, I would argue that not displaying as called for in bib standards *is* a bug.
2) a "local" XSLT file that survives updates unharmed where people can put the files they tweaked to their likings (I think this was talked about while ago, I don't know if it exists already).
This would be nice, but at present it is not possible, and I don't think anyone is working on it. Regards, Jared
* Jared Camins-Esakov (jcamins@cpbibliography.com) wrote:
Paul,
My vote will surprise no one.
in my opinion, it would be nice to have
1) an eventually huge XSLT file. It's probably easier for most people to comment out or tweak things that are already there than to add the "extra" fields they need from scratch.
+1
The other option would quickly make it impossible for people who are concerned about MARC display (people like me, for example) to contribute what you call "bugfixes". I use fields most other libraries do not, so my stylesheets will diverge. Also, I would argue that not displaying as called for in bib standards *is* a bug.
+1 from me also I think following the standard for display (even if I think the standard is mental, it is the standard) is the way to go here.
2) a "local" XSLT file that survives updates unharmed where people can put the files they tweaked to their likings (I think this was talked about while ago, I don't know if it exists already).
This would be nice, but at present it is not possible, and I don't think anyone is working on it.
Not actively, but there are specs, look for something in the new year! Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
+1 from me too. The XSLT is done so that only information in your records shows up. I don't see why people would not want that. Katrin * Jared Camins-Esakov (jcamins@cpbibliography.com) wrote:
Paul,
My vote will surprise no one.
in my opinion, it would be nice to have
1) an eventually huge XSLT file. It's probably easier for most people to comment out or tweak things that are already there than to add the "extra" fields they need from scratch.
+1
The other option would quickly make it impossible for people who are concerned about MARC display (people like me, for example) to contribute what you call "bugfixes". I use fields most other libraries do not, so my stylesheets will diverge. Also, I would argue that not displaying as called for in bib standards *is* a bug.
+1 from me also I think following the standard for display (even if I think the standard is mental, it is the standard) is the way to go here.
2) a "local" XSLT file that survives updates unharmed where people can put the files they tweaked to their likings (I think this was talked about while ago, I don't know if it exists already).
This would be nice, but at present it is not possible, and I don't think anyone is working on it.
Not actively, but there are specs, look for something in the new year! Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
2011/12/15 Fischer, Katrin <Katrin.Fischer@bsz-bw.de>:
+1 from me too.
The XSLT is done so that only information in your records shows up. I don't see why people would not want that.
+1 In an ideal world I think we would have some cool graphical tool where each library could easily configure their own display by dragging tags and subfields around, set conditions, formatting etc. Well, one can dream... Best regards, Magnus Enger libriotech.no
+1 to displaying all standard information on the Details page. If a library has this info in a record, but DOESN'T want it displayed, then can either remove the info, or strip the field out with JQuery. Hopefully 'sensitive' information is not being put in MARC records... I'm with Magnus on this one; a tool where the user can edit what fields are displayed in what order with what additional HTML (links and lists and spans etc), would be ideal. This is going to be particularly difficult with XSLT, because XSLT is, well, difficult. There has been a spec written to do User-Uploaded XSLT, so a library could modify and tweak the display as they need. We at ByWater weren't able to find enough folks interested in funding it, though, last time we asked, so it was shelved in favour of other projects. I'd really like to see more done with the ISBD view. As it stands, it's not terribly useful, as we've mostly moved away from cards at this point. But it's user-editable in a system preference, and can pull in MARC information and mix it with plaintext. If we used some of this code elsewhere, I think we could create a very customizable and user-friendly record display interface. Mashing that code up with the "tokens" we have in the Notices editor, and adding a little JQuery, could give us that drag/drop experience for customizing a record display. Probably not the most practical idea for immediate deployment, but making these sorts of display tweaks data-based instead of code-based will greatly easy the upgrade process for many libraries with particular information display needs. Cheers, -Ian On Fri, Dec 16, 2011 at 3:06 AM, Magnus Enger <magnus@enger.priv.no> wrote:
2011/12/15 Fischer, Katrin <Katrin.Fischer@bsz-bw.de>:
+1 from me too.
The XSLT is done so that only information in your records shows up. I don't see why people would not want that.
+1
In an ideal world I think we would have some cool graphical tool where each library could easily configure their own display by dragging tags and subfields around, set conditions, formatting etc. Well, one can dream...
Best regards, Magnus Enger libriotech.no _______________________________________________ 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/
-- Ian Walls Lead Development Specialist ByWater Solutions ALA Midwinter Booth #2048 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
On Thu, Dec 15, 2011 at 1:55 PM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Hello,
The bug 7332 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7332) add a new (242) field on the XSLT display.
The question is: the XSLT does not contain all the fields we have in MARC21, so what must drive the content of XSLT ? Should we accept any patch (and have a huge XSLT at the end) ? Should we refuse any patch -except a bugfix- (and have a basic-but-enough XSLT) An Option between those 2 extreme positions ?
I open the question, let me know your opinion !!!
I think the problem here is translation maintenance and consistency. I'd go for a 'official' huge translated set of XSLT files, and provide a stripped down (good default) version set as default. Regards To+
participants (8)
-
Chris Cormack -
Fischer, Katrin -
Ian Walls -
Jared Camins-Esakov -
Magnus Enger -
Mirko -
Paul Poulain -
Tomas Cohen Arazi