Subject: "Top 10" and other lists should be entries, not feeds.

From: "Bob Wyman" <[email-masked]>
Date: Tue, 30 Aug 2005 01:49:57 -0400

I'm sorry, but I can't go on without complaining.  Microsoft has proposed
extensions which turn RSS V2.0 feeds into lists and we've got folk who are
proposing much the same for Atom (i.e. stateful, incremental or partitioned
feeds). I think they are wrong. Feeds aren't lists and Lists aren't feeds.
It seems to me that if you want a "Top 10" list, then you should simply
create an entry that provides your Top 10. Then, insert that entry in your
feed so that the rest of us can read it. If you update the list, then just
replace the entry in your feed. If you create a new list (Top 34?) then
insert that in the feed along with the "Top10" list. 

What is the problem? Why don't folk see that lists are the stuff of entries
- not feeds? Remember, "It's about the entries, Stupid."

I think the reason we've got this pull to turn feeds into Lists is simply
because we don't have a commonly accepted "list" schema. So, the idea is to
repurpose what we've got. Folk are too scared or tired to try to get a new
thing defined and through the process, so they figure that they will just
overload the definition of something that already exists. I think that's
wrong. If we want "Lists" then we should define lists and not muck about
with Atom. If everyone is too tired to do the job properly and define a real
list as a well defined schema for something that can be the payload of a
content element, then why not just use OPML as the list format?

What is a search engine or a matching engine supposed to return as a result
if it find a match for a user query in an entry that comes from a list-feed?
Should it return the entire feed or should it return just the entry/item
that contained the stuff in the users' query? What should an aggregating
intermediary like PubSub do when it finds a match in an element of a
list-feed? Is there some way to return an entire feed without building a
feed of feeds? Given that no existing aggregator supports feeds as entries,
how can an intermediary aggregator/filter return something the client will
understand? 

You might say that the search/matching engine should only present the
matching entry in its results. But, if you do that what happens is that you
lose the important semantic data that comes from knowing the position the
matched entry had in the original list-feed. There is no way to preserve
that order-dependence information without private extensions at present.

I'm sorry but I simply can't see that it makes sense to encourage folk to
break important rules of Atom by redefining feeds to be lists. If we want
"lists" we should define what they look like and put them in entries. Keep
your hands off the feeds. Feeds aren't lists - they are feeds.

            bob wyman

---

From: Henry Story <[email-masked]>
Date: Tue, 30 Aug 2005 12:52:41 +0200

+1 I completely agree with Bob again.

Though my preference of course would be to put RDF in the content.
RDF has structures for ordered lists. It probably has vocabularies  
for songs.
It has vocabulary to specify the author of a work, etc... And with  
foaf you
could also specify which of the artists was your friend. In short you  
can
mix the different RDF vocabularies out there in well understood ways.

For those of you new to RDF but au fait with Java, I have just  
written up a blog
that should help explain exactly why RDF is so powerful:

http://blogs.sun.com/roller/page/bblfish? 
entry=java_annotations_the_semantic_web

In short: RDF can be mapped directly onto Java Beans. Just as Beans  
can be plugged
together, so RDF markup can be plugged together. Welcome to the world  
of OO xml.

Henry Story

