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

Robert Sanderson azaroth at liverpool.ac.uk
Thu Apr 11 15:25:52 CEST 2002


> I've been pushed for time; but now I'm back with a vengeance!  Read it

Goodo :)

> > 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.


> > 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.

See below, but yes.  I should have said, 'currently all full text', but I 
think that it's a good distinction to make in general as it keeps all the 
textual data together.

> > 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."

Right.  If we say F&N is serverInfo + title and description in 
databaseInfo it's much easier than specifying exactly which bits and 
pieces are okay and which aren't.

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

Okay, okay I forgot to do this.
http://gondolin.hist.liv.ac.uk/~cheshire/presentations/explain--/


> > I would like something along the lines of <indexInfo
> > encapsulationSupport="true"> or similar as that implies that the
> > following indexes can use piggyback searches.
> piggyBacking -- rather than using the misleading word "encapsulation",
> which in the Z39.50 world is something different altogether:

Urgh. My fault, I thought they were the same thing.


> 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

I thought the same thing, or at least a renaming of the existing high 
level elements.

> * <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".

How to get to the database in order to interact with it at all.  At the 
ZIG I described it as 'information by which you can create a full URL to 
the database'  I toyed with 'protocolInfo' but everything is protocol 
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.

Yes.  Obviously it's about the database as the record is about the 
database.


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

I disagree here. Information about the record as opposed to the database 
is very different from the rest of it, and is by definition 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.

What we need is a various-features-supported-by-this-server place to put 
stuff.

The lastUpdate and numRecs attributes /need/ moving. 

> * <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

Either is fine IMO.  Retrieval Info is more explicit though, as otherwise 
people might want to put information about the records in there.  (Like 
who they were created by or something)

> 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.


serverInfo:  connectionInfo ?  It's about how you connect to the database.
databaseInfo:  ? descriptive fields concerning the database.  
                descriptionInfo??
metaInfo:  can stay as is (info about the explain-- record)
indexInfo:  Interaction with the DB.  How about:

<interactionInfo>
  <indexInfo>
      <index>...</index>
  </indexInfo>
  <sortKeyword></sortKeyword>
</interactionInfo>

and then we have a more appropriate space to put in different 'supported' 
features.

recordInfo:  retrievalInfo is probably a better name.

Rob


-- 
      ,'/:.          Rob Sanderson (azaroth at liverpool.ac.uk)
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Twin Cathedrals:  telnet: liverpool.o-r-g.org 7777
____/:::::::::::::.              WWW:  http://liverpool.o-r-g.org:8000/
I L L U M I N A T I






More information about the Ex-plain mailing list