Re: new draft of Z39.50 URL specification

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.

> > As written, the syntax for z39.50s does not seem to allow for other
> > parameters without the presence of docid:
> 
> 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.

> > Furthermore, the draft implies that other parameters may appear without the
> > presence of database name(s).
> 
> Did you notice that the ']' matching the first '[' comes at the end
> (as drawn)?  This means that other parameters may only appear if a
> database name (at least one of possibly several) is given.

Yes, I did notice it.  In fact it's the crux of my comments.  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.

> > 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.

> 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.

Mike
mgursky@cdplus.com

Received on Tuesday, 21 March 1995 14:23:28 UTC