On 30 Aug 2005, at 07:49, Bob Wyman wrote:
> I’m sorry, but I can’t go on without complaining.  Microsoft has  
> proposed extensions which turn RSS V2.0 feeds into lists and we’ve  
> got folk who are proposing much the same for Atom (i.e. stateful,  
> incremental or partitioned feeds)… I think they are wrong. Feeds  
> aren’t lists and Lists aren’t feeds. It seems to me that if you  
> want a “Top 10” list, then you should simply create an entry that  
> provides your Top 10. Then, insert that entry in your feed so that  
> the rest of us can read it. If you update the list, then just  
> replace the entry in your feed. If you create a new list (Top 34?)  
> then insert that in the feed along with the “Top10” list.
>
> What is the problem? Why don’t folk see that lists are the stuff of  
> entries – not feeds? Remember, “It’s about the entries, Stupid…”
>
> I think the reason we’ve got this pull to turn feeds into Lists is  
> simply because we don’t have a commonly accepted “list” schema. So,  
> the idea is to repurpose what we’ve got. Folk are too scared or  
> tired to try to get a new thing defined and through the process, so  
> they figure that they will just overload the definition of  
> something that already exists. I think that’s wrong. If we want  
> “Lists” then we should define lists and not muck about with Atom.  
> If everyone is too tired to do the job properly and define a real  
> list as a well defined schema for something that can be the payload  
> of a content element, then why not just use OPML as the list format?
>
>
>
> What is a search engine or a matching engine supposed to return as  
> a result if it find a match for a user query in an entry that comes  
> from a list-feed? Should it return the entire feed or should it  
> return just the entry/item that contained the stuff in the users’  
> query? What should an aggregating intermediary like PubSub do when  
> it finds a match in an element of a list-feed? Is there some way to  
> return an entire feed without building a feed of feeds? Given that  
> no existing aggregator supports feeds as entries, how can an  
> intermediary aggregator/filter return something the client will  
> understand?
>
> You might say that the search/matching engine should only present  
> the matching entry in its results. But, if you do that what happens  
> is that you lose the important semantic data that comes from  
> knowing the position the matched entry had in the original list- 
> feed. There is no way to preserve that order-dependence information  
> without private extensions at present.
>
> I’m sorry but I simply can’t see that it makes sense to encourage  
> folk to break important rules of Atom by redefining feeds to be  
> lists. If we want “lists” we should define what they look like and  
> put them in entries. Keep your hands off the feeds. Feeds aren’t  
> lists – they are feeds.
>
>
>
>             bob wyman
>
>
>
>
>
>

---

From: Graham <[email-masked]>
Date: Tue, 30 Aug 2005 12:23:23 +0100

How would this apply to the most problematic example of a list feed,  
the BBC news headline page:

http://newsrss.bbc.co.uk//rss/newsonline_uk_edition/front_page/rss.xml

Which has the top stories first (amongst other structure) and is a  
hell of a lot more usable in news readers that preserve order.

Graham

---

From: Henry Story <[email-masked]>
Date: Tue, 30 Aug 2005 14:21:15 +0200

Mhh. Good point too.

For some reason though, this is starting to make me think that a feed  
is an entry again...

Henry

On 30 Aug 2005, at 13:23, Graham wrote:
>
> How would this apply to the most problematic example of a list  
> feed, the BBC news headline page:
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Aug 2005 13:01:57 -0700

Sorry, Bob I disagree. I tried to introduce a rigid concept of what a  
feed is much earlier, and people pushed back; as a result, Atom  
doesn't have a firm definition of the nature of a feed. As a result,  
we can't go and say what it can't be at a later date.

Besides which, I think the use cases for Atom-as-list are powerful,  
and just beginning to be seen. E.g., Netflix allows you to subscribe  
to your Queue:
   http://www.netflix.com/RSSFeeds

Are you saying that when/if Netflix switches over to Atom, they  
shouldn't use it for the Queue?

It sounds like you've got use cases for Atom that other use cases  
(e.g., lists) make difficult to work with. Banning those other use  
cases makes things easier for you, but I don't think it's good for  
Atom overall.

Cheers,

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Tue, 30 Aug 2005 13:10:12 -0700

> cases makes things easier for you, but I don't think it's good for  

+1 on every point.

- James

---

From: Graham <[email-masked]>
Date: Tue, 30 Aug 2005 22:04:02 +0100

> cases makes things easier for you, but I don't think it's good for  

But conceptually Bob is absolutely correct. An ordered list is just  
an entry that gets updated regularly. There's absolutely no reason  
for Netflix to create an individual entry for each DVD. It's a hack  
that makes it look better in most aggregators. Nothing more.

It would be good if Atom were flexible enough to cope where there  
isn't a 1:1 mapping between publications and items of information, by  
subdividing entries into chapters or something, but as Mark Pilgrim  
said somewhere, Atom deals with none of the interesting problems with  
syndication (Atom = RSS3).

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 30 Aug 2005 17:09:55 -0400

> shouldn't use it for the Queue?
	No. I'm saying that if Netflix switches over to Atom, what they
