OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [search-ws] OASIS/SRU: ATOM/SRU Response Schema


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.

Matthew

> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> Sent: 09 November 2007 21:56
> To: search-ws@lists.oasis-open.org
> Subject: Re: [search-ws] OASIS/SRU: ATOM/SRU Response Schema
> 
> Ok I think it's best to just take out the whole list (leave the rest
of
> the
> message intact). --Ray
> 
> ----- Original Message -----
> From: "Farrukh Najmi" <farrukh@wellfleetsoftware.com>
> To: "Ray Denenberg, Library of Congress" <rden@loc.gov>
> Cc: <search-ws@lists.oasis-open.org>
> Sent: Friday, November 09, 2007 3:34 PM
> Subject: Re: [search-ws] OASIS/SRU: ATOM/SRU Response Schema
> 
> 
> > Please see comments inline below..
> >
> > My feeling is that we need to narrow the options down some more
> rather
> > than just sending an enumeration of every combination.
> > I can live with the email as drafted if necessary.
> >
> > Thanks Ray.
> >
> > Ray Denenberg, Library of Congress wrote:
> > ...
> > > There are variations to this proposal, for example both formats
> could be
> > > mandatory. Or an implementation would have to support at least one
> but
> not
> > > both (on the theory that if a client supports one and server the
> other,
> then
> > > they probably weren't meant to interoperate).
> > >
> > > So the possibilities are:
> > > 1. ATOM mandatory, SRU optional.
> > >
> >
> > Suggest replacing above with:
> >
> > "1. ATOM mandatory, SRU optional and marked as deprecated. This
> indicates
> that a future version of SRU will likely drop support for it."
> >
> >
> > > 2. Support for both formats mandatory.
> > > 3. Support for the SRU format mandatory,  ATOM optional.
> > > 4. Must support at least one of the two, SRUor ATOM. (The explain
> record
> > > would indicate what formats are supported.)
> > > 5. No mandatory response format. (Explain.)
> > >
> >
> > Above is really quite unworkable for interop. Suggest dropping it if
> > possible.
> >
> > > 6. Server must support both SRU and ATOM, and client at least one.
> > >
> > Above is really redundant with (2). Also this spec should not make
> any
> > demands on the client other than it should be designed to work the
> SRU
> > interface.
> >
> > > 7. Client must support both SRU and ATOM, and server at least one.
> > > (Explain.)
> > >
> >
> > IMHO, above does not make sense to include. Also this spec should
not
> > make any demands on the client other than it should be designed to
> work
> > the SRU interface.
> >
> > > Note that there is a new request parameter proposed,
> 'responseFormat',
> so
> > > the client can indicate which format it wants.
> > >
> > > In any case, a "flavor" of ATOM would be specified in the standard
> which
> > > would call out (namespaced) elements similar to those in the
> current SRU
> > > schema -- globally: <version>, <numberOfRecords>; and per record:
> > > <recordSchema>, <recordPacking>, <recordPosition>.   So the full
> > > functionality of the SRU response schema can be provided.
> > >
> > > The TC solicits ideas from SRU implementors on this issue.
> > >
> >
> >
> > --
> > Regards,
> > Farrukh Najmi
> >
> > Web: http://www.wellfleetsoftware.com
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]