Re: ZNG dicussion

Sorry if I am spamming the list a lot at the moment, but in the light
of my last two messages (ZOOM and Query Language) I would just like to
take a quick look at Alan's list of Z39.50 weaknesses and see what is
and isn't addressed by current initiatives.

> Date: Wed, 26 Sep 2001 18:53:07 +1000
> From: Alan Kent <ajk@mds.rmit.edu.au>
> 
> Z39.50 Weaknesses
> -----------------
> To me, weaknesses of Z39.50 are
> 
> * The protocol is too large and hard to implement at the low level.

I hope that this will be less of an issue if ZOOM or something similar
becomes widespread -- reimplemention of low-level code should become
unnecessary, that code being implemented once in the API layer.

>   When an existing tool kit does not do the job, you are stuck.

Isn't it the case that many if not most of the existing toolkits are
Open Source?  That being so, it should be possible for good
programmers to extend the code where necessary -- I have done with
with Yaz at least once.

While modifying a low-level toolkit can be somewhat trickier than
writing application-level code, there are people you can hire to make
these changes for you.  <Ahem!>  :-)

> * There are too many concepts. This makes joining the crowd hard, or
>   makes interoperability hard.

I think this is the crux of the issue.  See below.

> * Its still not that easy to use from major programming languages.

Again, we can hope that ZOOM or something similar will address this.
Alan, did you have any specific languages in mind?

> * Numeric values for attributes is ugly - there is no standardized human
>   readable query language.

Totally agree, that's a part of the reason that I am keen on the
current initiative to design a human-readable query langauge (BUT not
to compromise on expressiveness in doing so!)

So back to what I think is the only truly fundamental issue among
these: the large number of concepts that one needs to understand in
order to use Z39.50.  I call this fundamental because it is tied into
the _identity_ of Z39.50, while all the others can be argued as being
problems with specific implementations or presentations.

So how can we move forwards with the number-of-concepts problem?
Well, some of the concepts (origin, target, presentation layer) will
be going away with the new revision of the standard, along with all
the other OSI baggage.  This will surely help.

But we will still be left with concepts such as attribute sets,
attributes, attribute types and values, result sets, tag sets, tags,
record syntaxes, schemas, profiles, etc.  What can we do about this?

I am really interested in any ideas people may have, because I have
none myself really -- except perhaps to concentrate more on these
semantic concepts in the tutorials than we may have done in the past.
I don't think any of these concepts can be dropped: it seems to me
that they are all fundamental to what Z39.50 is, and make real
contributions to its strength.

Thanks for listening.  I'll try to stay quiet for the rest of today
:-)

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike@miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "Oh no, you mustn't do that ...  They BREED in sewers, and
	 then you get huge swarms of evil-smelling twelve-foot tall
	 killer-budgies coming at you out of the drains!" -- Monty
	 Python.

Received on Thursday, 27 September 2001 06:59:04 UTC