Tuesday, April 11, 2006, 11:17:07 PM, James M Snell wrote:
> This was specifically added in response to feedback provided on this > list. Although I don't have the link to the original thread, the > rationale has to do with aggregated feeds. Specifically, I may publish > an entry that does not have a license that you turn around and republish > in an aggregate feed that does have a license. If entries inherited the > licenses of their parents, that would mean that you would end up > distributing my content under a different license than what I had > originally intended, which you, of course, have no right to do. > Therefore, entries are licensed independently of the feeds in which they > happen to appear. Wise. It is a really bad idea to invent extensions that "inherit" in the way that atom:author does. Just think about how people are going to implement it: Look at Windows Feed Platform, as an example. It preserves entries with full fidelity (or should do), and preserves feed metadata with full fidelity (or should do). But most reasonable implementations won't preserve the exact feed documents that each entry came from - they'll probably just preserve the latest version of the feed metadata. So if you have: <feed> <author><name>Dave</name></author> <ex:tag>x</ex:tag> <entry> <id>...2</id> </entry> <entry> <id>...1</id> </entry> </feed> and later poll again, and get: <feed> <author><name>Someone Else</name></author> <ex:tag>y</ex:tag> <entry> <id>...4</id> </entry> <entry> <id>...3</id> </entry> </feed> Then a correct implementation does need to maintain the association between feed/author and the entries that appeared in that document, because that is required by the RFC, but that doesn't apply to extensions. Reasonable implementations will probably just store the latest versions of feed and entry metadata, something like this: <feed> <author><name>Someone Else</name></author> <ex:tag>y</ex:tag> <entry> <id>...4</id> <author><name>Someone Else</name></author> </entry> <entry> <id>...3</id> <author><name>Someone Else</name></author> </entry> <entry> <id>...2</id> <author><name>Dave</name></author> </entry> <entry> <id>...1</id> <author><name>Dave</name></author> </entry> </feed> If users of this data, attempt to perform "inheritance" on the ex:tag extension, they will corrupt the entries by assuming that the latest version of the feed metadata applies retrospectively to all previous entries. -- Dave
