Subject: RE: One reason we have duplicates entries is that we have duplicate feeds...

From: Antone Roundy <[email-masked]>
Date: Thu, 14 Apr 2005 14:02:03 -0600

...back in town, and ready to express opinions...

> Thomas Broyer wrote:
>> Bob Wyman wrote:
>>> Robert Sayre wrote:
>>> You can point to an alternate feed like this
>>> <link rel="alternate" type="some/feed" href="..." />
>>> Of course, you can't have two alternates with the same media type...
>>
>> 	Yes, you can point to an alternate. However, all you are doing at
>> that point is establishing equivalence between the two. The 
>> "alternate"
>> mechanism doesn't provide you with a way to say which feed is 
>> preferred.
>>
> Well, if you publish Atom 1.0, RSS 1.0 and RSS 2.0 feeds, they should 
> all be equivalent. Which is "preferred" is on the end-user's hands.

I disagree that they're necessarily equivalent--the publisher may 
consider one to be the "original" feed, and all others to be 
alternative versions of it, and in fact the secondary feeds may very 
well be generated by transforming the primary feed.  That needn't 
necessarily affect which one an individual subscriber subscribes to.  
The point is that it would be useful (for duplicate detection) for the 
publisher to be able to indicate that they consider a particular feed 
to be a secondary source of data to another feed or feeds, either 
because it's an alternative format of all the same data, or because it 
is or contains a subset of data from another feed or feeds.

I think we could get by without @rel="preferred-feed" and the baggage 
that wording carries, and just use @rel="subset-of" for all cases.  
That wouldn't precisely express the idea that the feed in question is 
secondary to another feed, so we might want a different value like 
"secondary-to", "primary-feed", "primary-source" or something.  There 
are three cases this may need to address: feeds that are strict subsets 
of other feeds, feeds that are alternative format versions of other 
feeds, and feeds that are aggregated from multiple other feeds.

We've already got a way to handle aggregations from multiple sources.  
Do we want to allow people to choose to just use a "secondary-to" link 
to express that relationship rather than atom:source-feed with it's 
copy of the feed metadata?  Just asking because it's conceivable that 
it might happen.

Alternative format versions are the best candidate for handling with a 
single link, because other than the format that's carrying the data, 
they're the same thing--their feed level metadata should be identical 
(or as identical as the various formats are capable of expressing).

Strict subsets on the other hand might have very different feed level 
metadata, which would make using atom:source-feed to express them as 
aggregations (even though they're from a single source) more 
technically accurate.  But since each entry would have to have an 
identical copy of atom:source-feed in that case, it would be a little 
sloppy.

Antone

---

From: Thomas Broyer <[email-masked]>
Date: Sun, 17 Apr 2005 18:16:11 +0200

...only about subsets/supersets and duplicates...

Antone Roundy wrote:
> @rel="subset-of"

@rel="superset"?

>  Do we want to allow people to choose to just use a "secondary-to" 
> link to express that relationship rather than atom:source-feed with 
> it's copy of the feed metadata?

atom:source must not contain a copy of the whole original feed's 
metadata, only the metadata required in atom:feed are (should be?) 
required in atom:source.

(Yes, I know I previously said the whole metadata should be copied, I
now think it was a mistake: copy only what you want to copy, as long as
you copy the minimum required metadata)

> identical copy of atom:source-feed in that case, it would be a little

Might we add an "internal reference" system?

<atom:feed xmlns:atom="...">
...
<atom:source id="another-feed">
   <!-- another feed's metadata -->
</atom:source>
<atom:entry>
    <atom:source ref="another-feed" />
    ...
</atom:entry>
...
</atom:feed>

Problems:
  - if we allow this for atom:source, we might as well allow it for
person constructs (e.g. all entry authors are listed in the feed's
contributors and referenced by entries atom:author or contributors; this
prevents duplication of person constructs describing the same constructs)
  - this is a big enhancement to the spec and won't do it for Atom 1.0

An alternative would be to use a link element with @rel="superset"
telling aggregators that the entries in this feeds are copies of entries
in the linked feed. Entries with the same atom:id would then be
considered duplicates and only the "superset" feed would have
"authority": if an entry is said to have been updated in the subset feed
but not in the superset feed, it might be an "attack", so ignore it.
Same if an entry has been added to the subset feed without appearing in
the superset feed (problem: an entry could "disappear" from the superset
feed due to many newer entries "pushing the entry towards the exit").
Actually, if both the superset and subset feeds are used in
aggregations, the subset feed would only be used to list the entries
(from the superset feed) which compose the subset.
Such a link MUST then be copied in an atom:source element when the 
subset feed is used in aggregations... and this obviously complicates 
the aggregation process: some links MUST be copied, others only SHOULD 
or MAY, depending on their @rel value... To simplify this process, the 
solution would be that link @rel="superset" doesn't prevent you from 
using atom:source, which brings us back to the beginning...

A feed might also lists its subsets (e.g. category feeds) using link
elements with @rel="subset", though this list would only be informative,
without the aggregating rules above (preventing from "attacks": I create
a feed that declares another feed as a subset in order for my entries to
take precedence over the "real feed" entries).

Conclusion: all this should IMHO be delayed until the next Atom 
version... People will probably create extension elements and time will 
tell us about their advantages and drawbacks, then the Atom WG would be 
able to choose what to include in the Atom spec.

-- 
Thomas Broyer