https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29533 --- Comment #2 from mathieu saby <mathsabypro@gmail.com> --- Hi Even with only lowercases in 952/995, do you believe that the idea of allowing more subfields to be mapped in SQL is a bad idea? But I think uppercases are allowed in UNIMARC for subfields in local (9XX) fields, and I doubt it is forbidden in MARC21. For Marc21 the alphabetic character must be lowercase: Subfield codes - Two characters that distinguish the data elements within a field which require separate manipulation. A subfield code consists of a delimiter (ASCII 1F hex), represented in this document as a $, followed by a data element identifier. Data element identifiers may be a lowercase alphabetic or a numeric character. https://www.loc.gov/marc/bibliographic/bdintro.html But there is no such precision for UNIMARC: Subfield Identifier – A code consisting of two characters identifying individual subfields within a variable field. The first character, the delimiter, is always the same unique character specified in ISO 2709 and the second character, the subfield code, is either numeric or alphabetic https://eprints.mdx.ac.uk/2655/1/UNIMARC-2008-AH_final.pdf And in marcXML schema you can read this, so it seems that uppercase are allowed in MARC21 for local data https://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd "May 21, 2009 - Version 1.2 - in subfieldcodeDataType the pattern "[\da-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}" changed to: "[\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}" i.e "A-Z" added after "[\d" before "a-z" to allow upper case. This change is for consistency with the documentation. ************************************************************ This schema supports XML markup of MARC21 records as specified in the MARC documentation (see www.loc.gov). It allows tags with alphabetics and subfield codes that are symbols, neither of which are as yet used in the MARC 21 communications formats, but are allowed by MARC 21 for local data." -- 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=29533 --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I'd be interested in what your problem with more_subfields_xml is? We have quite a bit of data there and no issues. -- 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=29533 --- Comment #6 from mathieu saby <mathsabypro@gmail.com> --- (In reply to Katrin Fischer from comment #4)

I'd be interested in what your problem with more_subfields_xml is? We have quite a bit of data there and no issues.

A collegue from an other library told me it was "clumsy". I cannot say something more precisely because we are only planning to migrate to Koha and I am doing some tests. Generally speaking I confess I am not fond of Koha's logic for managing items (some other ILS I know, and our current one, store item data in SQL and only map them in MARC for display or export...), but we will adapt. What I fear mainly with more_subfield_xml is performance problems, if we need to use ExtractValue() for extracting information from this field in a report. Maybe am I worrying about nothing, but I have bad memories of ExtractValue() applied to MARCXML data. Less important, it will also be more complicated if we want to develop plugins or patches for customizing or making more parametrable the display of items (add a new column in OPAC for a information stored in more_subfield_xml ) -- 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=29533 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|add more fields to items |Add additional fields to |sql table |items --- Comment #8 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think a separate key-value style table would be the best way to improve the situation. If we offered a 'Koha only' storage without the need to map to map to a valid MARC subfield identifier, as we have run out of those. We could, for example, use capital letters only internally and do something like $9 + defined prefix for export/import. It would also help with the situation where data gets indexed and searchable that should not be (see recurring internal notes discussion). -- 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=29533 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.