 |
 |
Ray I agree with Pat on this - but this is exactly the kind of comemnts I was expecting to see from some ZIG folks - I think we need to make very clear what we are doing (as Pat said) to try and blunt this kind of criticism and also not give the sense of being autocratic and dictorial mark On Fri, 13 Jul 2001, Stevens, Pat wrote: > Ray > > The answer is that this is an experiment to see if this approach would work. > If Jo is right, it won't. I think we should stick to the decision we made. > We will take in implementers who want to work within the framework outlined. > After we try it out, we will be in a better position to know if this can > move us forward. > > At this point, we are experimenting towards a Z39.50 ng not going through a > standards process to build it. > pat > > -----Original Message----- > From: Ray Denenberg [mailto:[log in to unmask]] > Sent: Friday, July 13, 2001 9:53 AM > To: [log in to unmask] > Subject: [Fwd: Re: "Z39.50 Next Generation"] > > > Please give me opinions on whether I should subscribe people to this list > (on a > selective basis) like Joe, who is disgruntled about this whole thing (see > below), or Alan Kent, who I suspect would like to participate, etc. --Ray > > -------- Original Message -------- > From: "Johan Zeeman" <[log in to unmask]> > Subject: Re: "Z39.50 Next Generation" > To: <[log in to unmask]> > > 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. >