[ZOOM] Record Handling

Mike Taylor mike at tecc.co.uk
Wed Jul 10 17:37:30 CEST 2002


OK, I promised to address record-handling in a separate message.

> Date: Thu, 20 Jun 2002 16:00:50 -0500
> From: Aaron Lav <asl2 at enteract.com>
> 
> For 3.5.3, Get Field Count, coming from a MARC background, I was
> confused about the utility of this function [...]

So am I.

> For 3.5.4, Get Field, I'm not sure that for the case of MARC data,
> specifying both the field and subfield instead of just the field is
> desirable [...]

Neither am I.

> Also, there's no way currently specified to get the per-field
> indicator values, or the Leader data (see
> http://lcweb.loc.gov/marc/concise/concise.html#general_intro).

Indeed.

> On the other hand, perhaps the spec should explicitly say (as
> mentioned earlier on this list) that applications wanting this level
> of access should just get the raw MARC data and parse it themselves.

I agree 100% that this is the right way to go.  Indeed, section 3.5.6
(Raw Data) pretty much says so:

	[Raw Data] is useful primarily for record syntaxes such as
	USMARC which lead their own lives outside of Z39.50, and which
	are amenable to processing by other existing software.  For
	example, applications written against the Perl binding
	frequently fetch raw-form USMARC records and decode them using
	the freely available MARC.pm module.

So given that Get Field Count is meaningless and Get Field is
confusing; and given that every time we try to discuss them we get
nowhere; and given the knots that the C++ binding has got into trying
to provide a semi-uniform interface to records of different record
syntaxes (see
	http://zoom.z3950.org/bind/cplusplus/changes-1.0g.html#data
for example) I now propose that we THROW OUT THE GET NUMBER OF FIELDS
AND GET FIELD METHODS.

They are so underspecified as to be useless anyway.  Let's be
intellectually honest and reduce the Record interface to the only two
methods that are actually worthwhile: Render (as a debugging aid,
primarily) and Raw Data, yielding information that can actually be
used.  That's a MARC record, and XML document, a pointer to the
top-level node of a GRS-1 tree, a SUTRS string or whatever.

(Individual bindings and impementations would, of course, be free to
provide whatever additional methods they happen to find useful.)

CAN ANYONE THINK OF A REASON NOT TO DO THIS?

Thanks everyone.

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "Historically, Taunton is part of Minehead already" --
	 Monty Python.





More information about the ZOOM mailing list