---- Reported by kohabugs@agogme.com 2009-04-06 17:03:15 ----

This meta-bug is responsible for easily 100 mostly unreported bugs of the form when the bibliographic material has characteristic X Koha feature Y does not function correctly or feature Y fails completely.  Most of the corollary bugs affect the OPAC but the effect is not confined to display because the values are used in a manner which often breaks features, including search features.  Reporting all the corollary bugs would be a waste of time which would be better spent fixing the code which is the source of the problem.

The presence of many of the corollary bugs would be obvious to anyone with a serious knowledge of library science when casually examining Koha.  The corollary bugs are liable to give any library seriously investigating Koha when considering ILS choices to regard Koha with suspicion.  While the corollary bugs go well beyond mere display bugs, the presence of mere display bugs undermines confidence that Koha can even store MARC data correctly.

I should have reported this meta-bug years ago but I incorrectly believed that the various corollary bugs would be rapidly diminishing in the wake of significant changes, such as migration to Zebra, as work on Koha 3.X continued.  Unfortunately, some relatively recent attempts to provide an alternative to legacy use of the biblio and biblioitems tables have followed the bad practise of starting with an incorrect presumption about the structure and values of a record instead of reading the structure and values in the manner in which the record presents them.  Furthermore, useful and necessary elements of past feature implementations have been lost when replacing legacy work in Koha.  Losing useful and necessary elements could be avoided by paying careful attention to what had been done even somewhat correctly in previous code, and by paying careful attention to relevant standards.

The design and use of the biblio and biblioitems tables has been a consequence of time and budget constraints which were especially severe at the two most significant points in the development of Koha.  Those tables introduced for the first version of non-MARC Koha.  In the original non-MARC Koha, those tables provided an innovative FRBR-like hierarchical model for Koha.  Their use in MARC Koha minimised the new code needed for MARC Koha.  Without having taken some insufficiently well considered coding shortcuts which happened to include the biblio and biblioitems table design, the opportunity to create the first version of Koha and the later opportunity to create MARC Koha might have been lost.

The problems would only be maintained by merging various bibliographic tables.  Use of Zebra has only modestly changed most of the legacy use problems and merely inspired recreating the same old bugs in a new form with poorly implemented features such as the code for XSL.

The constraints from the first version of Koha and first version of MARC Koha are past.  However, we cannot afford to break Koha with a great code upheaval everywhere to fix the legacy problems.  My proposed remedy given further below is a piecemeal approach to correcting the various problems feature by feature.  Legacy code which currently depends upon the poorly populated biblo and biblioitems tables should only be removed when a newly introduced fix for that particular feature has been thoroughly tested.  Until such testing is complete, legacy code should exist in parallel to a newly introduced fix for the feature.


1.  MAPPING.

1.1.  NON-MARC KOHA MAPPING.

The first non-MARC Koha libraries used data import filters which normalised the data from MARC records to match the non-MARC Koha bibliographic record model.  I have never seen those filters but it could have been possible to normalise the MARC data as needed and then provide a mostly many to one mapping of MARC data to a Koha table column.  The records had subsequently been maintained as non-MARC Koha records by those libraries.


1.2.  MARC KOHA MAPPING.

The use of the biblio and biblioitems tables in MARC Koha has presumed only a one to one mapping of data limited to only one MARC  subfield in only one field to a Koha table column.  The mapping is set by biblioitems.kohafield in the Koha bibliographic frameworks.  The limitations of the MARC Koha mapping design between MARC data and non-MARC Koha columns ensure that the non-MARC Koha columns are not populated as well as they might have been for MARC Koha.

Very little value normalisation has been provided in MARC Koha when inserting data into the biblio and biblioitems tables.  Without normalisation appropriate for the intended use of the non-MARC columns, values taken from MARC are not necessarily appropriate for code which is common to both non-MARC and MARC Koha.

The mapping problems include: under-inclusiveness of the value when a variety of fields may be appropriate for filling the value; 
under-inclusiveness of the value taken from a single instance of a particular field;  under-inclusiveness of the value when a variety of subfields may be appropriate for filling the value; under-inclusiveness of the value taken from a single subfield; and over-inclusiveness of the value from a single subfield.


1.2.1.  MARC FIELD VARIATION MAPPING UNDER-INCLUSIVENESS.

MARC records may use different MARC fields than the one for which biblioitems.kohafield specifies a particular biblio or biblioitems column.


