[Ex-plain] RE: Explain--

Mike Taylor mike at tecc.co.uk
Wed Apr 3 16:39:56 CEST 2002


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