MARC-105 (reformatted)

[Derek Lane <derek@duke.edu>]

All--

I noticed that I had long lines in the previous announcement.

Bill Birthisel points out that attachments are probably not
apropos in mailing list email.

Below find the re-formatted announcement for MARC-105.

All--

Latest tweaks for MARC.pm.

These tweaks will arrive on CPAN and at marcpm.sourceforge.net soon.

I sent this on to the others most closely involved before remembering
that we are now doing this on the list. Mea Culpa.

There are two new things here: one a generalisation and one new
functionality.

1. Getfields and updatefields no longer need assume that all fields
with the same tags are contiguous.

Discussion:

Getfields() and updatefields() have provided default capability for
retrieval and update of the data part of the MARC records
($marc->[$recnum}{array}) while maintaining order of tags inside the
record.

so records like:

092   $a MC207
049   $a NDDE

(note that 092 is out of sorted position)

can be edited programmatically to 

092   $a MC307
049   $a NDDE

What this update does is remove a restriction in the implementation
that disallowed records like this: 

(A)

880 1  $6 880-1 $a <Chinese encoded text>
245 00 $6 880-2 $a Taehan Chegukii
880 00 $6 245-2 $a <Chinese encoded text>

The problem is that the implementation required that all 880's go
together:

(B)

880 1  $6 880-1 $a <Chinese encoded text>
880 00 $6 245-2 $a <Chinese encoded text>
245 00 $6 880-2 $a Taehan Chegukii

This has been fixed, since many cjk records look like (A).

2. Output in MARC now adds appropriate 005 information if writing to a
file using output().  There is a means to add this information even if
you are using output() for the string version.

Discussion.

Field 005 is defined to be the "date and time of latest
transaction". Typical moments to update this are on transitions
between systems; commonly done on output.  I have implemented this
portably using localtime() (the alternative is to use Posix or select:
folk who can make this work over Unix's, Mac and Windows are hereby
invited to send patches...). I have not attempted the (optional)
tenth-second resolution since localtime does not support this.

The implementation also stamps records with a time that is potentially
a little earlier than the time the bits hit the disk (actually, the c
library).  There was a trade-off between ease of implementation and
absolute accuracy.

For commmon uses of MARC.pm this should not be a significant
difference. If you are using MARC to output 200 records, they should
hit the disk within a second or so; if you are outputting 30,000 then
you should be doing it incrementally, in which case the implementation
will Do the Right Thing.

Subclassers of MARC can add this detail by adding one line to their
output() method.

Let the list know if you have any problems or concerns.

Derek Lane
dereklane@pobox.com