No subject

systems call "shelf location" were also lists of basically the same nature.  So
rather than explicitly support each of these, they are also considered to be
"holding types" in the XML.

When migrating from one system to another, very often a library wants to swap
types around, putting the secondary types into primary and vice-versa, swapping
fund codes and vendors (I suppose because they've been putting things in the
wrong place before), using shelf location as the material type, ignore and not
import one list or other, etc.  There are all kinds of things that people want
to do with these "types".

What this approach allows is for the importing software to configure a mapping
for what to do with each of the types.  This way, no matter what the library
wants to do with them, the importer code doesn't have to be changed, nor does
there need to be a step transforming the XML.

I'm not married to this approach.  Do you think it's too confusing?

* Some systems (including Apollo) keep a usage count for biblios.  Whenever an
item checks out, the usage count for that item is incremented, as well as the
usage count for that biblio.  It isn't hugely important, but it means that for
biblios with a lot of items and a lot of turnover on those items, items can be
weeded without losing the count for the number of times the title has
circulated.  The biblio usageCount can be absent, in which case the importer
(for a system that supports it) should probably add up the item usageCounts to
create the biblio usageCount.

* ILS-specific extensions should be fine, and that makes sense.  Of course
we'll want to make sure that anything that makes sense in the main spec goes
there.  Also it would be nice to have an export including the extensions
validate against the schema, but I suppose an ILS could use its own schema, and
declare that it's the same as "LDIF Version X" plus extensions.

The main ILS-specific stuff that might be required (at least, that I can think
of right now) would be the set of configuration options for a library.  Those
wouldn't really translate from one system to another, generally, but would be
handy to have in the export for backup/restore purposes.  Maybe there's a way
to allow the storage of those in key/value pairs in the main spec.

Let us work on some updates based on this conversation and we'll see how the
XSD looks after that.  Thanks for all your help!

-- 
Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.