On Mon, 28 Apr 1997, Jon Knight wrote:
> On Sat, 26 Apr 1997, John C Klensin wrote:
> > (ii) For MARC records, I suspect the situation is much
> > like some of what we've found for EDI. The important thing
> > may be to distinguish things that are MARC records from
> > things that aren't, then to pass the former off to
> > processors --processors that will rarely be conventional
> > email engines-- that know what to do about them. It is
> > possible that such processors might reject some subtypes as
> > uninteresting or incomprehensible, but they are probably
> > the right level at which to make those decisions.
>
> Unfortunately I know from bitter experience that its sometimes impossible
> to deduce what sort of MARC record you've got just from its syntax;
> because all the MARC formats have a common heritage they all have a
> similar <leader><directory><fixed fields><variable fields> structure but
> sometimes the semantics of the fields is slightly different. I've knocked
> up a Perl module that can distinguish between some instances of USMARC,
A wild, and perhaps not very good, idea from one with very little
experience of the MARC format (other than hacking programs for
unpacking the UDC-distribution diskettes). In addition to MARC, one
could imagine a simple way of encoding MARC as multipart MIME (many
such records can then be put into a single message using multipart
mime). Something along these lines
Content-type: multipart/related; boundary=RandomSeparator
--RandomSeparator
Content-type: application/MARC-directory
fixed-field: lable1
fixed-field: lable2
fixed-field: lable3
variable-field: lable4
--RandomSeparator
Marc-field-lable: lable1
Content-type: application/MARC-fixed-field
... etc etc etc ...
--RandomSeparator--
I suppose that it also would be easy to encode Generic Record Syntax 1
this way (superior to RDM used in STARTS).
Cheers
Siggy
|