Re: ZNG: "Z39.50 Next Generation"

Ray,

I read this with interest, but I have to say that I find it difficult to
see how the conclusions have arrived - are there any accompanying
notes/rationale for this design ?

In my mind, I thing that any next generation of Z39.50 should revisit at
first base the requirements of what Z39.50 gives us - after all, we are
talking software development here, and a formal set of requirements should
be the first stage of a development lifecycle.

I see that this can be very simply listed as:

- something that offers search/retrieval interoperability in all the
  domains that Z39.50 is currently used in - plus others as well
- something that offers strong search semantics in a fully open sense
- something that easily allows server characteristics to be ascertained
- something that addresses current trends in technology.

these are the unique factors of Z39.50 - and the very reason why we use
it. Z39.50 version 2 and 3 does address this - 
the problem being that 75% of the current standard addresses a tiny
minority of actual implemetations out there, that were often quite
specialised requirements, and this has an effect of putting many folk off 
implemeting the core 25% I suspect.

I find it difficult to see why anyone would want to use ZNG over the
range of alternatives out there: - on one hand
it is looking at current technologies - a very positive thing, but on the
other hand use of something like CCL I can see potentially upsetting
folk, eg those where a native language is not English - for example, how
is CCL represented for in a Japanese language ?

One question is therefore - why would any implementer choose the proposed
ZNG over XML Query, XQL, XML-QL, Quilt etc.

It is my belief that a key stength of Z39.50 is the ability to scale from
a simple pseudo-stateless architecture used in many web applications up to
a full result set session with an extended service infrastructure, and
that after several years we see vendors finally starting to look at search
interoperability such as Bath profile. Its taking a lot of pressure from
customers to get these real issues to finally happen.

So for my stab at encouraging some criticism -  lets simplify the
current spec to (say)  init search and scan.  

Use just Query type 1 or choose an XML approach on type 0 and bring back
the good old piggybacking for retrieval, and carry records entirely in
XML.

Nothing else - no other externals etc, and define this against the
protocol bit 1.  This way we retain technical backward compatibility from
V2 and V3 and keep the semantic strength we've been striving for all
these years.

Rob

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 Rob Bull    bull@crxnet.com         Crossnet Systems Limited
 tel +44 (0) 1635 522912             Unit 41 Bone Lane, Newbury
 fax +44 (0) 1635 522913             Berkshire, RG14 5SH, United Kingdom
-+-+-+-+-+-+-+-+-+-+-   A member of the DS Group  -+-+-+-+-+-+-+-+-+-+-+-

Received on Friday, 13 July 2001 10:56:20 UTC