should do is insert the Queue information, as a list, into a single entry
within the feed. 
	This will not only preserve the nature of Atom feeds as "feeds" but
also allow NetFlix a number of new and potentially interesting opportunities
for providing data to customers. Most important among these will be the
ability to include multiple lists in the feed (i.e. in addition to the
Queue, they could also include their "Top 10" list as well as a set of
"recommendations" based on user experience. They might even include a list
of "10 most recent transactions on your account") Each list would be a
distinct entry. To make life easier on aggregators, each entry "type" should
probably use the same atom:id across "versions." This allows the aggregators
to discard earlier, now out of date entries.
	NetFlix would also be able to intermix information such as the
"Queue List" with non-list entries. For instance, they might have a "Message
from NetFlix" that they want to include in the feed or, they might include a
series of movie reviews that were carefully selected for the specific user.
	Basically, by using entries for lists instead of converting the
entire feed into a list, NetFlix is able to offer a much richer and much
more satisfying experience to their users.
	The ability of Atom to carry both lists and non-lists as entries
means that Atom is able to offer a much more flexible and powerful mechanism
to NetFlix than can be had from the less-capable RSS V2.0 solution. I think
that if I were NetFlix, I would want to have the opportunity to experiment
with and find ways to exploit this powerful capability. The richer the
opportunity for communications between NetFlix and their customers, the
greater the opportunity they have to generate revenues.
	The alternative to using entries rather than feeds would be creating
multiple feeds per user. That strikes me as a solution which is ugly on its
face and unquestionably increases the complexity of the system for both
NetFlix and its customers. The "list-in-entry" solution is much more elegant
and much more powerful.

	bob wyman

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 30 Aug 2005 23:35:34 +0200

Bob Wyman wrote:
> proposed extensions which turn RSS V2.0 feeds into lists and we’ve got 
> folk who are proposing much the same for Atom (i.e. stateful, 
> aren’t lists and Lists aren’t feeds. It seems to me that if you want a 
> “Top 10” list, then you should simply create an entry that provides 
> your Top 10. Then, insert that entry in your feed so that the rest of 
> us can read it. If you update the list, then just replace the entry in 
> your feed. If you create a new list (Top 34?) then insert that in the 
> feed along with the “Top10” list.
>
Henry Story also proposed atom:id to be "order-related":
<feed xmlns="http://www.w3.org/2005/Atom">
...
<entry>
<id>tag:first-in-list</id>
<title>Some entry</title>
...
</entry>
<entry>
<id>tag:second-in-list</id>
<title>Another entry</title>
...
</entry>
</feed>

and a bit later:
<feed xmlns="http://www.w3.org/2005/Atom">
...
<entry>
<id>tag:first-in-list</id>
<title>Another entry</title>
...
</entry>
<entry>
<id>tag:second-in-list</id>
<title>Yet another entry</title>
...
</entry>
</feed>

Note how tag:first-in-list entry now represents "Another entry" while it 
were previously "Some entry", and tag:second-in-list now is "Yet another 
entry" while it were "Another entry".

-- 
Thomas Broyer

---

From: Walter Underwood <[email-masked]>
Date: Tue, 30 Aug 2005 14:41:37 -0700

--On August 30, 2005 1:49:57 AM -0400 Bob Wyman <[email-masked]> wrote:

> I’m sorry, but I can’t go on without complaining.  Microsoft has proposed
> extensions which turn RSS V2.0 feeds into lists and we’ve got folk who are
> feeds)… I think they are wrong. Feeds aren’t lists and Lists aren’t feeds.

The Atom spec says:

   This specification assigns no significance to the order of atom:entry
   elements within the feed.

One could read that to mean that feeds are fundamentally unordered or that
Atom doesn't say what the order means.

Other RSS formats are ordered, either implicitly or explicity (RSS 1.0).
For interoperatility, lots of software is going to treat Atom as ordered.
Otherwise, it is not possible to go from Atom to RSS 1.0.

> What is a search engine or a matching engine supposed to return as a resul

Maybe the list feed should have a noindex flag.

> that contained the stuff in the users’ query?