1.2.1.1.  EXAMPLES OF MARC FIELD VARIATION.

The most problematic examples of mapping many different types of MARC fields, such as author, usually present too many different and more important problems for Koha mapping.  For simplicity of presentation, I use an example which does not cause many problems but is an obvious omission in the OPAC.

One example of field variation is the many different types of notes fields in MARC.


1.2.1.1.1.  MARC 21 EXAMPLE OF FIELD VARIATION.

The most commonly used MARC 21 notes field is 500.  A MARC 21 bibliographic framework may set biblioitems.kohafield to biblio.notes for 500 $a.

Notes which did not appear in the most commonly used MARC 21 field, such as the following case of a bibliography or other reference note, would not appear in uses of biblio.notes.

504 ## $a Filmography: v. 2, p. 344-360.


1.2.1.1.2.  UNIMARC EXAMPLE OF FIELD VARIATION.

The most commonly used UNIMARC notes field is 300.  A UNIMARC bibliographic framework may set biblioitems.kohafield to biblio.notes for 300 $a.

Notes which did not appear in the most commonly used UNIMARC field, such as the following case of a bibliography or other reference note, would not appear.

320 ## $a Index published separately every December.


1.2.2.  REPEATABLE MARC FIELDS MAPPING UNDER-INCLUSIVENESS.

MARC records may have more instances of the field for which biblioitems.kohafield specifies a particular biblio or biblioitems column than uses of the column expect.


1.2.2.1.  EXAMPLES OF TROUBLESOME REPEATABLE MARC FIELDS.

Uses of  biblio.isbn expect a single ISBN but the real world of bibliographic material is very different.

The ISBN field is a repeatable field in MARC records.  Different ISBNs are assigned for different, volumes, revisions and binding formats issued by a particular publisher.  MARC bibliographic records are generally created at the manifestation level.  Multiple applicable ISBNs may have been printed on an individual book or merely known to the cataloguer.  When multiple ISBNs are part of the same bibliographic manifestation, then they may be included in the same manifestation level MARC record.

In the current publishing practises of English language countries, a single manifestation is liable to have multiple ISBNs for multiple binding formats issued by the same publisher.  ISBNs for both the hardcover and paperback binding format are likely to be included in the same MARC record.  The practise of changing the pagination from one binding format to another, thus introducing a new manifestation, is now mostly reserved for popular fiction.  The time when a publisher would introduce a title in a sturdy binding format and later sell the cheaper binding format rights to another publisher specialising in cheaper binding formats has mostly subsided several decades ago.

However, in the publishing practise of other countries, such as French language countries, different binding formats for the same title are liable to be issued by different publishers.  The pagination is also likely to change between the most common French binding formats.  ISBNs for broché and poche format bindings are unlikely to be included in the same MARC record for books published according the common French publishing practise because at least the publisher is liable to be different between broché and poche bindings.

There are other generally less common reasons for multiple ISBNs to appear on an individual MARC record but they tend to be shared by the publishing practises of all countries.  Co-publication or divergent market publication may mean that a book is produced or distributed by multiple publishers in their respective markets and each publisher uses its own ISBN for its own market without changing the bibliographic manifestation.  A multi-volume set of books may have an ISBN for the set as a whole, if the set has its own ISBN, and the set may collectively share the ISBNs for each individual volume of the set, if the individual volumes have separate ISBNs.

[The complications of manifestation level cataloguing of sub-manifestation level information such as ISBNs which often function at a level between manifestation and item need a special remedy.  However, the mistake of manifestation level cataloguing incorporating sub-manifestation level information such as ISBNs is a legacy of AACR and the earliest designs of MARC and their derivatives.  Creating sub-manifestation level records between the manifestation and item level and linked to the appropriate manifestation and item level records might help.  However, any such local correction would be of limited value in a shared cataloguing environment in which common standards perpetuate problems associated with the standards until the standards are duly corrected.  Furthermore, the many complications of ISBNs would only be reduced, not eliminated, even if such a remedy would be widely adopted.]

The ISBN used from biblio.isbn may not be the appropriate one for a particular use case.  Yet most Koha features would fail completely if multiple ISBNs would be supplied to their functions.


1.2.2.1.1.  MARC 21 EXAMPLE OF TROUBLESOME REPEATABLE FIELDS.

A MARC 21 bibliographic framework would set biblioitems.kohafield to biblio.isbn for 020 $a.

