RE: ZNG: "Z39.50 Next Generation" (fwd)

> > zng.cgi?field1=any&term1=cheshire&bool1=NOT&field2=any&term2=c
> > at&sortfield=
> > title&maxrecords=25&firstrecord=1
>
> Why is that superior to zng/startRec=1?numRecs=25?any:cat not any:dog, which
> is what we are proposing?  Other than you've added the complexity of sort
> which we've chosen to defer for now.

As I'll say again below, defering acknowledged complexity to post design
phase is in my opinion a fundamental mistake in software design of any
type.

> > It doesn't require server side interpretation of the 'common command
> > language' just mapping directly into a standard Z query.
>
> Both our proposals require nearly identical code to turn the requests into
> Z39.50.  The difference is that it probably didn't take code to produce my
> original request.

Err...

<select name="field1">
<option value= "any">Full Text</option>
<option value = "author">Author</option>
...
</select>

<input type="text" size = 80 name = "term1" value = "">

My system doesn't require any code, nor does it require the end user
knowing the ins and outs of the query language as yours does.

For example, how could you specify in your system:

search title 'mozilla and z39.50' and author sanderson, robert not date <
2000-12-01 sorted-by descending date


The options/selects could be generated on the fly from the Explain Lite
document by some simple javascript even.  By building the fields into the
interface, rather than the query, we're exploiting the Web's advantage
over a command line interface.

The Explain Lite should be easily machine parsable. The good thing about
the current Explain is that once you've got the information it's all
neatly laid out in such a way as you can just extract the useful bits of
it.  Of course that's still pretty complex to do, but that can be fixed
with the xml version I hope.


> > My, admittedly very quickly hacked up, specification is more easily
> > extended, and wouldn't break previous versions of ZNG. For
> > example, to add
> > probabalistic searches, or specific proximity searches, or other
> > unforeseen type of search, currently you'd need to extend the query
> > language and then make sure that everyone knows about the
> > changes, updates
> > their parser and so forth.
> > If it just takes adding in a new operator to be recognised in
> > the 'operN'
> > fields, this is a trivial task. This can be acknowledged in
> > the explain
> > record as well.
>
> I think we have plenty of opportunity for extensibilty in our current
> proposal.  We've consciously chosen to limit our proposal to start with
> something simple and build from it.

I've had no good experiences in my time as a programmer trying to build
things from an underspecified base.  I'm sure examples aren't needed.

> Well, when we're done with our simplied Explain, perhaps will be be adopted
> by the current Z39.50 implementors as well.

Perhaps :)

Rob

-- 
      ,'/:.          Rob Sanderson (azaroth@liverpool.ac.uk)
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Syrinnia:  telnet:  syrinnia.o-r-g.org 7777
____/:::::::::::::.                WWW:  http://syrinnia.o-r-g.org:8000/
I L L U M I N A T I

Received on Tuesday, 17 July 2001 10:11:54 UTC