Subject: Re: Feed License Draft

From: "John Panzer" <[email-masked]>
Date: Tue, 11 Apr 2006 14:41:40 -0700

I'd like to support this in our products, and I'm curious as to why the 
feed licence isn't inherited (by default) by the entries within a feed. 
  Seems like this would require a lot of duplicate licence information 
in the most common case, where the feed and its entries have exactly the 
same licence.  It's not a huge issue but if there's a good reason why 
this rule is in place it would be good to know.

-John Panzer

James M Snell wrote on 1/27/2006, 4:17 PM:

 >
 > Just an editorial clean up of the draft. No significant technical
 > changes.  This draft should now be considered complete.  I've stumbled
 > across a number of feeds in the wild using the extension and know of at
 > least one blog vendor and one feed reader with plans to implement.
 >
 > 
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-05.txt
 > - James

-- 
Abstractioneer John Panzer
System Architect
http://abstractioneer.org

---

From: James M Snell <[email-masked]>
Date: Tue, 11 Apr 2006 15:17:07 -0700

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.

- James

---

From: "John Panzer" <[email-masked]>
Date: Tue, 11 Apr 2006 17:45:00 -0700

Thanks, that actually makes a lot of sense.  It's also helpful in 
resolving ambiguities regarding CC "NoDeriv" licences applied at the 
feed level, I think.

---

From: David Powell <[email-masked]>
Date: Wed, 12 Apr 2006 12:27:39 +0100

> Therefore, entries are licensed independently of the feeds in which they

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

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 12 Apr 2006 14:29:00 +0200

* David Powell <[email-masked]> [2006-04-12 13:40]:
> Reasonable implementations will probably just store the latest
> versions of feed and entry metadata, something like this:

Of course, what they *should* do is use `atom:source` so that
they can preserve all of the feed metadata, including RFC4287
Sec.6 extensions:

    <entry>
      <source>
      </source>
      <id>...2</id>
    </entry>

    <entry>
      <source>
      </source>
      <id>...1</id>
    </entry>

    <entry>
      <source>
      </source>
      <id>...4</id>
    </entry>

    <entry>
      <source>
      </source>
      <id>...3</id>
    </entry>

(Whether this is wrapped inside `atom:feed` or each entry is
stored separately is not relevant.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: David Powell <[email-masked]>
Date: Wed, 12 Apr 2006 14:05:48 +0100

> they can preserve all of the feed metadata, including RFC4287

Using atom:source is fair enough for representing loose entries, but I
think it is overkill for representing entries in the context of a
known feed, where the vast majority of feed metadata is going to be
the same for each entry.

I believe feed metadata to be about feeds, and entry metadata to be
about entries. Two separate entities, with their own life-cycle. There
is one feed, if I change the title of it, then the feed title should
change.  I don't expect it to change back to the old title whenever I
look at older entries.

Feed documents are just an implementation detail of the most popular
way of passing this information around.

-- 
Dave