Subject: Re: Can we make Atom:Author, Atom:Title, Atom:Summary, Atom:updated and Atom:id optional?

From: Nikunj Mehta <[email-masked]>
Date: Wed, 20 Jun 2007 17:36:35 -0700

Yaron Goland wrote:
> Below I walk through a number of mandatory ATOM elements and explain that in many cases we either have no useful value for these elements or the values we have are potentially deceptive. Rather than wasting enormous amounts of bandwidth sending around empty elements in GET responses and even more bandwidth on having clients have to send these elements up to us on PUTs/POSTs (where we will ignore the submitted values) can we just make these values optional in ATOM?
>   
Of course, the Atom Syndication Format RFC (a standards track document 
since December 2005) would need to be changed to enable optional 
elements since the Atom syntax makes certain elements required and not 
the atom publishing protocol, which is the working group you have sent 
this email to. The syntax discussion can be held over at the atom-syntax 
group
> Atom:author - We don't track who authored what specific content because it is just overhead for us that doesn't actually fulfill any of our scenarios. In fact, given merging and other concerns, we don't always know for sure who authored what nor do we particularly care. Since we don't want to track this information but since we are required to return it the only thing I can figure to do is to return the minimal value which as near as I can tell would be: <author><name>a</name></author>
>   
There are a number of variations around the use of the author element. 
If the feed contains an author, then none is required in an entry. If an 
entry had a source that contained an author, again none is needed in the 
entry. Moreover, in Atom in general, when something is required, but no 
value applies, we have the possibility of empty elements. So, in your 
particular example, you could send <author><name/></author>.
> Atom:updated - Because of the problems inherent in tracking changes with dates (e.g. why eTags were introduced into HTTP) we may not have any clock information about our entries. E.g. we literally have no data to put into an atom:updated entry. Right now the only solution we have come up with is to just return <updated>0001-01-01T01:00:00</updated> everywhere. Since our data sets don't have duplicates of the same ID we don't have to worry about screwed up ordering.
>   
The <updated> element was never intended to replace ETags. If anything, 
it is meant to allow propagating an epoch from the author/editor of an 
entry to its reader.
> Atom:id - It is very rare for us to have a globally unique identifier for an entry. We will sometimes do this for top level entries but usually their children have identifiers that are only unique within a particular scope and even then are subject to re-use. E.g. we may have a counter to specify IDs for all of our location elements but if an entry gets deleted it is not beyond the realm of possibility for that counter value to get re-used on a different entry in the future. This is much the same problem as HTTP has when people use anything other than a PURL style URL. E.g. the URL should always point to the same object but that could change.
>   
If when an id is reused, it requires the processor of the entry to 
process the entry as a new entry, then this is a problem. In other 
words, if it doesn't matter to any processor that you reused an entry, 
then, by all means, reuse the entry id in an otherwise new entry. There 
is no requirement, IIUC, in HTTP to have a URL always point to the same 
object. It does point to a particular resource, but the resource could 
be as dynamic as the current temperature (which changes every now and 
then) or as static as the specific gravity of water.