https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39509 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |39510 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39510 [Bug 39510] Allow for a single xslt file that can cover unimarc and marc21 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39509 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Could you elaborate on this one? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39509 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to Lisette Scheer from comment #2)

Sure, cascading XSLT works where there's more files for the different definitions, and you can create a custom one that overrides the default but it's still there. This means when there are updates the default is updated but the custom is still there.

This also makes it easier to debug and make changes to the XSLT.

Also if you change something it only breaks that section and is easy to recover the default.

I'm not sure that I follow. Is the idea that there are multiple XSLTs in a pipeline which are each applied to the XML sequentially? Or the custom XSLT is imported into the 1 XSLT and it overrides the existing templates? Or something else?

We were discussing yesterday during Hackfest the difficulties with customizing record display when libraries have different needs.

Personally, I think that the XSLT for record display is a dead-end, especially in light of things emerging metadata schemas like BIBFRAME. I think we should be looking at using the Elasticsearch JSON document and using a template language for display (whether that's server-side or client-side). Provided we restrict the security of the template (ie disabling EVAL_PERL/ABSOLUTE for Template::Toolkit for instance) and use Content-Security-Policy, we could actually let libraries modify these templates via the Web UI. This is a strategy that I've employed in discovery systems. That said, we would still run into that same problem of new updates to displays not flowing through to customized displays. But we could mitigate that just by flipping a flag at upgrade time which could show a dismissable message saying "hey the default template has been updated - consider reviewing your custom template view" or something like that. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39509 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #4)

I think long-term no one thinks XSLT should be used. But a full revamp won't happen soon too much effort, and also it was not clear for the crowd that we were ready for removing support for Zebra entirely.

I was thinking more so of adding a new display option which could be grown incrementally rather than an in-place replacement. The same way really that the XSLT gradually replaced the old display mechanism that came before it. Only once it was fully mature did we flip the switch.

This MVP would imply a reorganization of the current XSLT in a way each visual section of the record display has its own template (I'd say all in one single file) so we can have options for overriding them. Something like make the XSLTs useful as they were originally meant to be.

Sounds interesting. I have a Koha plugin which transforms MARCXML into another XML schema using XSLT and I've started using template overrides so different customers can have different transforms. It's quite useful. Happy to share code and ideas with whoever works on this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.