I want to address issues raise by Mike Taylor.
- "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
- "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.
- "obscure transports (SOAP..."
We are essentially focused on SRU. No obscure transport there. A binding
for SRW (or what we now no longer refer to as such, but instead, "SRU Over
SOAP") will also be defined as part of the OASIS work, but so what?
- 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
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.
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
4. Result Set Size proposals
People have been screaming for this.
5. Multiple Query Types
Part of the "take-up" effort.
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.
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.
----- Original Message -----
From: "Mike Taylor" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, August 29, 2008 1:20 PM
Subject: Re: SRU/CQL 2.0: Invitation to participate in OASIS SWS TC
> Ashley Sanders writes:
> > > Really? It's hard for me to see how this is a good idea. Surely
> > > our problem at the moment is how to improve take-up of SRU as it
> > > currently exists --
> > What do you think might improve the take-up of SRU? Or put another
> > way, why do you think people are slow/reluctant to use SRU?
> Fragmentation. Too many choices. Adding yet another (or two more)
> can only make that problem worse. Where we _should_ have got to be
> now is that anyone wanting to do semantically rigorous searching
> across the Internet can quickly discover that SRU is The Right
> Answer. But we are a long, long way from that goal, and it's
> questionable whether we're even converging on it. Interoperability
> remains as elusive a dream as it was when SRU was first suggested.
> (More elusive, actually: at least Z39.50 had part of the field to
> itself back in those heady days.)
> > > Not to mention bringing the resulting protocol yet closer to the
> > > Z39.50 it was deliberately designed to simplify.
> > Is SRU simpler than Z39.50? Both use obscure transports (SOAP
> > v. ASN1 & BER) that have/had notorious interoperability problems.
> Really? I know that ASN.1 and BER are not everyone's cup of tea, but
> I've seen _very_ few interoperability problems at the transport
> layer. What Z39.50 interoperability problems I've seen have pretty
> much all been at the service level.
> Can't say the same for SOAP, of course.
> > Both come with an obscure query language that will be pretty
> > daunting to the newcomer.
> I suggest you go back and re-read the first few pages of
> :-) There is nothing there to daunt the _newcomer_. For experts, of
> course, there is plenty more to get your teeth into, but none of that
> author=kernighan and title=programming
> from doing what you expect.
> > If you want to simplify z39.50 I think you can go a whole lot
> > further than SRU.
> But I don't. What we're seeing with SRU compared to Z39.50 is
> _exactly_ what happened to XML with respect to SGML: conceived as a
> lighter, simpler version of its antecedent with all the extraneous
> extra complexity stripped away, it has inexorably increased in
> complexity until matching and finally surpassing the older standard.
> The lesson here is that if you want to do more than unfielded
> let-the-server-do-the-best-it-can-whatever-that-is text search, then
> you _do_ need all that complexity -- which, it turns out, was in
> Z39.50 for good reason.
> > And in the real world people do go a whole lot further than SRU and
> > go and create their own interfaces that hide behind urls that:
> > o) may or may not be HTML form driven
> > o) spit out a variety of stuff including HTML and XML.
> And for people who want to do that kind of thing, there is
> OpenSearch. Good luck to them.
> _/|_ ___________________________________________________________________
> /o ) \/ Mike Taylor <[log in to unmask]>
> )_v__/\ "There's no getting around it: to awesomely, boldy lead in an
> authentic way, you must be authentically awesome. There's no
> room for deception" -- Brant Hansen, _The 417 Rules of Awesomely
> Bold Leadership_