hello thomas.

Thomas Broyer wrote:
AFAICT, this has nothing to do with Atom-the-Protocol but only with
Atom-the-Syntax, so CC'ing atom-syntax (and please follow-up there).

ok, follow-up to atom-syntax, cc'ed to atom-protocol and will remove that list from future posts.

My reading is backwards: undefinedAttribute in the RNC explicitly
prohibits local:* attributes while allowing xml:id (and any "foreign"
attribute besides xml:base and xml:lang)

you're correct. which means xml:id would be allowed; that's nice.

<feed xmlns="http://www.w3.org/2005/Atom";>
<link rel="via" href="http://example.com/feed-A"; />
...
<entry>
  <source>
    <link rel="self" href="http://example.com/feed-A"; />
...
And relate entries to li...@rel='via'] using the @href value.

that's almost what i want, but not quite, because this way, clients can only find out entries from which feeds did show up in the consumed feed, but not which feeds have been aggregated by the consumed feed. as a side-effect, i's also like the aggregated feed to be able to create and advertise IDs for the aggregated feeds, so that clients can query the aggregated feed by specifically asking only for certain entries from certain feeds. this is the bigger picture of the question i am asking here; how to create a query language for feeds. as one goal, we want it to be able to work across feeds, and a nice way to do this would be to specify it as working on an aggregated feed.

<feed xmlns="http://www.w3.org/2005/Atom"; xml:via="...">
<link xml:id="feed1" rel="via" href="http://example.com/feed-A"; />
<link xml:id="feed2" rel="via" href="http://example.com/feed-B"; />
...
<entry>
  <source via:via="feed1">
    <link rel="self" href="http://example.com/feed-A"; />

that would be the idea, i guess. it does duplicate the feed URIs, but it is usable for pure atom clients, which is good. but even though entries from feed-B might not show up in the aggregated feed too often (because the aggregated feed is limited to some number on entries and feed-B is a low-volume feed, perhaps), it would still be visible that feed-B is contributing to the aggregated feed, and clients could specify filters and query the aggregated feed asking for entries only from feed-B (by using the "feed2" id in the query).

cheers,

dret.

Reply via email to