Different bindings for the same manifestation may appear as follows.  In this case, the hardcover binding has no identifying text but hardcover is the most common binding for English language library books in the absence of identifying text.

020 ## $a 0415285933
020 ## $a 0415285941 (pbk. : alk. paper)


1.2.2.2.  UNIMARC EXAMPLE OF TROUBLESOME REPEATABLE FIELDS.

A UNIMARC bibliographic framework would set biblioitems.kohafield to biblio.isbn for 010 $a.

Co-publication or different publishers for different markets may appear as follows.

010 ## $a 0-8405-0392-X $b Presses de l'Université de Montréal
010 ## $a 2-252-02070-9 $b Klincksieck


1.2.3.  MARC SUBFIELD VARIATION MAPPING UNDER-INCLUSIVENESS.

MARC records may have more subfields for a particular field containing data which ought to be used in populating a particular biblio or biblioitems column than the one subfield for which biblioitems.kohafield specifies the particular column.


1.2.3.1.  EXAMPLES OF MARC SUBFIELD VARIATION IN A MARC FIELD.

Uses of biblio.author populated by a single MARC subfield often prevent standards compliant and authority controlled uses.

The use of authorised forms provides unique text for a term or name within an authority file applicable to authority controlled bibliographic records.  Matching the authorised forms of a term or name in an authority controlled field across multiple automation systems requires using the textual value composed from all the MARC subfields which form the authorised term or name.  The record number of a matching authority record may be helpful but cannot be widely used to query other systems.

Thomas Mann, the reference librarian at the Library of Congress, may be distinguished from the many other people with the name Thomas Mann including Thomas Mann, the Nobel prize winning novelist and short story writer.  Additional distinguishing information is added to the common complete form of a name until a particular name is matched uniquely.  Thomas Mann, 1948- will not form a false match with Thomas Mann, 1875-1975.


1.2.3.1.1.  MARC 21 EXAMPLE OF SUBFIELD VARIATION.

A MARC 21 bibliographic framework would set biblioitems.kohafield to biblio.author for 100 $a.

However, authorised names require more than merely $a to be complete.

100 1# $a Mann, Thomas, $d 1948-

will not form a false match with

100 1# $a Mann, Thomas, $d 1875-1955.


1.2.3.1.2.  UNIMARC EXAMPLE OF SUBFIELD VARIATION.

A UNIMARC bibliographic framework should set biblioitems.kohafield to biblio.author for 700 $a.

700 #1 $a Mann $b Thomas $f 1948-

will not form a false match with

700 #1 $a Mann $b Thomas $f 1875-1955.

Even the simple common forms of names require more than merely $a in UNIMARC because $a only contains the entry part of the name used as the beginning point for alphabetic sorting in a list of names which is usually the author's last name.

UNIMARC Koha libraries have used poor standards breaking workarounds for the problem that even the common form of a name does not appear in a single subfield within an authority controlled personal name field in UNIMARC.

One approach has been to use the first statement of responsibility in the title field, 200 $f, to populate biblio.author .  However, the statement of responsibility is intended to be transcribed from the non-authorised form of a name as it appears on the title page along with any accompanying words describing the author's role.  Even if the uncontrolled transcribed form of an author's name matches the controlled authorised form of an author's name, the included accompanying words describing the author's role such as "by" or "photographs by" will not match the authorised form of the name.  Actual non-standard cataloguing practise could treat 200 $f as an authority controlled field but non-standard uses of 200 $f have led to worse problems.  Some French UNIMARC libraries have catalogued using 200 $f and never add appropriate authorised forms of names to their proper place in 700-720.

Another approach has been to treat 700 $a as in MARC 21 where $a usually contains both the first and names for authority controlled fields.  Mixing use from different standards does not solve the fundamental problem.

If some workaround would have been needed, then compatible record exchange with other libraries could have been much less broken by adding special local use fields to the UNIMARC records perhaps using 790.  A script could have populated 790 $a with the authority controlled string extracted from the various relevant subfields in 700-720.

Libraries should be free to use Koha in whatever manner they find helpful.  However, Koha defaults should not be encouraging non-standard cataloguing as workarounds for legacy problems in Koha code.  Unfortunately, the poor workaround of setting biblioitems.kohafield to biblio.author for 200 $f is part of the default French UNIMARC bibliographic frameworks.  The problem has been exacerbated by taking the non-standard use of 200 $f as an example in the Koha online help.

