On Tuesday, November 16, 2004, at 10:40 AM, Bob Wyman wrote:
I view "Feeds" as streams of entries and explain away the various
syntactical oddities as markup-minimization and reuse of <head/> via
inheritance. An entry is simply a feed which provides only one "content"
element (which we call an "entry"). A compound feed is a stream of entries
in which it is not always possible or not correct to attempt to "reuse" the
context provided by a single <head/> element.
I just spent a while writing an meandering exploration of this issue, which I won't bore you with, but in the end, I came to the conclusion that a feed is not an entry and an entry is not a feed.
A feed is a context in which content is published. Sometimes it is the original context of the content, and sometimes it is a context in which content originally from another context is redistributed. atom:head is a container for metadata describing the context.
atom:entry is a container for both the content and metadata describing the content.
I think the question is, are context and content different forms of the same thing, and I think the answer is no. Although there are cases, like comment feeds, where the context is an entry, that's more of a coincidence than a description of the nature of a feed.
So assuming that we agree that content and context aren't different forms of the same thing, then what about the metadata describing content and the metadata describing context? In other words, if Atom looked like this:
<context>
<context-metadata>
<title></title>
<link ... />
</context-metadata>
<content>
<content-metadata>
<title></title>
<link ... />
</content-metadata>
<actual-content>Here's the content</actual-content>
</content>
</context>... then are <context-metadata> and <content-metadata> the same thing? (Till now, we've been asking whether either <context> or <context-metadata> and <content> are the same thing, which I think they're not).
I, for one, don't think so, despite structural similarities.
The final question is whether, due to the structural similarities, the written specification would benefit from consolidation of <context-metadata> and <content-metadata>.
Pro: * The spec would be shorter * We wouldn't have to duplicate various text * Any others?
Con:
* Where their structures diverge, it could create confusion over which elements are legal within context-metadata (atom:head) and content-metadata (atom:entry...we don't actually have a container within atom:entry, which is probably for the best). Yes, I know, the spec will make that clear, but it won't be clear by looking at the index, and a less than thorough reading of the spec text itself could miss the details.
* Any others?
Personally, I don't think the pros are that important (nice, but not important), but I do think the con is.
