This is all fine, but lets talk in unit tests for MARC::Record if we
can. They will make plain what the actual behavior is, and will let
us talk about what the preferred behavior could be. Sorry to be so
short, but there's only so much time in the day.
//Ed
On Jul 13, 2006, at 2:55 PM, Thomas Dukleth wrote:
The MARC record management libraries need to allow management of the
legacy records we actually have and the records that existing systems
currently use.
Some problems that MARC record management libraries need to manage:
1. CHARACTER VARIANCE FOR FIELD CODES.
Large union catalogue systems such as RLIN and OCLC have already
specified
almost every numeric MARC 21 local use field for their own purposes.
Canadian local use fields for equivalence or cross-reference between
languages are part of the MARC 21 standard even if they are only
used in
Canada. RLIN itself has specified so many local use fields that
they have
added field codes with letters instead of only numbers to provide more
local use fields for special purposes of theirs.
Local system use of field codes that are not strictly numeric would
seem
to be a reasonable solution to the problem of too many potential
reserved
uses of local use fields. Such usage would allow local use fields
which
do not interfere with the established local use.fields of popular
union
catalogue systems.
1.1. NO PROBLEMS WITH RECORD MANAGEMENT MODULES?
I have not observed problems with field codes containing non-numeric
characters using MARC::Record or MARC::File::XML. However, I have not
tested extensively and want to be certain that no problems would
not arise
from such usage in future.
2. CHARACTER VARIENCE FOR SUBFIELD CODES.
On Thu, July 13, 2006 4:41 pm, Paul POULAIN wrote:
Could it be possible to have an option that deals with invalid
subfieldcodes :
Whether valid or not, real systems use punctuation symbols to
designate
subfields so as not to interfere with standard usage. No, $9 is not
always enough. Use of $% and $@ is widespread.
RLIN uses $% to store the control number of a linked authority record.
UNIMARC has provided $3 for the same purpose. The problem of how
to match
bibliographic records to authority records has been left to system
designers for MARC 21.
Punctuation symbols may be sufficiently numerous for some purposes
but I
can certainly imagine a case in a system where actually using capital
letters in addition to the standard lowercase letters would be very
helpful.
2.1. PROBLEMS WITH RECORD MANAGEMENT MODULES.
I have not tested this but expected that at least some punctuation
might
be liable to be a problem for some record management modules. Paul
Poulain reports this as a problem for MARC::File::XML. I believe
his case
had problems with $> as a subfield in addition to possibly capital
letters.
On Thu, July 13, 2006 4:41 pm, Paul POULAIN wrote:
* die (actual behaviour)
Maybe this would not be a problem for some punctuation, but I would
like
to be certain that it would not to be a problem for any punctuation
nor
for capital letters either.
3. SYSTEMS ANSWERING REAL NEEDS.
Systems are designed to answer real needs in the real world. Of
course,
extensions to standard usage should sometimes be filtered out to
facilitate maximally interoperable record exchange when exported
for use
outside the system for which the extensions were created. However,
the
recipient of an unfiltered record may not have the option of
choosing a
filtered record if only unfiltered records are available. The record
recipient's system has to cope with available records or not use them.
If system designers are adding elements to MARC, which extend the
standard
without conflicting with the standard; then the libraries used to
manage
the records must support such records.
Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
http://www.agogme.com
212-674-3783