One of the most important purposes of MARC is the interoperable sharing of records between libraries.  The standards breaking compromises used by the workarounds actually implemented for French UNIMARC Koha, prevent interoperable sharing of UNIMARC records between French UNIMARC Koha libraries and standards compliant libraries.  This unnecessary record sharing exclusion of French Koha libraries is most unfortunate.


1.2.4.  REPEATABLE MARC SUBFIELDS MAPPING UNDER-INCLUSIVENESS.

MARC records may have more instances of the subfield for which biblioitems.kohafield specifies a particular biblio or biblioitems column than uses of the column expect.


1.2.4.1.  EXAMPLES OF ASSOCIATED REPEATABLE MARC SUBFIELDS.

Uses of biblioitems.place , biblioitems.publishercode , and biblio.copyrightdate expect single values in each column but the real world of bibliographic material is very different.

Co-publication or divergent publication in different markets is one example of the problems with repeated subfields.  Some types of publishing frequently involve co-publication.  If populating the publication information columns excludes additional values from repeated MARC subfields, then important information would be lost for its uses inside Koha.

If populating the publication information columns includes additional values from repeated MARC subfields, the relationships between the additional values becomes disassociated.  A particular place of publication needs to be associated with a particular publisher and sometimes particular dates.  When place, publisher, and date are disassociated into separate uncoordinated variables, necessary coordination between them is lost.  Segregated use of place, publisher and date without association makes even display use difficult to read and interpret correctly even when actual human understanding is applied.


1.2.4.1.1.  MARC 21 EXAMPLE OF ASSOCIATED REPEATABLE SUBFIELDS.

A MARC 21 bibliographic framework may set biblioitems.kohafield to biblioitems.place for 260 $a, biblioitems.kohafield to biblioitems.publishercode for 260 $b, and  biblioitems.kohafield to biblio.copyrightdate for 260 $c.

260 ## $a Geneva, Switzerland : $b Skira ; $a New York : $b Rizzoli, $c 1983.

Such information might be confusingly transformed into the following form in Koha.

place = "Geneva, Switzerland : New York : "
publishercode = "Skira ; Rizzoli, "
copyrightdate = "c. 1983."


1.2.4.1.2.  UNIMARC EXAMPLE OF ASSOCIATED REPEATABLE SUBFIELDS.

A UNMARC bibliographic framework may set biblioitems.kohafield to biblioitems.place for 210 $a, biblioitems.kohafield to biblioitems.publishercode for 210 $c, and  biblioitems.kohafield to biblio.copyrightdate for 210 $d.

When multiple publishers are present and individual publishers have multiple places or dates which need association, any failure to retain the association is even more problematic than usual.

210 ## $a Köln $a London $a Paris <etc.> $c Taschen $a Paris $c Le Monde $d cop. 2005 

Such information might be confusingly transformed into the following form in Koha.

place = "Köln London Paris <etc.> Paris "
publishercode = "Taschen Le Monde "
copyrightdate = "cop. 2005."


1.2.5.  SINGLE MARC SUBFIELD MAPPING OVER-INCLUSIVENESS.

The MARC subfield for which biblioitems.kohafield specifies a particular biblio or biblioitems column may contain data which does not match some uses of the specified column.


1.2.5.1.  EXAMPLES OF MISMATCHED DATA IN SINGLE MARC SUBFIELDS.

Some uses of biblioitems.pages expect the pagination and nothing more, however, MARC records catalogued according to standard cataloguing rules include extra data or other information intended for human interpretation including at least the type of extent reported.  Even the presence of pagination in MARC, is dependent upon the material type and in the case of some material is also liable to be absent in records representing multiple volumes.


1.2.5.1.1.  MARC 21 EXAMPLE OF MISMATCHED DATA IN SINGLE SUBFIELDS.

A MARC 21 bibliographic framework may set biblioitems.kohafield to biblioitems.pages for 300 $a.

Pagination extent almost always includes at least the abbreviation for pages.

300 ## $a 546 p. ; $c 24 cm.

Pagination often exists in multiples designating different parts of the text.

300 ## $a xiv, 391 p. $b : ill. $c ; 25 cm.

Multiple volumes usually have no pagination reported when describing extent.

300 ## $a 10 v. $c ; 29 cm.

Some material types have no pagination.

