Yaron Goland wrote:
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 groupBelow 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?
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: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>
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: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.
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.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.