Re: new draft of Z39.50 URL specification

> From: mgursky@cdplus.com (mike gursky)
> Date: Tue, 21 Mar 1995 14:21:02 -0500 (EST)
> 
> Sorry - I didn't clearly state what my intention was.  It was not to
> object to the various options, but rather to suggest that the language
> of the draft says one thing and the syntax another.  In fact, I think
> the language is fine and the syntax is too restrictive.
> 
> > That's correct.  The docid is actually the query Term, without which
> > the other parameters don't (or barely) make sense.
> 
> But the draft specifically allows this (nonsensical or not):
> 
>    -  If docid is not included, and other parameters (besides host/port)
>       are specified, the client may use those parameters as "hints".
>       Various clients may choose to treat them as requirements, or as
>       preferences, or ignore them.

Yes, this is not clear.  I believe the intention was to say

     -  If docid is *empty*, ... [this applies only to z39.50s, not z39.50r]

In other words, the "?docid" construct would still be *included*, but would
be reduced to just "?".  Perhaps I should change the wording to make it
reduce the chances of interpreting the syntax as restrictive in this case.

>   The draft > also states:
> 
>    -  All other parameters are optional, however, if docid is present,
>       then database must be present.
> 
> Since database is only specifically mentioned as being required when docid
> is present, I believe one could reasonably read this as implying that
> database need not be present when parameters other than docid are present.

Yes, that sentence by itself might lead one to conclude that (again)
the syntax summary is more restrictive than it should be.  I think the
intention was simply to emphasize the importance of docid and database,
and it's confusing as stated.  Perhaps it should be removed.

> > > It seems that what is intended is something like:
> > >
> > >         z39.50s://host[:port]
> > >                 [/
> > >                         [database[+database...][?docid]]
> > >                         [;esn=elementset]
> > >                         [;rs=recordsyntax[+recordsyntax...]]]
> > 
> > Hmm.  I think this actually creates the problem you were trying to avoid.
> 
> I don't see it as a problem.  I think it's reasonable, as suggested above,
> to have parameters without docid which serve as hints.  Since, to quote the
> draft, "[f]uture extensions to these URLs will be of the form of
> [;keyword=value]", I also think it's quite conceivable to want to use
> parameters, especially yet-to-be-defined ones, without database or docid.
> (However, docid without database seems wrong.)  Hence my suggested syntax.

I agree that it is reasonable for some uses of URLs.  The thinking behind
these two Z39.50 URL schemes was to slice through a couple of important
special problem areas somewhat restrictively, and possibly create a third
scheme to implement more functionality (eg, a fully general Z39.50 URL)
as it was called for.

Do you have a specific application in mind that needs these hints today?

> > Does the following change make it clearer?
> > 
> >    -  If element set name (esn) is not specified, it is client's choice.
> >       If esn is specified, it should be used either within the Search
> >       request for the value of small- and/or medium- set-element-set-names
> >       or within a Present request following a Search.  These terms and their
> >       use are defined within the Z39.50 Standard [2].
> 
> Yes.  The next paragraph after that should also be changed:
> 
>    -  If record syntax (rs) is not specified, it is client's choice.
>       If one or more record syntaxes are specified, the client should
>       select one (preferably the first in the list that it supports) and
>       use it within a Search or Present request as the value of
>       PreferredRecordSyntax.

Right.  Thanks for catching that.

-John

Received on Tuesday, 21 March 1995 16:04:22 UTC