300 ## $a 1 DVD (90 mins.) : $b sd., col. ; $c 4 3/4 in.


1.2.5.1.2.  UNIMARC EXAMPLE OF MISMATCHED DATA IN SINGLE SUBFIELDS.

A UNIMARC bibliographic framework may set biblioitems.kohafield to biblioitems.pages for 215 $a.

Pagination extent almost always includes at least the abbreviation for pages.

215 ## $a 546 p. $d 24 cm.

Pagination often exists in multiples designating different parts of the text.

215 ## $a XIV-391 p. : ill. ; 24 cm.

Multiple volumes usually have no pagination reported.

215 ## $a 10 v. $d 29 cm.

Alternatively, multiple volumes may have multiple paginations reported.

215 ## $a 8 t. en 4 vol. (LIV-439, 529, 504, 571, 553, 521, 545, 544 p.) $d 26 cm.

Some material types have no pagination.

215 ## $a 1 DVD (1 h 31 min) $c coul. (PAL), sonore


2.  DATA MODELS.

A good data model must have an adequate representation of the world to support the intended function of the model.

Some parts of MARC design may be unnecessarily complex.  Yet, an an alternative oversimplified data model which fails to capture the intrinsic complexity of the world in a particular context will fail to perform the needed function reliably or at all 


2.1.  DATA MODEL USE EXAMPLES.

2.1.1.  ISBN NORMALISATION EXAMPLES.

There are three different Koha template ISBN parameters: isbn, amazonisbn, and clean_isbn.  Each has progressively more normalisation but all of them are deficient for their intended purpose in the case of an enormous set of source record complications and ISBN matching difficulties.  All the template ISBN parameters start from the often improperly populated value in biblioitems.isbn .

In http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2242 comment #3 Frédéric Demains referred to an ideal situation, http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2242 .  "It should be better to have one place to construct 'isbn' required by various services!!!"  Unfortunately, the ideal situation is not the real world.

The problems for data modeling include those used as examples above, including those not explicitly described above, as well as other issues.

Although less common in some publishing practises such as French language publishing practises, individual bibliographic manifestations may have multiple ISBNs.  Even individual physical items may have multiple ISBNs which vary according to the market in which the item is being sold.  ISBNs are normalised with dashes separating groups of numbers to enhance human readability for UNIMARC but normalised without dashes for MARC 21 and most other automation uses.  MARC 21 allows extra qualifying text to occupy the same subfield as the ISBN.  A particular ISBN may have no match in some set of data but a different ISBN used for the same item, manifestation, expression, or work may be useful.  Invalid and cancelled ISBNs persist in many important data sources.  Some publishers recycle old disused ISBNs for new titles , therefore, ISBNs are not a reliable unique identifier of even a particular manifestation format.  ISBN-13 was introduced for EAN compatibility and in anticipation of the exhaustion of the ISBN-10 namespace but ISBN-10 did not vanish in legacy data and systems.  The subject of ISBN difficulties is much too complex to treat in this bug report.


3.  FIX METHODOLOGY.

3.1.  WASTEFUL FIX METHODOLOGY.

The methodology which should not be employed to fix this meta-bug is to use some workaround for each particular corollary bug as it is encountered starting from the same problematic legacy design and values.  Koha would then become nothing more than a collection of very brittle workararounds.  Each workaround would be liable to become broken every time a new or different form of the values used for one workaround would be needed for a new feature or different form of an existing feature.


3.1.2.  EXAMPLES OF WASTEFUL FIXES.

In 2005, I committed a few very minor workarounds for some of the most obvious corollary Koha bugs which merely corrected  superficial visibility problems in the OPAC.  No more than one of my workaround fixes survived more than a month and a half in CVS without being broken by code added by someone else which reintroduced the original bug or a new variation.

Fixing bugs which to which other developers had not given any attention, and would have been especially unaware because the bugs had not been reported, had been only part of the problem.  As long as the underlying data model does not fit the needs of a feature, new means of breaking the feature in some contexts would be likely to be found.


3.2.  RELIABLE FIX METHODOLOGY.

A reliable methodology for fixing the corollary bugs is a piecemeal approach to correcting the various bugs feature by feature in a direct manner, not by using a workaround.  A direct manner means fixing the meta-bug but only for the context of a particular feature and corresponding corollary bugs.

