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.
