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

[Yaron Goland <yarong@xxxxxxxxxxxxx>]

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?

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>

Atom:title - In effect our 'titles' are really defined by our schemas which we defined using category. So I could imagine us doing something like defining static titles that map to specific schema entries. For example, if an entry represents an author then the schema would define a URL to author and we could associate with that some kind of static string such as "Author" that we could put in title. But this would blow huge amounts of bandwidth so my current plan is to just return empty Titles everywhere.

Atom:summary - Per section 4.1.2 of ATOM the Summary element is mandatory when the contents of an entry are linked to rather than provided by value. Linking is a big deal for us but we won't have any useful human readable information to put into summary. The 'real' value is in the scheme attribute on the category element. So, at worst, we would have to come up with an approach like the static string approach mentioned for Title but for now our plan is to just return empty summary elements when the summary element is required.

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.

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.
        The only way we have figured out how to address this problem within ATOM is to, in effect, lie. We return fully qualified HTTP URLs for each entry that map to their location in the data structure and include their various ids. The URL is not actually guaranteed to be unique forever. IDs can, in some cases, get re-used.