> [KL] When I was reviewing the previous discussion about LC sorting, Jason > Etheridge had suggested the possibility of nesting sort algorithms - > http://markmail.org/message/xxbfp63g3yzeqxqa. A possible configuration could > be: > > Sort #1 -> LCCN > Sort #2 -> DDS > Sort #3 -> Default / ASCIIbetically > > I think this is what we have in mind for sorting across schemes.
Those sorts I was musing had undefined "tests" in them for determining whether a call number is actually LCCN, DDS, etc. This test could be to look at a "class_scheme" value, or use some sort of pattern matching (maybe not feasible if different call number schemes could look very similar), so there could still that extra step you're concerned with, defining the type of call number. That said, we could take the prefix/suffix-per-shelving-location idea and have a class-scheme-per-shelving-location value as well. Or once the label maker gets better support for multiple templates, it might make sense to bundle a class_scheme value into your templates (assuming there are other useful changes a template could help with, otherwise you're just abstracting the toggle a bit). One other thing, the selection could be "sticky", so you're not overriding a default so much as setting the value to what you'll be working with for a while (this would work well if you process batches of materials with the same call number scheme, but not so well if you have to--worst case--alternate the scheme for every item). -- Jason Etheridge | VP, Tactical Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com
