So am I.

LeVan,Ralph writes:
 > I believe you and I are in complete agreement.
 > 
 > Ralph
 > 
 > -----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
 > 
 > Amen.
 > 
 > Also, the semantics of what they're actually describing aren't the 
 > clearest. 
 > 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
 > 
 > SRU.
 > 
 > 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.
 > 
 > Rob
 > 
 > On Mon, 3 Dec 2007, LeVan,Ralph wrote:
 > 
 > > We are in the process of getting rid of the unnecessary boiler plate
 > in
 > > 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
 > on
 > >
 > >> 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
 > applications
 > >
 > >> 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
 > >