Abstract
Creates a new option for the document element, <archive>, which can contain multiple feeds or instances of the same feed, in order to archive the states of a feed or feeds and the states of the entries published while the feed was in each of those states. Specifies that multiple instances of a resource with the same atom:id is illegal in Feed Documents, Entry Documents, and if PaceAggregationDocument2 as adopted, Aggregation Documents, but is legal in Archive Documents.
Status
New Proposal.
Rationale
-
Our charter speaks of creating an archive format.
-
If we wish to be able to archive multiple revisions of an entry or the contents of a feed's head in a single document, we must either specify that the atom:id of a resource be repeatable within a document intended as an archive, or that we invent some other method of identifying multiple instances of the same entry or feed metadata. Multiple instances within an archive type document would be simpler.
-
Multiple versions of an entry or feed in a non-archive document is unprecedented in syndication formats. In spite of the fact that changing feed metadata after an entry is published breaks the connection between the state of the feed metadata at the time of publishing the entry and the entry, this is how feeds have always worked, so no exception to the one-feed-instance-per-document rule need be made for Aggregation Documents--that is a special case reserved only for archiving.
Proposal
In section 2:
2. Atom Documents This specification describes three kinds of Atom Documents: Atom Feed Documents, Atom Entry Documents, and Atom Archive Documents. An Atom Archive Document contains an archive or an Atom feed or feeds, or one portion thereof. Its document element is atom:archive. ...and further down... start = atomFeed | atomEntry | atomArchive All three kinds of Atom documents are specified in terms of ...
Replace the first sentence of section 3.5 of draft-ietf-atompub-format-05.txt with the following (with the choice of alternate terms left to comments made during discussion and the discretion of the editors):
An Identity construct is an element whose content conveys a permanent, universally unique identifier for the resource (instantiated|described) by the construct's parent element. The content of an Identity construct MUST be unique within an Atom Feed Document or an Atom Entry Document; therefore, only one version of any resource MAY appear within those document types. Multiple versions of the same resource MAY appear within an Atom Archive Document, in which case, the contents of their Identity constructs would be identical.
In section 4:
4.X The "atom:archive" Element
The "atom:archive" element is the document element (i.e., top-level)
element of an Atom Archive Document, and acts as a container
for archives of one or more feeds or portions of feeds and metadata
associated with the archive. The first element child of atom:archive
MUST be atom:head, which MAY be followed zero or more atom:feed child
elements.
atomArchive =
element atom:archive {
atomCommonAttributes,
atomVersionAttribute,
(atomHead
& atomFeed*)
}
Multiple instances of the same atom:feed MAY appear as children of
atom:archive in order to reflect changes in the feed metadata.
Likewise, multiple instances of atom:entry elements MAY appears as
children of atom:feed children of atom:archive in order to reflect
changes in the content or metadata of the entry.
4.X.1 The "version" Attribute
atom:archive elements MUST have a "version" attribute whose content
indicates the version of the Atom specification that the feed
conforms to. The content of this attribute is unstructured text.
The version identifier for this specification is
"draft-ietf-atompub-format-05: do not deploy".
atomVersionAttribute =
attribute version {"draft-ietf-atompub-format-05 : do not deploy"}
Discussion of the atom:version attribute and atom:head element may be repeated or relocated under atom:archive and atom:feed as deemed best by the editors.
4.X The "atom:head" Element The atom:head element acts as a container for metadata about the containing feed or archive.
Impacts
Consumers that wish to be able to access archives would need to be able to handle one more type of Atom Document, which would add one level of hierarchy above <feed>.
Notes
The proposed text does not mention Atom Aggregation Documents, although they are discussed in the abstract and rationale. If PaceAggregationDocument2 is adopted, language consistent with the contents of the abstract and rationale will need to be added to the proposed text from that proposal.
