Bug 20406

Would this include the ISBD export format? I ask because, so far, is the only way to specify custom formats for export/sending lists/carts.

Can't we use csv export there as well?

Yes, I think we can use CSV profiles in some places.

I agree that the syntax is underdocumented, but I am not sure that some libraries aren't still wanting this.

Students might use it for creating lists of literature for their projects maybe? It's an easy to copy summary and somewhat more readable than what you could do with a CSV.

I think we should provide export with XSLT profiles in addition to CSV profiles.

Hi Gaetan! For old-fashioned librarians still printing catalog cards, this is their way of copy-pasting what is in the ISBD display into their word document in so far as experience is concern.

I agree with Gaetan that this should be removed. Keeping it (undocumented and problematic as it is) only for the sake of copy-pasting seems a waste. Better work on the export formats instead then.

I disagree and with good reason! yes, agreed that the way it is implemented is not in the best possible manner. 

The ISBD display support is one of the __MAJOR__ reason that has allowed the massive use of Koha across the entire Indian sub-continent. Without the ISDB display (and I do not mean the code) as an option on the OPAC and staff client, Koha will stand to lose the position of de-facto choice. many libraries here have infact use the ISBD display as the primary display.

So, yes I don't mind a code upgrade / cleanup. But that display is *needed* and needs to stay. Koha users are not all from the 1st world countries and thousands are still using AACR2 instead of RDA.

We were just about to use it! Our cataloguing colleagues want a quick view of the data.

You have to click a lot on the MARC view to see it all.

The XSLT view is appropriate for circulation but not for what they want.

Well, it seems a few people do rely on this display.

My understanding is that the requirement is a more simple display than the normal one, without all the links, layout, and features we have in the normal display. (Nicolas, the marc view is indeed quite horrible, somehow some librarians want it by default yes!)

I think this display would still be better achieved through xslt, which wouldn't require us to have a half-baked undocumented domain-specific templating system hanging around in Koha just for this one tab.

Maybe indeed we could make it so that several xslts could be used in the normal display, and allow the user to switch between them?

This would of course make it possible to have a simple text only ISBD-style display, but anything would be possible then.

(In reply to Indranil Das Gupta from comment #7)
> I disagree and with good reason! yes, agreed that the way it is implemented
> is not in the best possible manner. 
> 
> The ISBD display support is one of the __MAJOR__ reason that has allowed the
> massive use of Koha across the entire Indian sub-continent. Without the ISDB
> display (and I do not mean the code) as an option on the OPAC and staff
> client, Koha will stand to lose the position of de-facto choice. many
> libraries here have infact use the ISBD display as the primary display.
> 
> So, yes I don't mind a code upgrade / cleanup. But that display is *needed*
> and needs to stay. Koha users are not all from the 1st world countries and
> thousands are still using AACR2 instead of RDA.

I agreed with you Mr. Das Gupta.. .

Old is gold ! :)

Its better not to remove ISBD display.its a feature which makes Koha more welcoming to Indian users.Forget the undocumented internal syntax for a while.

Strongly disagree with the initiative of removing ISBD display. This may be because of the fact that Librarians are not so much involved in Koha development team. The popularity of Koha in Indian Subcontinent is mostly based on the ISBD view of entered database. Till now there are a lot of users in this Subcontinent those want to view the catalogue not in mnemonic format but in ISBD format. As MARC framework is totally based on AACR2, so removing ISBD display should be unethical, as I think. Correlating MARC with AACR2 properly is the only way of integrating the sense of librarianship with the technological aspects of a library management software, is my opinion. Again as there are many items described in AACR2 Part 1 and there is only one place of writing syntax in ISBD template in Koha, at the time of releasing new version of Koha we are waiting for some easier way of incorporating syntax of each and every items. Hope effort should be made regarding this not removing the existing ISBD display. Regards...

While I agree w(In reply to Bengal Library Association from comment #12)
> Strongly disagree with the initiative of removing ISBD display. This may be
> because of the fact that Librarians are not so much involved in Koha
> development team. The popularity of Koha in Indian Subcontinent is mostly
> based on the ISBD view of entered database. Till now there are a lot of
> users in this Subcontinent those want to view the catalogue not in mnemonic
> format but in ISBD format. As MARC framework is totally based on AACR2, so
> removing ISBD display should be unethical, as I think. Correlating MARC with
> AACR2 properly is the only way of integrating the sense of librarianship
> with the technological aspects of a library management software, is my
> opinion. Again as there are many items described in AACR2 Part 1 and there
> is only one place of writing syntax in ISBD template in Koha, at the time of
> releasing new version of Koha we are waiting for some easier way of
> incorporating syntax of each and every items. Hope effort should be made
> regarding this not removing the existing ISBD display. Regards...

I agree with most of this comment, and agree that ISBD should not be removed. But it is wrong to say Librarians are not involved with Koha, every single feature in Koha has come as a request from Librarians. The QA Manager is a librarian, plenty of others are involved.

It is true that there are not many Indian Librarians involved, and that this should change. Commenting on bugs is a good start, paying developers to add features such as an easier way to edit ISBD is a good second step.

I think the ISBD has its uses, brevity and clarity for one. It seems to make sense to change how the view is generated to a more widely recognized standard.  However, we've customized ours to display some of the less common fields we use, and if you change how it's coded, I expect that will have to be redone.  I imagine other libraries who use it have also customized theirs?

It seems to me that this bug highlights how complicated(In reply to Elaine Bradtke from comment #14)
> I think the ISBD has its uses, brevity and clarity for one. It seems to make
> sense to change how the view is generated to a more widely recognized
> standard.  However, we've customized ours to display some of the less common
> fields we use, and if you change how it's coded, I expect that will have to
> be redone.  I imagine other libraries who use it have also customized theirs?

I think this comment highlights one of the problems with the current XSLT-driven visualization: it is too difficult to do and maintain for most institutions.

We also disagree with this suggestion of removing "ISBD View", as many Indian Subcontinent libraries are still based on AACR-2 and they are using this feature in their libraries for the end user's convenience. Even many times libraries use this ISBD view as default display view. Also, adding more information in ISBD view is easy for librarians by using Koha Global system preferences. It just need some more documentation to explore more. And in case, the community wishes to add additional feature like export cart in "CSV format", it is good and it can be done while the ISBD should remain in existence.

I think the ISBD preview should not be removed. 
However it should work equal to the normal view, ie use XSLT.
It allows more flexibility (repeatable fields, maintain fields ordering, etc.) to configure the view than the system preferences.

Reviewing the comments here the vote was quite clear: the ISBD view needs to stay. We could still think about offering an alternative way of defining its contents or at least making sure the syntax is well documented.

Closing.