How to indicate piggy-backing (Was: [Ex-plain] ZIG presentation)

Mike Taylor mike at tecc.co.uk
Thu Apr 11 14:58:22 CEST 2002


Well, Rob's been hassling me to reply to his post-ZIG thoughts, and
I've been pushed for time; but now I'm back with a vengeance!  Read it
and weep, Azaroth!  :-)

> Date: Mon, 8 Apr 2002 19:11:44 +0100 (BST)
> From: Robert Sanderson <azaroth at liverpool.ac.uk>
>
> > > [Piggy-backing] should be somewhere in the indexInfo
> > > element. Attribute on the indexInfo tag?
> >
> > Really?  I find it _seriously_ hard to imagine a server which can
> > honour piggy-backed search/retrieve requests when the search is on
> > an `author' index, but not if it's on a `title' index.
> 
> On the indexInfo element, not on individual indexes.

Ah, stupid me.

> It would be a highly contrived situation where you could piggyback
> some searches but not others.  How does the standard represent
> piggyback searching?

As a bunch of optional fetch-related parameters on the searchRequest
APDU.

> > Conclusion: I think this is a per-databases boolean attribute.

(We all agree on this now, right?)

> > That leaves open the issue of whether it should go on the
> > <serverInfo> element (because it's to do with the mechanisms the
> > server supports) or the <database> or <databaseInfo> element
> > (because it may vary between databases.)
> 
> Not databaseInfo, as that's all full text.

If we think that's a distinguishing feature of the <databaseInfo>
element, then we should think about changing its name to reflect that.
Or at least making a bigger deal about it in the Commentary and the
Reference Guide.

> IndexInfo is about how to interact with the server as far as
> search,scan and sort go.  Originally there was just indexes inside
> indexInfo, but we now have sortKeyword for example.

Hmmm.

> If we put it in serverInfo, then it by default becomes part of the
> F&N elements.

Not necessarily.  It's up to us to specify what the F&N record looks
like.  But I agree it's nice if we can do that just by saying "It's
the <serverInfo> element and everything inside it."

> [...] Which I definitely do not like.  The full F&N record is
> already quite large.

Really?

> I'll upload my presentation to the ZIG to my server in a moment, and
> has an example of this.

?

> I would like something along the lines of <indexInfo
> encapsulationSupport="true"> or similar as that implies that the
> following indexes can use piggyback searches.

I don't disagree that <indexInfo> is the right place for this
attribute, but neither am I yet fully convinced that it's the right
place.  I DO feel strongly that we should call it what it is --
piggyBacking -- rather than using the misleading word "encapsulation",
which in the Z39.50 world is something different altogether:
	http://lcweb.loc.gov/z3950/agency/amend/am3.html

But all this vagueness and misunderstanding (e.g. my misreading
<indexInfo> as being a per-index thing, and no-one but you spotting my
mistake!) makes me wonder whether we need a semi-radical rethink of
the high-level structuring of the record.  I'm not sure that the
current pentachotomy (<serverInfo>, <databaseInfo>, <metaInfo>,
<indexInfo> and <recordInfo>) is as helpful as it could be.

* <serverInfo> is NOT information about the server (or at least, its
  <database> subelement isn't!)  Like the rest of the record, it's
  about a database.  This is, what, sort of "mechanical information",
  or "how-to-access-the-database information".

* The key  distinguishing characteristic of <databaseInfo> seems to be
  that it contains human-readable text, rather than that it's anything
  more to do with databases than any of the other information.

* <metaInfo> is so vague as to be almost meaningless (and as I have
  observed before, one man's data is another man's metadata.)

* <indexInfo> maybe be a good name, especially as it's essentially a
  repository for <index> elements; but it's not obviously the right
  place for the piggyBackingSupported attribute (or whatever we call
  it) which to me is nothing to do with high-level abstract concepts
  like indexes, but is a low-level nitty-gritty implementation detail
  more akin to the INET port.

* <recordInfo> is probably OK :-)  Though more generally you might
  argue that it's about retrieval, or about data; so that something
  <retrievalInfo> or <dataInfo> _might_ be more appropriate.  I'm not
  arguing for or against any of these possibilities, but I'll be
  interested to hear other people's thoughts.

More generally, it's not clear to me that our information fits into
five categories at all -- maybe four or twelve or ninety-six.  And I'm
not totally convinced either that all the subelements are in the right
categories given the current slicing.

(More generally, this is an example of just what difficult problems
classification and nomenclature generally are.  It shouldn't freak us
out that it's hard to get this stuff right.  See
	http://www.miketaylor.org.uk/dino/faq/s-class/index.html
if you're interested in this kind of thing.)

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "I grow weak, I grow slack / as if she captured the breath of
	 my voice in a bottle and I can't catch it back" -- Paul Simon,
	 "She Moves On"


P.S. I thought I'd just made up the word pentachotomy. but I guess
it's the obvious word for the concept, and sure enough a google search
reveals that four other people have already thought of it.)





More information about the Ex-plain mailing list