So am I.
> I believe you and I are in complete agreement.
> -----Original Message-----
> From: SRU (Search and Retrieve Via URL) Implementors
> [mailto:[log in to unmask]] On Behalf Of Dr R. Sanderson
> Sent: Monday, December 03, 2007 4:24 PM
> To: [log in to unmask]
> Subject: Re: Say NO to mandatory Atom Feeds
> Also, the semantics of what they're actually describing aren't the
> The <id> element, for example, is not dc:identifier for the object
> described in the data, it's an arbitrary id of that particular entry in
> that particular feed. (As I understand it)
> Which makes perfect sense in an ATOM feed. And is totally meaningless in
> Unless someone can get the powers that be to de-mandatory-ify the
> elements, it still seems inane to me to be changing all this stuff just
> for the sake of changing it. If someone can't parse an XML response,
> then they should quickly get out of the business of writing IR clients.
> On Mon, 3 Dec 2007, LeVan,Ralph wrote:
> > We are in the process of getting rid of the unnecessary boiler plate
> > our standard. I do not want to see it replaced with new boiler plate
> > that has even less value than the old.
> > I would be happy with a proposal that we just ignore those mandatory
> > elements, but I will not be putting in bogus values just to satisfy a
> > meaningless requirement.
> > Ralph
> > -----Original Message-----
> > From: SRU (Search and Retrieve Via URL) Implementors
> > [mailto:[log in to unmask]] On Behalf Of Farrukh Najmi
> > Sent: Monday, December 03, 2007 2:28 PM
> > To: [log in to unmask]
> > Subject: Re: Say NO to mandatory Atom Feeds
> > LeVan,Ralph wrote:
> >> I've been giving more thought to SRU responses and have come to the
> >> conclusion that the Atom Feed document should not be a mandatory
> >> response format and should certainly not be the sole mandatory
> >> response format.
> >> The problem is that Atom Feeds were not intended for dynamically
> >> generated search results and have mandatory elements that are
> >> important for syndicated blog feeds but are meaningless for us.
> >> Specifically, they are the author, id and updated elements required
> >> every response. I can live with the mandatory title element, but the
> >> others don't work.
> > I had responded to above issues in an earlier email on this list. See
> > recap below...
> > What do you see as issues in the solution I proposed?
> >> I'm still interested in figuring out how to use Atom Feeds as a
> >> possible alternative response. It is clear that there are
> >> that want to use them. I just hope that their assumption that they've
> >> just gotten a list of blog entries from me matches up with the user's
> >> expectation that they just got a list of documents.
> > Farrukh Najmi wrote:
> >> Dr R. Sanderson wrote:
> >>> On Tue, 13 Nov 2007, Ray Denenberg, Library of Congress wrote:
> >>>> Let's see if this comes out better. A sample response record in
> > ATOM:
> >>> As Ross points out, ATOM has some requirements for validation. In
> >>> particular there's quite a few mandatory elements both at the feed
> >>> level and the entry level which aren't quite so easy to map into the
> >>> SRU response while retaining the ATOM semantics, or without adding
> >>> extra requirements to implementers. For example the updated time for
> >>> the record.
> >>> Rob
> >> There are only a handful of mandatory properties AFAIK.
> >> Implementations typically should know when a record is updated. The
> >> search-ws spec can specify that implementations that do not have this
> >> ability use a fixed time that can never be used in reality (e.g.
> >> 1900-00-00T00:00:00Z ).
> >> Other mandatory values like those below can be required to have a
> >> value of "Unknown" if implementations do not support this.
> >> /atom:feed/atom:entry/atom:title
> >> /atom:feed/atom:author/atom:name
> >> /atom:feed/atom:author/atom:email
> > --
> > Regards,
> > Farrukh Najmi
> > Web: http://www.wellfleetsoftware.com