I'd return the entry. It is all about the entries. If the list position is
semantically important to the entry, then include a link from the entry to
the list. "This is movie 312 in wunder's queue."

wunder
--
Walter Underwood
Principal Software Architect, Verity

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Aug 2005 15:50:45 -0600

> Atom doesn't say what the order means.

Is not logical order, if any, determined by the datetime of the 
published (or updated) element?

> Otherwise, it is not possible to go from Atom to RSS 1.0.

I assume you mean from RSS 1.0 to Atom. :-)

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

---

From: Walter Underwood <[email-masked]>
Date: Tue, 30 Aug 2005 15:05:47 -0700

> I assume you mean from RSS 1.0 to Atom. :-)

No. You can go from a Bag to List by ignoring the order. RSS 1.0 is a
List, so you would need to invent an order to put unordered items in it.

wunder

---

From: Walter Underwood <[email-masked]>
Date: Tue, 30 Aug 2005 15:08:16 -0700

--On August 30, 2005 3:50:45 PM -0600 Peter Saint-Andre <[email-masked]> wrote:
> Is not logical order, if any, determined by the datetime of the published
> (or updated) element?

That is one kind of order. Other kinds are relevance to a search term
(A9 OpenSearch), editorial importance (BBC News feeds), or datetime of
original publication (nearly all blog feeds, not the same as last update).

wunder

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Aug 2005 15:19:34 -0700

I'd say an ordered list *can be* an entry that gets updated  
regularly. There's absolutely no reason that Netflix can't have one  
DVD-per-entry, and it's not a hack.

---

From: Tim Bray <[email-masked]>
Date: Tue, 30 Aug 2005 15:48:49 -0700

