Subject: PaceIdConstruct2

From: "Bob Wyman" <[email-masked]>
Date: Sun, 3 Oct 2004 16:23:23 -0400

Graham Parks wrote:

        Whenever a resource appears in an Atom Document, its
        identifier SHOULD be the same as any other times it has
        appeared in an Atom Document, and MUST NOT be the same as the
        identifier currently or formerly used for any other Atom
        resource.  Changes to the content or location of the resource
        MUST NOT change the identifier.

This wording does not prohibit multiple instances of a single resource
appearing within a single Atom Document. It does, however, require that if
multiple instances of a single resource do appear in a single document, then
all such instances MUST have the same identifier.

As I read this, it tells me that if -- as a publisher -- I maintain a
resource which is: "The delay status at JFK airport", then all instances of
that resource MUST have the same atom:id even if two or more such instances
appear in a single Atom Document. This is, of course, consistent with a view
that says that an Atom Document is simply a sliding window on a potentially
infinitely long "feed" of atom entries. While the window at any time may
contain fewer entry instances then have been published to the feed, if the
window where expanded to match the "size" of the feed itself, then all
instances of all entries that had been published to the feed over time would
become visible. Thus, the maximal[1] Atom Document might contain multiple
instances of some resources, all of which would share a common atom:id.
Given that the maximal Atom Document might contain multiple instances of a
single atom:id, it appears to me reasonable that a less-then-maximal
instance of an Atom Document might also contain such multiple instances.

This "sliding window" view is, of course, the view that is maintained by
most aggregators. Their model of the feed contains not only those entries
which are most recently available in the Atom Document but also all those
entries that had been visible in the past. While for many purposes, we can
anticipate that aggregators will discard "old" entries that have the same
atom:id as newer entries, this behavior does not satisfy all requirements
and should not be considered a requirement. 

This discussion is, of course, one of the things that I was arguing some
months back should be covered by the "BAG" Blog Architecture Group... Atom
will be underspecified if we don't clearly define what a "feed" is and how
an Atom Document relates to a feed.

PaceIdConstruct 2 says further:
        A system that accepts input in Atom format that it
        subsequently outputs in Atom format SHOULD pass through the
        values of all identifiers.

This would seem to require that systems such as PubSub.com's, which create
Atom format feeds based on Atom format inputs, would be required to pass
atom:id's unchanged into the generated aggregate feeds. Given this
requirement, it would appear that we would also need a requirement that says
that atom:id's must be globally unique over all feeds and for all time. This
degree of uniqueness is necessary to ensure that identifier clashes do not
occur when multiple input sources are aggregated. If atom:id's are not
required to be universally unique (and in time) then it becomes virtually
impossible for an aggregator to safely do what PaceIDConstruct says that it
"SHOULD" since there will be considerable risk that in passing through
values unchanged, the aggregator will cause multiple resources to share a
single atom:id.

		bob wyman

[1] http://www.webster-dictionary.org/definition/maximal
	maximal - the greatest or most complete

---

From: Graham <[email-masked]>
Date: Tue, 5 Oct 2004 14:44:42 +0100

On 3 Oct 2004, at 9:23 pm, Bob Wyman wrote:

> appear in a single Atom Document.

Taken completely out of context, it does say exactly that. Your problem 
is that "resource" does not refer to a general purpose resource, but 
only to an Atom entry or feed. Before you start worrying about ids you 
first need to map your data to feeds and entries, which have their own 
rules and conventions (admittedly not specced yet). Imagine your 
service as an actual blog. Now I'd imagine you'd post a new entry for 
each update, with a category for each airport, and therefore possibly a 
feed for each airport. Alternatively you'd post an entry for each 
Airport, which you then update with the latest information. I have 
never seen a blog where multiple versions of the same entry appear 
separately on the home page.

Graham