RE: Explain-lite (Explain discussion)

> > Whilst I agree with Sebastian's view that Explain is the 
> way it is for a
> > reason and probably has a number of advantages over 
> Explain-lite, E-Lite has
> > the advantage that it is being used whereas however 
> technically good Explain
> > maybe it just hasn't been adopted
> 
> Wow. Big claim. We have supported it for years and use it on 
> all our sites.
> It might not have been adopted widely

OK ;-) - I take the point. I think that there was a understood qualifier in
that statement (widely, "apart from a small number of implementors" etc.)


> I hear this a lot. Could someone summarise in one or two sentences the
> information content Explain Lite supports that makes it better?

I part I think you've answered it yourself when you said  "The biggest
problem that I saw is that people do not know what information clients want
to receive and don't want to implement everything because its lots of
effort." - agreed this is not an argument for Explain-Lite per se.

The other strength, that I see (although some may argue it is a weakness) is
that Explain-lite can be delivered over other mechanisms whereas Explain in
its current form requires the Z39.50 search/retrieve mechanisms. I'd like to
see felxibility here since I'm looking at how to fit Z39.50 into service
discovery things such as UDDI. (again this isn't an argument per se for
Explain-lite)

> In terms of making Z39.50 more accessible to the world, I think
> two things would help here without changing the actual standard.
> (1) An XML encoding of packets (XER etc)
> (2) A document describing a subset of Z39.50 for doing init, search,
>     present, close (+ the explain lite category? :-)

Agreed and possibly (3) placing it amongst supporting standards (although
this is more marketing that protocol development)

Matthew

Received on Tuesday, 21 November 2000 04:12:52 UTC