+1 on all points made so clearly below and specially the conclusions.
I agree that by adopting ATOM as the default, required canonical
response format, we have no loss of functionality and that
it is really a minor syntactic change, albeit one that brings many
benefits to the final spec.
Matthew J. Dovey wrote:
> I would support dropping the list of alternatives, as I think discussion
> about retaining the existing SRU response format (were we to adopt ATOM)
> as premature.
>
> If we adopt ATOM, there are two reasons for retaining the existing
> response format:
>
> a) because it offers additional functionality beyond ATOM
> b) for backwards compatibility to existing SRU implementations
>
> I think we agreed that (b) is really not a driving motivation - that had
> we not been persuing the OASIS standard, we would have been working on
> SRU 2.0 and it had been agreed that major version revisions would not
> guaranteed backwards compatibility.
>
> We don't know yet what other proposals would also break backwards
> compatibility. I would therefore suggest that we shelve that whole
> debate until we have a better idea what the spec will look like. Then
> *if* there are some simple tweaks to enable backwards compatibility we
> can look at those.
>
> (b) is of greater interest - if there are things we can do with the SRU
> response which can't be done via ATOM, then this may provide arguments
> against the adoption of ATOM.
>
> My own impression is that adopting ATOM will really be just a syntactic
> rewrapping of the response content with not major changes to the content
> itself, so converting between the SRU response and an ATOM response is
> something that a fairly trivial XSLT could achieve. My preference would
> be for supporting only one response format, and let people build SRU -
> OASIS WebSearch gateways.
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
