Ray Denenberg, Library of Congress writes:
 > I want to address issues raise by Mike Taylor.

Thanks for this Ray.

I'm sure neither of us wants to get embroiled in a long philosophical
discussion, so I will be very brief and only respond to specifics.

 > -  "Take up".
 > 
 > That's really what this is all about, for the most part. Extending
 > SRU to accomodate requirements from other communities: geospatial
 > and LOM for example.

Profiling.

 > - "Fragmentation.  Too many choices."
 > 
 > Do you mean "Too many ways to do a given thing", or "too many given
 > things"?  The first "too many ways to do a given thing" was Z39.50s
 > problem, and I don't see that happening here.  And those who
 > participate in this process can make sure it doesn't.

The former.

 > - Complexity added by new features.
 > 
 > Let's look at the ones suggested so far:
 > 
 > 1. Allow Non-XML Record Representations
 > A near-trivial change: extend the controlled vocabulary of values for the
 > recordPacking parameter.

Adds significant complexity to implementations.

 > 2. Proximity
 > Proximity is believed by many to be broken.  Mike, If you don't consider it
 > to be, and you therefore feel we should not tinker with it, then you should
 > participate in the discussions.

AFAIK, one (1) person in the world has specific actual problems with
CQL proximity, as opposed to a Computer Sciency interest in playing
with it.  From what little I've heard of the proposed solutions, they
are much worse than the problems.  Most importantly, if we change prox
syntax, then we break compatibility with earlier versions, and that is
a disaster.

 > 3. Faceted Searching
 > There have been a number (more than one) of calls to add faceted search
 > capability to SRU. From initial discussions it does not appear that it will
 > be difficult.

Good.

 > 5. Multiple Query Types
 > Part of the "take-up" effort.

Total disaster for interoperability.  "Take-up" of a supposedly
interoperable standard is meaningless if "taking up" consists of
continuing to do what you were doing already and slapping an "SRU"
label on it.  One query type to bring them all and in the, er, light,
bind them!

 > 6.  Eliminate the Version and Operation Parameters
 > This is a simplification, not added complexity.  And there will be an annex
 > included on how a 2.0 system can interoperate with a lower-version.

Broken.

 > 7. Alternative Response Formats
 > Too complicated to cover in this message. I know how you feel about it.
 > Again, if you feel so strongly you should participate in the
 > discussion.

Broken.

I wonder how many of the people on this list will undertake to
actually implement the results of this round of respecifying.  My
guess is, somewhere between zero and two.

 _/|_	 ___________________________________________________________________
/o ) \/  Mike Taylor    <[log in to unmask]>    http://www.miketaylor.org.uk
)_v__/\  "I could be arguing in my spare time" -- Monty Python's Flying
	 Circus.