hello peter. thanks for your comment!
> It looks like you will be duplicating the value of the link relation > in the link element type attribute for each entry in the target feed? > How would you handle discrepancies if the marked feed had entries with > a different value? i think i wasn't clear enough. my proposal would only be for feed/link elements, not for feed/entry/link elements. the idea is to point to a variant of the whole feed, not to individual entries. it should be a link y can follow when you want to consume a different feed, one that has different "primary" content. and each "feed variant" would be a regular feed and thus be free to link to entry alternate versions. the label i am thinking of would indicate something you might call the feed's "primary content type". > If there are multiple feeds for a given set of resources, how can I > trust I am getting the same updates in each of the feeds? i don't think you can trust the publisher a 100%, but it's a good thing to point out, and the link relation should probably say that "publishers SHOULD try to expose updates across feed variants in a consistent manner", or something along these lines. > I see a lot of benefit in having one feed with multiple link elements. > If I'm only interested in the RDF entries I am still doing the same > number of requests (one for the feed and then one for each entry I am > interested in)? And I can trust I get all updates at the same time. you're right that there is an issue with trust and consistency, which is probably very hard to formalize or standardize. on the other hand, if you follow a feed that embeds non-RDF (and limks to RDF alternates) and you got 10 new entries when reading the feed, you need a total of 11 GETs to retrieve the data you're interested in. if there was an feed embedding RDF, it's just one GET and you're done. for resource-constrained scenarios such as mobile or embedded systems, and in particular for push support, this is a very significant difference. thanks and cheers, dret. >
