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
>