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.