Okay, time to respond to this message:
On Monday, November 15, 2004, at 02:15 PM, Henry Story wrote:
On 15 Nov 2004, at 16:55, Antone Roundy wrote:Other differences:I don't understand introspection that well either. But I suspect there would be no harm with Entries having introspection files too.
* introspection - I'm not up on what the introspection file is all about enough to comment on this one
My vague impression is that an entry has no need for introspection. Comments anyone?
* generator - I don't see this making sense in entryWell, why not? This could make a lot of sense for aggregator feeds, it seems to me.
The aggregator is responsible to ensure that it's output is well-formed and valid, regardless of what it gets from its source feeds. I'd say that makes it the generator. (That might be an argument for removing atom:generator from atom:head when aggregating if PaceHeadInEntry is accepted). Conceptually though, you're right, SOMETHING is generating the entry.
* content - I don't see this making sense in headWhy not: Add a bit of nice content to the head, for richer news readers may be quite nice. It works out quite nicely for James Gosling's blog [1]
Okay, I'll buy the argument that sometimes the context can contain content. A comments feed is probably the best example. But the nature of that content feels different--or at least like it would often be. The fact that it's expendable at the feed level but central to an entry is part of that. In some cases, feed/head/content would be more like metadata than content.
* origin - I don't see this making sense in headGood one. I don't know about this.
Perhaps this would make sense in the case of a feed inside a feed: namely responses to someone's entry. If you think of the responses as constituting a feed with the original post as the "head" then this feed would in fact have an origin feed.
If PaceHeadInEntry is adopted, I expect we'll drop atom:origin, so this won't be an issue.
* id: required in entry, not in head - as it should beMhhh. I had not realized that the id was mandatory in atom entries.
Of course if you think about using the Atom API for setting your feed head entry, then it would not be silly for your entry to have an id.
I'm not subscribed to the protocol list, and haven't kept an eye on the API, so perhaps someone else could speak to this better than me. Can the API be used to edit atom:head? If so, how does one identify which feed's head is being manipulated? I'm sure you COULD have a different URI for each feed, but I would also expect that the API would support manipulating multiple feeds via the same URI. So it's easy to imagine both cases where you would and wouldn't need a feed ID. Should a feed ID be required?
* if tagline becomes summary, the fact that it's sometimes required in entry, but never in head - as it should beYes. But why do you really want to make it required for a feed?
I don't, which is what I meant by "as it should be".
It looks to me like MOST of the structural differences between atom:head and atom:entry can be resolved, but I still question whether there's enough value in merging their descriptions in the spec to justify the work for the editors, the messiness of having to explain of the differences, and the risk of it causing misunderstandings.
Ultimately though, IF we were to alter the structure of head and entry to make them VERY similar, I wouldn't put up a stink about it either way.
