Abstract
Remove atom:head, group entries with atom:entries instead. Allow feeds to contain atom:summary and atom:content (Folders are Resources Too!).
Diff from a format-05 feed: http://franklinmint.fm/2005/02/03/ongoingatom-diff.html
Use cases: http://www.imc.org/atom-syntax/mail-archive/msg12963.html
Status
Open
Rationale
Making a feed document strictly hierarchical and recursive solves a number of problems that have been previously attacked in a piecemeal fashion:
-
XML containment relates feed and entry metadata to the data being described, thereby defining a consistent model for future extension elements;
-
Multiple feeds can be aggregated and presented using a single data format without having to modify the entries within those feeds to incorporate their original feed metadata;
-
Digital signatures can be safely applied to feeds and entries without needing special-case exceptions on how to recreate the signature after aggregation;
-
Simplifies description of the Atom syndication format to containers (atom, feed, content) and metadata that targets its own parent (atom).
-
Allows Hierarchical feeds, comments.
-
No structural changes for format05 feeds in the simple case. Rename your elements, add "atom:feed" as a child.
-
Differentiates elements lower in a hierarchy from metadata.
-
Some aggregators let you subscribe to OPML.
More than one person thinks "atom:head" in "atom:entry" is a bad idea (not that they agree this Pace is the way to fix it).
![[WWW]](/moin-1.2.1/wiki/htdocs/classic/img/moin-www.png){kind=small}
Mark Nottingham: 4.2.1 Usage of "atom:head" within "atom:entry" -- This doesn't seem clean; I know that people have use cases for it, but I'd like to register my preference to get rid of it, FWIW.
Robert Sayre: If it were up to me, and I had to turn the draft in tomorrow, I would strike PaceHeadInEntry, because "it can easily be added later".
"Don't think for a second that your format contains more data that the current flat format," --Graham
I would hope not -- the point was to make that data available such that it would not have to be replicated in every entry.
Example
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<?xml-stylesheet
href="http://www.blogger.com/styles/atom.css" type="text/css"?>
<atom xmlns="http://purl.org/atom/ns#">
<title>bloggerDev Google Group</title>
<subtitle>
For discussion of development related to the Blogger API. And
stuff. This ISN&#39;T a list for Blogger technical support.
</subtitle>
<link href="http://groups-beta.google.com:/group/bloggerDev"
rel="alternate" title="bloggerDev" type="text/html" />
<updated>2005-01-20T01:48:00Z</updated>
<generator url="http://groups-beta.google.com:" version="1.99">Google Groups</generator>
<feed>
<atom>
<author>
<name>Randy Charles Morin</name>
<email>randymo...@gmail.com</email>
</author>
<published>2005-01-19T02:05:21Z</published>
<updated>2005-01-19T02:05:21Z</updated>
<id>http://groups-beta.google.com/group/bloggerDev/browse_thread/thread/b30482ac4e0d3931</id>
<link href="http://groups-beta.google.com/group/bloggerDev/browse_thread/thread/b30482ac4e0d3931"
rel="alternate" title="Universal Subscription Mechanism" type="text/html"/>
<title>Universal Subscription Mechanism</title>
<summary type="HTML">
How quickly can we get Blogger<wbr>
to support the USM? <br> <a target="_blank"
href="http://www.kbcafe.com/rss/usm.html">[link]</a>
<br> With USM support, you simply c<wbr>lick on the
orange XML/RSS ico<wbr>n or Atom <br> icon and the
feed is added to <wbr>your RSS aggregator. <br> I've
already written a client <wbr>for my Yahoo, which I call,
th<wbr>e Yahoo! <br> solution ;) <br> <a
target="_blank"
href="http://www.kbcafe.com/rss/?guid=20050118154018">[link]</a>
</summary>
<feed>
<atom>
<author>
<name>steve jenson</name>
<email>ste...@google.com</email>
</author>
<published>2005-01-20T01:48:00Z</published>
<updated>2005-01-20T01:48:00Z</updated>
<id>http://groups-beta.google.com:/group/bloggerDev/msg/bef049ee0ccacb4f</id>
<link href="http://groups-beta.google.com:/group/bloggerDev/msg/bef049ee0ccacb4f"
rel="alternate" title="Re: [bloggerDev] Re: Universal Subscription Mechanism" type="text/html" />
<title>Re: [bloggerDev] Re: Universal Subscription Mechanism</title>
<summary type="HTML">
I've only ever seen him drink <wbr>Diet Dr. Pepper.
Well, that an<wbr>d scotch. <br> <p>-steve
</summary>
</atom>
<atom>
<author>
<name>Danny Ayers</name>
<email>danny.ay...@gmail.com</email>
</author>
<published>2005-01-19T22:18:05Z</published>
<updated>2005-01-19T22:18:05Z</updated>
<id>http://groups-beta.google.com:/group/bloggerDev/msg/ad4c85537041d860</id>
<link href="http://groups-beta.google.com:/group/bloggerDev/msg/ad4c85537041d860"
rel="alternate" title="Re: [bloggerDev] Re: Universal Subscription Mechanism" type="text/html" />
<title>Re: [bloggerDev] Re: Universal Subscription Mechanism</title>
<summary type="HTML">
Ah. <br> <p>But can *he* make coffee..?
<br> <p>-- <br> <p><a
target="_blank"
href="http://dannyayers.com">[link]</a>
</summary>
</atom>
</feed>
</atom>
</feed>
</atom>
Proposal
in section 2:
2. Atom Documents
This specification describes Atom Documents.
namespace atom =
"http://purl.org/atom/ns#draft-ietf-atompub-format-05"
start = atomAtom
Atom Documents are specified in terms of the XML
Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and
identified with the "application/atom+xml" media type. Atom
Documents MUST be well-formed XML.
Atom constrains the appearance and content of elements and
attributes; unless otherwise stated, Atom Documents MAY contain other
Information Items as appropriate. In particular, Comment Information
Items and Processing Instruction Information Items SHOULD be ignored
in the normal processing of an Atom Document.
[[ discussion of URI escaping and i18n, IRI ]]
[[ discussion of white space ]]
2.1 Metadata and Content
Atom Documents consist of "container" and "metadata" elements.
All elements are properties of the container element which encloses them.
[[ RNC stuff ...]]
2.2 Extending Atom
Atom is extensible. All extension elements are considered to be
"metadata" elements. See the section titled 'Extending Atom' later in
this document for a full description of how Atom Documents can be
extended.
2.4 Common Attributes
Any element in an Atom Document MAY have an xml:base attribute. XML
Base [W3C.REC-xmlbase-20010627] processing MUST be applied to any
relative reference [RFC3986] present in an Atom Document. This
includes such elements and attributes as specified by Atom itself, as
well as those specified by extensions to Atom.
Any element in an Atom Document MAY have an xml:lang attribute, whose
content indicates the natural language of the element's content.
Requirements regarding the content and interpretation of xml:lang are
specified in XML 1.0 [W3C.REC-xml-20040204] Section 2.12.
atomCommonAttributes =
attribute xml:base { atomUri }?,
attribute xml:lang { atomLanguageTag }?
In section 4:
4.1 Container Elements
Container elements are used to group metadata and content.
4.1.2 The "atom:atom" Element
The "atom:atom" element acts as a container for metadata and data.
atomAtom =
element atom:atom {
atomCommonAttributes,
(atomFeed?
& atomTitle
& atomSubtitle?
& atomId
& atomLink*
& atomUpdated
& atomPublished?
& atomAuthor?
& atomContributor*
& atomGenerator?
& atomCopyright?
& atomCategory*
& atomSummary?
& atomContent?
& anyElement*)
}
The following child elements are defined by this specification (note
that the presence of some of these elements is required):
o atom:atom elements MAY contain exactly one atom:feed element.
o atom:atom elements MUST contain exactly one atom:title element.
o atom:atom elements MUST contain at least one atom:link element
with a relation of "alternate".
o atom:atom elements MUST NOT contain more than one atom:link
element with a rel attribute value of "alternate" that has the
same type attribute value. atom:feed elements MAY contain
additional atom:link elements beyond those described above.
o atom:atom elements MUST NOT contain more than one
atom:author element.
o atom:atom elements MUST NOT contain more than one
atom:contributor element.
o atom:atom elements MUST NOT contain more than one
atom:copyright element.
o atom:atom elements MUST contain exactly one atom:id element.
o atom:atom elements MUST contain exactly one atom:updated element.
o atom:atom elements MUST NOT contain more than one atom:published
element.
o atom:atom elements MAY contain any number of atom:category
elements.
o atom:atom elements MUST NOT contain more than one atom:summary
element.
o atom:atom elements MUST NOT contain more than one atom:content
element.
4.1.1.1 The Root Element
The atom:atom element has some additional requirements when it
is the root element of an Atom document.
o atom:atom elements MUST contain exactly one atom:author element.
If the root element's atom:link element with type="alternate" resolves to
an HTML document, then that document SHOULD have a autodiscovery link
element [Atom-autodiscovery] that reflects back to the Atom document.
4.1.2 The "atom:feed" Element
The "atom:feed" element represents Atom documents that are
lower in a hierarchy than the containing atom:atom element.
atomFeed =
element atom:entries {
atomCommonAttributes,
(atomAtom*)
}
4.2 Metadata Elements
[[ Alphabetical listing of metadata elements... ]]
[[ Fix wherever it says "Atom Feed or Entry"]]
Remove "The atom:head element"
Impacts
"Everything. PaceHeadInEntry is no longer needed. Dozens of other paces become obsolete or changed due to simplifying the data model."
* Requires atom:author and atom:id on the document element.
* Assumes there's no atom:post, atom:edit, atom:introspection, atom:info, or atom:host. Removal of cruft left us with almost exactly the same element content in atom:entry and atom:feed.
Notes
See Also: PaceFeedRecursive
