Fw: "Z39.50 Next Generation"

Sent this to Ray only by mistake.  Outlook Express seems to misinterpret the
headers supplied by the W3C list manager.

J.

----- Original Message -----
From: "Ray Denenberg" <rden@loc.gov>
To: "Johan Zeeman" <j_zeeman@hotmail.com>
Sent: Friday, July 13, 2001 12:42 PM
Subject: Re: "Z39.50 Next Generation"


> Joe -- Please post your concerns to the ZIG list; the other participants
will
> pick up the discussion.  I'll be away (on vacation) until July 16 and
won't be
> able to join in further until then.  Meanwhile see the response I posted
to Rob
> Bull.  --Ray
>
>
> Johan Zeeman wrote:
>
> > I am pretty unhappy at having this sprung upon us as a fait accompli by
a
> > really quite secretive group of implementors.  There has been no
declaration
> > that this group was active.  There has been no invitation to participate
or
> > be kept informed.  There has been no discussion of requirements. There
has
> > been no attempt to arrive at any kind of consensus on technical
approaches
> > to a problem that many, if not all of us, wish to see addressed.
> >
> > I think that some of the basic premises of the group are simply wrong.
For
> > instance, the statement that distinct search and present services either
"do
> > not fit well in the contemporary implementation-environment" or "are
> > outmoded".  Just because some implementors don't like the distinction
> > doesn't make the distinction irrelevant. If a single service is used,
the
> > message must still include information to allow the server to decide
whether
> > a new search is being made or not, especially since the result set model
> > remains.  The is little benefit in rolling these into a single message,
and
> > especially, there is no removal of any "barrier to implementation" - the
> > same amount of implementation work is required whether a single message
type
> > is used or two separate ones .
> >
> > I would also like to have the rationale for abandoning RPN explained.
This
> > strikes me as a serious loss, especially as RPN can easily be carried in
> > XML.  Inventing a new query language to compete with XQL is just dumb.
We
> > all know which will win.   If the justification is, as I suspect, to
allow
> > queries to be carried in URLs then I think the requirement for URL
support
> > should be re-examined.  If you don't like bib-1, then develop  new
attribute
> > sets designed to work better in the Web environment.
> >
> > A standard that lets the same thing be done 2 ways (URL and XML) is
going to
> > fail.  Pick one, folks.  My vote would be for SOAP.  Unfortunately, I
don't
> > seem to get to vote.
> >
> > J.

Received on Friday, 13 July 2001 16:14:50 UTC