 |
 |
Mike, Hrm, how about I recast that in saying 'primarily used in the library setting'. MARC isn't 'library specific', either. I understand the aims of SRU making it more accessible than Z39.50 (and, lord knows, it does). And I'm not sure I'm saying that SRU has failed or even needs to be changed. My question is just, if existing (and I understand the fact that it /didn't/ exist when this was being fleshed out) technologies are out there, starting to gain momentum, at what point do we figure out ways to coopt those technologies, rather than compete? My fear is that we can make SRU as accessible and as use-case-neutral as we want, but I'm not sure I see a lot of adoption outside of the library sphere. Meanwhile, OpenSearch gets integrated into all the major browsers, you know? I don't know how to write this in a way that doesn't come off fatalistic or confrontational -- since that's not what I'm going for. -Ross. On 9/29/06, Mike Taylor <[log in to unmask]> wrote: > Ross Singer writes: > > Could APP not just be extended and namespace to meet your need? > > > > At least then, even if, yes, we're using some niche namespace for > > the specific functionality you mention here, it's built on a > > foundation that isn't so /totally/ library specific that others > > could pick it up and use it on top of their existing systems (or, > > at the mininum, the parts they support). > > Hi, Ross. Out of interest, what makes you describe SRU as "library > specific"? > > I ask because that was a perception that we explicitly wanted to get > away from in moving from Z39.50 to SRU, and it's a bit dispiriting to > see how totally we failed :-) > > _/|_ ___________________________________________________________________ > /o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk > )_v__/\ "Arboreality does not correlate with pelvis shape" is an > interesting conclusion, but it's hard to get a paper of more > than seven words out of it. > >