[ZOOM] Access to Record Data (Was: Catching up)

Mike Taylor mike at tecc.co.uk
Wed Nov 14 14:12:51 CET 2001

> Date: Wed, 14 Nov 2001 12:19:12 +0000
> From: Ashley Sanders <zzaascs at irwell.mimas.ac.uk>
> > In case anyone didn't "get" that, the message is that I am
> > starting to think that the rawdata objects are an extra layer of
> > added complexity for no or marginal gain.
> Have we decied how to allow access to the internal structure of a
> record?  DOM?  I'm sorry, but I can't work out what has been decied
> here.

Nothing's been decided -- or indeed discussed in any depth, despite my
asking people for their thoughts several times!

I think we're all agreed that we need a way to get hold of the raw
sequence of bytes for SUTRS, for all the *MARC records, and for XML
(and _probably_ not for anything else).  So I think we should go the
path of least resistance and define ZOOM::SUTRSRecord,
ZOOM::MARCRecord and ZOOM::XMLRecord much as we did in in 1.0e
but with the following method, or something very similar, right the
hell there in the records:

	const char *bytes(size_t *nbytesp);

(Maybe we should do that making ZOOM::SUTRSRecord, ZOOM::MARCRecord
and ZOOM::XMLRecord all subclasses of a ZOOM::documentRecord class
which provides that method.  Yes, I think I like that.)

Then the only real issue we have is how to deal with GRS-1, which is
very much out on its own.  Although I am a big GRS-1 fan, I think we
should just go ahead without it for 1.0g -- it's more important to
move the other issues forwards.

That said, we should keep thinking about this in the background.
Adam's suggestion, which both terrifies and intrigues me
(http://www.angryflower.com/status.gif) is that we don't deal with it
_at all_: we just translate GRS-1 records into "equivalent" XML
documents, and let people use their favourite DOM software to walk the
tree.  "Very interesting, Mr. Bond."

> > Personly i thing all record's shut be returned as a raw data, and
> > a easy way for the user to decode it with libs for handling
> > different encodings.
> Libs for handling decoding of raw data is fine, but out of scope for

Agree.  I don't think that's what Jakob meant, though: I think he was
just saying we need to make the data available in a form that people
can feed to their favourite libraries.

> I'm happy with DOM as long as it is optional and I don't have to
> have anything to do with it. I just don't have the time or the need
> to get into it.

I don't see us having anything to do with DOM _per se_.  We'll dish up
XML records (when servers provide them), and there's every chance that
people who want to play with XML records will use DOM to do so.  But
hey, that's their lookout.  They can feed 'em to sed if they want :-)

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "Indentation?! - I will show you how to indent when I indent
	 your skull!" -- Klingon Programming Mantra

More information about the ZOOM mailing list