[Ex-plain] RE: Explain--

LeVan,Ralph levan at oclc.org
Wed Apr 3 17:22:53 CEST 2002

Thanks everyone for taking this stuff seriously!

I think the topic of general local extensibility is a good one.  If I am to
replace my current configuration files with this, then I'm going to need
stuff that you won't want.  The location of a holdings database is a good
one, though I think you'll hear more calls for it when the topic leaks off
this list and onto the Holdings list.

Mike, I'm afraid that "blows up" does mean catastrophically.  We've got code
to react gracefully to a diagnostic.  But, some servers just drop

The NamedResultSets option bit didn't show up until version 3 and is not
supported by the servers that blow up when you send them a result set name
other than "default".  I vaguely remember a case of a server that ignored
result set names and we turn this on for them as well.

Thanks, again!


> -----Original Message-----
> From: Mike Taylor [mailto:mike at tecc.co.uk]
> Sent: Wednesday, April 03, 2002 9:40 AM
> To: azaroth at liverpool.ac.uk
> Cc: ex-plain at indexdata.dk; levan at oclc.org
> Subject: Re: [Ex-plain] RE: Explain--
> > Date: Thu, 28 Mar 2002 23:14:00 +0000 (GMT)
> > From: Robert Sanderson <azaroth at liverpool.ac.uk>
> > 
> > > > HoldingsDatabaseName: do we have to go off to another database
> > > > for holdings info?
> > 
> > I think we can ignore this one as overly specific?
> I'd say that's a prime candidate for an "official" extension set.
> (Which, I guess, suggests that the word "extension" may not be quite
> what we mean.)  I have in mind that the core Explain-- DTD should
> concentrate, as it currently does, on generic Z39.50 concepts only;
> and that Ralph and others who know about such things should put
> together a set of bibliographic extension tags (and a specification
> for how and where they should be placed in the Explain-- record.)
> We'd include a reference to that set off the Explain-- site.  And
> Ralph's records would look a bit like this:
> 	<explain xmlns:bib='http://www.oclc.org/~levan/bib'>
> 	  <serverInfo>
> 	    <host>oclc.org</host>
> 	    <port>210</port>
> 	    <database>foo</database>
> 	    <bib:holdingsDb>bar</bib:holdingsDb>
> 	  </serverInfo>
> 	</explain>
> > > > What query types they support.  (Some blow up if you send
> > > > type-101.)
> > 
> > This is a good one, which I think we should include.  I know that
> > our server at least has type 0 as a way to transform SQL queries
> > into Z, but there's more useful applications for te different query
> > types.
> I guess we could support this.  But can't clients just submit a
> Type-whatever query and see whether it's accepted?  Or, Ralph, when
> you that some servers "blow up", do you mean in some completely
> catastophic way?
> > > > Do they support piggy-back searches.
> > 
> > Argh, encapsulation, we hates it.  But at least a global 'supports
> > encapsulation' or not field somewhere would be useful.
> No, supporting encapsulation is a much bigger deal, or at least a much
> less frequently supported deal, and piggy-backing on the Search
> Request APDU.  I _think_ Ralph's right, and we should just include a
> boolean saying whether piggy-backing is supported (per-server?
> Per-DB?)
> > > > Do they only allow the "default" resultSetName.
> > 
> > Named Result Sets is in the init response. Do we need to record this
> > as well?
> Surely not.
> > > > Do they allow referenceID's.  (That one will never get 
> past Ray.  But
> > > > apparently there are servers that don't support it.)
> > 
> > What's a reference ID? :)
> What is a server that doesn't support reference IDs?  Surely not a
> Z39.50 Server in any useful sense, any road up :-)
> > > > Do they support elementSetNames.  (Horrifying as it might seem,
> > > > there are such servers.)
> >
> > I think we can already do this, by having a record syntax tag with
> > no elementset subtags.
> "Absence of evidence is not evidence of absence" -- Tom Holtz.
> Surely a <recordSyntax> with no <elementSets> merely means (as with an
> omitted "sort" attribute on an <index> element) that we're not saying
> anything one way or another?  Otherwise we need to mandate that the
> <recordSyntax>'s <elementSet>s are an exhaustive list, which doesn't
> seem realistic to me.
> > IMO, we should put in at least query types and piggy-backing. After
> > the ZIG though ... focus needs to go on tightening the current stuff
> > and finishing the documentation
> Agreed.  (Obviously!)
>  _/|_	 _______________________________________________________________
> /o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   
)_v__/\  "Football is a simple game complicated by fools" -- Kevin
	 Keegan, quoting Bill Shankly.

More information about the Ex-plain mailing list