Thoughts about how we interpret Atom UUIDs.

UUID specification is available here.

The Atom spec says this about IDs:

The "atom:id" element conveys a permanent, universally unique identifier for an entry or feed.

And it goes on to say:

When an Atom Document is relocated, migrated, syndicated, republished, exported, or imported, the content of its atom:id element MUST NOT change. Put another way, an atom:id element pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their atom:id elements.

It also suggests:

It is suggested that the atom:id element be stored along with the associated resource.

This initially led us to think that the id, a uuid, should be the uuid of the object in Zope, because it is stored on the object. However, a closer reading of the first and second quote suggest that, while it is pragmatic to store the id on the "associated resource," it is the feed and entries that have IDs, not the objects, as there is not necessarily a one to one mapping between the objects and the entries.

This was further confirmed by the idea that a single container in Zope may have multiple atom feeds, with different parameters: recursive vs non-recursive, including only certain entry content types versus including everything, etc. This requires a container to have multiple associated IDs, one for each feed, not just one ID for the container shared by all feeds.

It is an open question whether a single object serving as the source for entries in multiple feeds should have multiple IDs (one for each feed it is in) or not.

This rethinking led to the conclusion: "Thus, we will not attempt to create a generic UUID package, but will only specifically implement UUIDs inside of Vice for the sole purpose of syndication.  Also of note, the current implementation does not include a mechanism for retrieving a document by UUID." However, upon discussions with Florian Schulze, we revised our plan.

We now will create a generic UUID package. This package will be modeled on the intid facility. UUIDs will not be stored as annotations on their objects or directly in ISyndications annotations, but in catalogs. There will be one catalog of feed UUIDs that contains UUIDs for all the feeds in a site; this catalog will be site local. Additionally, there will be zero or more catalogs of feed entry UUIDs, one catalog for each feed; this catalog will be local to the corresponding ISyndication annotation. Each catalog will be implemented as a pair of OOBTrees, one that maps from a KeyReference to a UUID and another that maps from a UUID to a KeyReference.

This is an architecture diagram of how the UUID utility will be used in Synz with Atom feeds:

• Not using an annotation makes import and export harder. How will UUIDs be stored on export? How will they be retrieved on import?