Fixes should be applied in parallel to the existing code.  Legacy code which currently depends upon the poorly populated biblo and biblioitems tables should only be removed when a newly introduced fix for that particular feature has been thoroughly tested.  Until a fix for a particular feature has been thoroughly tested, a system preference should control whether legacy code or the new fix is used.

Once the testing is complete for all uses of the legacy code, the legacy code can be removed along with the system preference for selecting either the legacy code or the new code.

The form of data values needed is actually dependent upon the function of the feature.  Values should be stored in a form normalised for the purpose of one feature and not presumed to be appropriate for every available feature.

While feature specific query time values normalisation on a shared set of stored values may be possible in some cases, it should not be used.  The CPU overhead required for query time normalisation, however minimal, should be preserved for where it is actually needed at query time.  Remember that many important features which may require much query time CPU usage have yet to be placed on any Koha roadmap.

Stored values should be reused as much as possible without unnecessarily increasing CPU usage and without a blind presumption that they will be appropriate for the purpose of every feature.  Imagining that all information matches the simplest cases is a mistake which gives rise to weak programming.


3.2.1  EXAMPLES OF RELIABLE FIXES.

3.2.1.1.  ISBN NORMALISATION EXAMPLES.

Each of the features using ISBNs may have a need for a different data structure and different normalisation to accommodate the variation in source data and feature use cases.  Most ISBN related features should use a list of ISBNs.  Some features should even include other non-ISBN identifiers in their functions to cover some uses of ISBNs where ISBNs may not always work.

Information such as binding format, material composition, or distribution market should be usefully associated with an ISBN rather than merely discarded in normalisation.

Features such as populating the OPAC with data from Amazon should use a list of ISBNs.  Amazon data from multiple ISBNs in the same manifestation, expression, or work may be perfectly appropriate to combine for the OPAC or necessary to find even one relevant match.  Amazon ASINs or other identifiers may be needed where ISBNs have not been used as identifiers by Amazon even if applicable.  Even when Amazon has records for a particular identifier the corresponding records may not have been populated with data useful to complement the OPAC, therefore, other related records should be used.

Other features may need to match only a single ISBN appearing on particular copy for a particular binding format, material composition, distribution market, etc.

Some normalisation must control for the variation of the same ISBN expressed as ISBN-10 or ISBN-13.

Provision for ISBN-14 or really GTIN-14 or EAN/UCC-14 may be needed for a more complete acquisition feature.  GTIN-14 for a package of multiple copies of the same item is mostly a book trade issue but could be a school or consortium with centralised buying issue.



---- Additional Comments From joe.atzberger@liblime.com 2009-04-06 18:12:47 ----

> the presence of mere display bugs undermines confidence that Koha can even store MARC data correctly.

This would be a foolish conclusion in a "serious" investigation of Koha, since one can easily reference the biblioitems.marc and biblioitems.marcxml fields of the database to see exactly what MARC data is stored by Koha.  The MARCXML file can be downloaded directly from the interface.  This should be enough to conclude it is stored correctly.

There is a lot to digest in this ticket, but some aspects are covered in RFC's at http://wiki.koha.org/doku.php?id=en:development:rfcs3.2

Including:
~ merge Biblio and biblioitems table - http://wiki.koha.org/doku.php?id=en:development:rfcs3.2



---- Additional Comments From kohabugs@agogme.com 2009-04-06 18:41:48 ----

If you read my bug report carefully I specifically state that merging the legacy Koha tables does not address the problems.  Merging those tables is not discarding them nor am I proposing that they be discarded.  Storing data correctly in MARCXML does not solve the problems either.

Throughout Koha data is being used from the poorly populated and poorly normalised legacy tables despite the presence of MARCXML.  However, even if the data were to be taken from MARCXML where it is stored according to standard cataloguing rules, too much feature dependent normalisation would be required at query time.  One may think that the CPU use for query time normalisation can cope now but it would not cope in future when there are many more features which actually need the CPU at query time.

The existing feature dependent normalisations often break the features in many use cases.  Feature dependent normalisations are often absent so that the features return bad data even if not everyone knows the difference.

Please read the entire bug report very carefully and then read it again.  Look at how many features, especially OPAC features, actually work when anything other than the simplest data is present in the records.  Often features fail.




--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:06 UTC  ---

This bug was previously known as _bug_ 3092 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3092

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was kohabugs@agogme.com.
CC member joe.atzberger@liblime.com does not have an account here
CC member kohabugs@agogme.com does not have an account here