On Sunday, January 9, 2005, at 05:36 PM, Roy T. Fielding wrote:
Perhaps instead of making feed recursive, it would be better to have one more kind of document element to be used for aggregate feeds. For example:I just created a starting point for a proposal on making the feed element recursive, eliminating the need for RDF syntax, atom:head, and a bunch of things proposed in other paces regarding aggregators and digital signatures.
http://www.intertwingly.net/wiki/pie/PaceFeedRecursive
<aggregation xmlns="...(atom)...">
<feed>
<head>...</head>
<entry>...</entry>
</feed>
<feed>
<head>...</head>
<entry>...</entry>
</feed>
<feed>
<head>...</head>
<entry>...</entry>
</feed>
</aggregation>This would get rid of the problem of feeds of feeds of feeds..., but would raise a few questions:
* Does <aggregation> need a <head> and/or the kinds of things it contains>? I'd say yes, and it's role would be just like the feed/head in an aggregate feed based on PaceHeadInEntry.
* If one aggregates <aggregation>s, does one need to carry forward data from aggregation/head, and if so, how does one do that? I'd be willing to punt on this and say that it just can't be done. Allowing it would be similar to reintroducing feeds of feeds of feeds...
On the question of eliminating atom:head, if we go this route, we could eliminate entry:head, but feed:head was created for reasons other than enabling it to be embedded in entries.
The rationale for the pace states:
Simplifies description of the Atom syndication format to containers (feed, entry, content) and metadata that targets its own parent (feed or entry).I've been mulling over the question of what the hierarchical placement of an element means, and came up with the following possibilities for what a child element might be:
1) metadata about its parent (eg. modification date of an entry).
2) metadata about its parent's content??? For example, does <author> name the author of an entry, or of it's content? If we decide that metadata about the content itself must be an attribute in the content element itself, then we can eliminate this one.
3) the parent's content (eg. entries in a feed, content in an entry).
4) a container for other child elements just for convenience (eg. head in a feed)--which would mean that the container's children could be metadata about their grandparents, perhaps metadata about the grandparent's content, or the grandparent's content itself. Eliminating feed/head would eliminate this one. But remember that feed/head predates PaceHeadInEntry--it was created for a different purpose, so we may not want to be too quick to toss it out.
That's a slightly different view than what you describe, but not a whole lot--assuming 2 and 4 are gone, elements are either metadata about their parent, or their parent's content. Without understanding the format, one can't tell which a particular element is unless we did something like the following (which I am NOT advocating--I'm happy with applications having to know a little about the format if they care to distinguish):
<feed>
...
<entry isContent=1">
<title>...</title>
<link ... />
...
<content isContent="1">...</content>
</entry>
</feed>If we explicitly state that extension elements may only interact with other elements in their own namespace and with their immediate parents (ie. they may be metadata about or the content of their immediate parents, or may interact as defined in the extension with other elements from the extension), we eliminate problems with extension elements trying to influence the interpretation or handling of their siblings, and eliminate questions of inheritance from feed to entry (except with elements defined in the Atom core, a la <author>).