> original publication (nearly all blog feeds, not the same as last  

Well put.  It's obvious that there exist feeds that have ordering  
requirements that are orthogonal to atom:updated.

It's plausible, but not obvious, that the first two kinds of order  
Walter enumerates are instances of a class which we might label  
"importance" or "priority".  It's also plausible, but even less  
obvious, that there are going to be lots of places where non-updated  
order matters in a way that has to do with "importance", to the  
extent that a generally-implemented extension will be useful.  It's  
also plausible, but not obvious, that there's no usefully- 
generalizable notion of "importance", that the semantics of this  
stuff are really application-specific, and that interested parties  
should go and do their own NetFlix or A9 or BBC extensions.  Or just  
cram your Netflix queue in a single entry.

Fortunately, the format spec, with its "assigns no significance"  
language, doesn't get in the way of people who want to work on this  
problem.  I can see two generalized approaches; the first is a  
singleton attribute of child of <atom:feed> that says "in this feed,  
<atom:entry> order reflects importance".  The second is such an  
attribute that says "in this feed, an ordering by the following  
namespaced-element child of <atom:entry> reflects importance".  I  
prefer the first.  I haven't looked at the Microsoft proposal.

Clearly, the WG lacks consensus, at least in the short term. -Tim

---

From: Graham <[email-masked]>
Date: Tue, 30 Aug 2005 23:53:19 +0100

> DVD-per-entry, and it's not a hack.

Well it depends. The basic paradigm for a feed is as a newswire of  
recently posted or updated entries, which works pretty well. For the  
netflix queue to work, you have to take a step beyond that and view  
the feed file as a document and not just an envelope. It's not  
necessarily a hack, but it's a totally different paradigm.

Graham

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 31 Aug 2005 01:20:51 +0200

> Henry Story also proposed atom:id to be "order-related":

Indeed, and together with an extension for expiring entries, the
Netflix use case should be pretty well covered.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Henry Story <[email-masked]>
Date: Wed, 31 Aug 2005 02:17:07 +0200

It's late here, but since I have been called...

Clearly the order of the entries could not be deduced from the tags  
themselves.
One would need to have an extra tag in there such as this <position> tag

<feed>
    <entry>
       <id>tag:first-in-list</id>
       <ext:position>1</position>
       <title>The Graphes of Wrath</title>
       <update>1 July 2005</udpated>
       ...
    </entry>
    ...
</feed>
to specify the order of the entry. I think at the time I was talking  
in the context
of that being proposed.

Again it is late, but I think my idea of having a entry always stay  
at the same position
was that I was thinking that from one week to another one could just  
change the content
of the entry

<feed>
    <entry>
       <id>tag:first-in-list</id>
       <ext:position>1</position>
       <title>Of Mice and Men</title>
       <update>8 July 2005</udpated>
       ...
    </entry>
</feed>

So that one could still think of a feed as a sequence of changes to  
resources. One
would then, I thought, not need to republish the whole list of  
entries, just
those that changed from week to week. As a result there was I  
thought, no need for
a <stateful> tag.

But the problem with that suggestion was that it could not cope well  
with mistaken
feed updates. So that if I mistakenly entered "Of Mice and Men" but I  
meant to
enter "The Restaurant at the End of the Universe" then adding the  
following entry

<feed>
    <entry>
       <id>tag:first-in-list</id>
       <ext:position>1</position>
       <title>The Restaurant at the end of the Universe</title>
       <update>8 July 2005</udpated>
       ...
    </entry>
</feed>

would tend to indicate that the change was insignificant, whereas a  
change
of date would tend to indicate that the there was a new entry in  
first position.

Some proposed that one should distinguish therefore between the  
update time of the
entry and the update time of the object of the entry...

Henry

On 30 Aug 2005, at 23:35, Thomas Broyer wrote:
> Note how tag:first-in-list entry now represents "Another entry"  
> while it were previously "Some entry", and tag:second-in-list now  
> is "Yet another entry" while it were "Another entry".
>
> -- 
> Thomas Broyer
>
>

---

From: James M Snell <[email-masked]>
Date: Tue, 30 Aug 2005 17:24:47 -0700

Or.. perhaps <i:index>1</i:index>

http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-01.txt

- James

---

From: Eric Scheid <[email-masked]>
Date: Wed, 31 Aug 2005 13:04:10 +1000

> published (or updated) element?

No. I've seen a few things online where they publish chapter 3 first,
followed by chapter 8, and then go back and fill in the blanks. And then
update chapter 2.

Sometimes there are good reasons for this, strangely enough.

Leaving aside completely the idea of publishing a chunk, followed by more
chunks, and *then* re-arranging them into some semblance of logical order
once they know what content they have.

e.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 31 Aug 2005 12:59:07 +1000

> cases makes things easier for you, but I don't think it's good for

those other use cases are also a good example of some feeds which shouldn't
be devoured by robots.

e.

---

From: Dan Brickley <[email-masked]>
Date: Wed, 31 Aug 2005 08:36:01 +0100

Peter Saint-Andre wrote:

>>> proposed

Often it makes sense for the order to come from properties of the things
described by the items/entries, rather than publication dates. Examples:
movie listings, job listings, photos by image creation rather than upload
time, etc. Generally, feeds that aren't blog content but are views into some
database, ie. the same kinds of feed that are most likely to use 
data-centric
markup extensions.

Atom allows such orderings to be exposed, without requiring that a
machine-friendly justification be given. Seems about right to me.

cheers,

Dan

---

From: Danny Ayers <[email-masked]>
Date: Wed, 31 Aug 2005 17:30:57 +0200

> should do is insert the Queue information, as a list, into a single entry

Correct me if I'm wrong, but doesn't Atom already support this, along
with pretty much every other approach?

Entries in an individual feed document are unordered. The client can
derive a well-defined order from the dates (or have something
considerably less controlled going per doc changes). That's for date
order.

But the client could sort entries according to some other derived
order - e.g. alphabetically by title or content or by size.

Or by value of the x:priority element on each entry, with perhaps a
later entry flagged <x:priority>2</x:priority> replacing the current
entry with an element with that value.

Or by interpretation of something like:

<atom:entry>
...
<atom:content xmlns="http://www.w3.org/1999/xhtml" ...>
   <ol class="chart order">
       <li><a href="tag:.stuff.entryx">Number One</a></li>
       <li><a href="tag:.stuff.entryy">Number Two</a></li>
...
   </ol>
</atom:content>
...
</atom:entry>

( - is that the kind of thing you had in mind, Bob?)

Another alternative would be:

<atom:entry>
...
<atom:content>whatever</atom:content>
...
<x:sortOrder title="chart order">
    <x:sortItem uri="tag:.stuff.entryx" />
    <x:sortItem uri="tag:.stuff.entryy" />
</x:sortOrder>
...
</atom:entry>

i.e. having the list order provided in a single entry, but through
extensions rather than in the content. There's a load of other
alternatives to - adding "next" and "previous" URI links, labelled
with whatever axis the sort order is over.

I doubt there's much difference in terms of effort needed to support
either the per-entry or in-entry approaches. Capabilities of the
client might make a lot of difference though - expressing the order in
XHTML might be more client-friendly than using something like RDF/XML
or any other hard-to-view format.

With the aggregator code I've been playing with recently the list
approach might be marginally easier to support, as it could be XSLT'd
across to an rdf:List. Sorting on an x:sortPosition kind of element
could be trickier as that would need to be considered in combination
with the date, but then again joins may be more flexible.
  
Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Wed, 31 Aug 2005 17:34:54 +0200

On 8/31/05, Danny Ayers <[email-masked]> wrote:

Correction:

> client might make a lot of difference though 

=>

> I doubt there's much difference in terms of effort needed for a publisher to support
> client might make a lot of difference though 

Also what I didn't ask was - as these approaches are already supported
by the Atom format, what's the point of dispute, the aim of this
discussion?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 31 Aug 2005 11:36:18 -0400

Folks, I hate to be insistent, however, I think that in the mail below I
offered some pretty compelling reasons why lists should be entries rather
than turning feeds into lists. Could someone please comment on this? Is
there some point that I'm completely missing? What is wrong with my
suggestion that lists-are-entries is much more useful than the alternative?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bob Wyman
Sent: Tuesday, August 30, 2005 5:10 PM
To: 'Mark Nottingham'
Cc: [email-masked]
Subject: RE: "Top 10" and other lists should be entries, not feeds.

	bob wyman

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 31 Aug 2005 09:08:45 -0700

What would you like the working group to do?

---

From: James M Snell <[email-masked]>
Date: Wed, 31 Aug 2005 09:22:42 -0700

It may very well be more useful, but we shouldn't mandate it in any 
way.  Let people build whatever kind of applications they want with Atom.

---

From: "Roger B." <[email-masked]>
Date: Wed, 31 Aug 2005 12:22:34 -0500

> What is wrong with my

Bob: Well, off the top of my head...

(1) If the lists are embedded as (X)HTML, then only aggregators that
display markup will be able to do anything with them, and
headline-only aggregators will be useless.

(2) If the lists are embedded in a new extension of some sort,
developers have to buy in to get even minimal functionality. Not so if
the entries are list items... even a non-list-aware aggregator will be
able to display *something*.

(3) If the lists are embedded as (X)HTML, my options for re-sorting
the list are somewhere between minimal and non-existent.

In fact, the only benefit I can see (as a user) to
lists-within-entries is the ability to easily archive the state of the
list. But that's probably better left to aggregator developers to
implement as a feature.

--
Roger Benningfield

---

From: Graham <[email-masked]>
Date: Wed, 31 Aug 2005 19:29:27 +0100

> headline-only aggregators will be useless.

And damn those unthinking bloggers who embed their paragraphs as (X) 
HTML, because headline-only aggregators are useless for reading them.

> able to display *something*.

Who is advocating this?

> the list are somewhere between minimal and non-existent.

Fair point.

> list. But that's probably better left to aggregator developers to

Another feature is the list can be formatted properly XHTML,  
considerably improving legibly over a bunch of floating entries.

Graham

---

From: Robert Koberg <[email-masked]>
Date: Wed, 31 Aug 2005 16:56:47 -0400

Hi,

A. Pagaltzis wrote:
> * Graham <[email-masked]> [2005-08-31 20:40]:
> 
> Straw man. The onus for the legibility of an XHTML-formatted list
> lies with the publisher; for the entries-as-items list, it lies
> with the aggregator developer. I’m sorry if you aggregator
> developer can’t make a bunch of floating entries very readable.

What is a floating entry? I have tried a search in the specs (IETF and 
.3) and google for: atom floating entry. No results or no relevent results.

-Rob