On 13/7/05 4:25 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> True, but this doesn¹t detract from my argument that we need to > be able to signify a tighter relationship than just ³related.² An > aggregator might want to offer different UI for comment feeds, in > contrast to merely ³related² feeds. Automatic polling of comment > feeds is just one possible behaviour that differentiates the two. An example that comes to mind of different kinds of feeds: say I have a pod-cast with a horkin' mp3 enclosure ... and a link to an Atom Feed Document that contains section by section summaries, complete with some kind of link to the time-point in the mp3. That particular Atom Feed Document would never grow, normally, and thus should not be polled. A user might choose to refresh or reload that Atom Feed Document, just in case some errors were updated (just as we do with regular web-pages), but there wouldn't need to be any reason to *poll*. There are probably many other whole->part feed document scenarios. Quick poll: how many feed readers let the user read the current feed document without first requiring them to subscribe. That is, present the content, along with a button "subscribe to future updates". e.
