RE: ZNG dicussion

On Fri, 28 Sep 2001, Robert Sanderson wrote:
> > > > > > Explain Lite uses an XML format to describe some administrative details,
> > > > > This is what I don't get. When there's GRS and all the rest already in the
> > > > > Z spec, why add yet another parser requirement and put Explain Lite in
> > > > > XML?
> 
> > > > Rather than looking at Z39.50 as an isolated protocol, view it as
> > > > something that needs to fit into an environment of multiple applications.
> > > > Every library runs a webserver these days. Most libraries have a web
> > >
> > > This looks like an argument for ZNG, not Explain Lite. Although some of
> > > the same people are involved in each so perhaps I shouldn't be surprised.
> >
> > It certainly is an argument for ZNG, but I also made the argument that ZNG
> > is too a radical step for the installed base of libraries. See it more as
> > a step away from the world where you have to make a goat sacrifice to
> > appease the gods every time you need to make a change.
> 
> Personally, I don't as our system does it for me. I add an access point to
> a database in its XML configuration file, it gets added to explain. No
> need to do things twice :)
> I don't see why this shouldn't be the case for all Z servers.

In an ideal world that would be true. In the real world, it isn't true for
most servers out there. The toolkits supply the encoding, but you have to
write quite a bit of the content handling yourself. It appears as if
programmers have been too lazy, or too dumb, or had other priorities, and
didn't build things in a self updating way.

> > I wouldn't say Explain Lite is bolted on to accomodate lazy programmers. I
> > would say that it is bolted on so that a non-programmer can change the
> > specs and the presentation in one single swipe, using a readily available
> > XML tool.
> 
> I would argue against anything being bolted on to any specification. If it
> can't be encorporated within the standard natively, and it is useful and
> widely desired, then the standard should be changed fundamentally. Hence,
> XML/XER or other such approach if this is thought useful/necessary.

In principle I would agree. It makes an unneat wart on the Z39.50
protocol. However, I am more concerned with what is possible in practice,
than with the neatness of the protocol. It already has so many ugly warts
that it looks like an old toad. One more won't hurt it.
 
> > to be caused by too much real and percieved complexity. We believe that
> > putting our efforts into the existing Explain mechanism is a waste of
> > time, because we see little chance in getting the programmers in the
> > library community off their lazy bums and implementing Explain in a
> > standard, communicable way. This is why we propose a different, simpler
> 
> Very true :)  Apart from the ONE-2 consortium (don't know if that's the
> right word) has anybody else implemented Explain Lite? It seems that you
> have the same problem - getting people to implement something.

Not as far as I know, though there is a fair bit of interest in
implementing it. Explain Lite has been an experiment within the ONE-2
consortium, and has clearly been announced as such. Now that experiment
has been concluded, and it turns out to have been very successful. I would
label it as the most important result to come out of the ONE-2 project.

It is now up to us to convince people in the library community that this
is a good thing, and that they should go and graft our little wart onto
their systems. If we fail, we have another dead piece of Z39.50 baggage.
If we succeed, we will have strengthened Z39.50 interoperability in the
library community a great deal.

> In my opinion, if there is enough demand for it, then people will find
> solutions, either by changing products or getting their current supplier
> to implement it.  Currently there simply isn't enough demand, it seems?
> We hope to change this with our Explain supporting client. If people use
> Z natively they will see the advantages of Explain in not having to wait
> while it probes (ala Sebastian's Z-Spy) each index in turn.
> 
> I'm sure if the consortium approached one of the other projects that had
> implemented explain, that a reasonable contract could be worked out to
> turn the XML into real explain.
> 
> For example Cheshire uses an XML configuration file which is similar to
> the explain lite dtd, but is used by the Z server as well. It wouldn't be
> difficult to modify the configuration parser and explain generation
> code to fit into another system...

These are perfectly reasonable technical arguments. It could be done this
way, but experience from the ONE project showed that it was very difficult
to get the partners to implement Explain (which was one of the goals of
the ONE project). In the ONE-2 project all participants except the ones
who have library system vendor targets have implemented the support. You
can lead a horse to water, but you can't make him drink.

> BTW - How do you specify SortDetails in Explain Lite? It doesn't seem to
> be in the DTD at all? Also, there isn't any provision for
> PreferredLanguage? This seems strange, considering the European nature of
> the project? And b_<tag>s ?  Maybe the web documentation is out of date?

It is a little bit out of date, but the details you mention have not been
specified, simply because no-one in the project has had a need. The dtd
can quite easily be expanded upon. I am a firm believer in need based
specifications rather than trying to think of all the different ways
anyone will ever want to apply them.

Jacob Hallén

Received on Friday, 28 September 2001 10:26:15 UTC