Re: The benefits of "Lists are Entries" rather than "Lists are Feeds"

[Robert Koberg]

Hi,

A. Pagaltzis wrote:

* Graham <[EMAIL PROTECTED]> [2005-08-31 20:40]:


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



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

Re: The benefits of "Lists are Entries" rather than "Lists are Feeds"

[A. Pagaltzis]

* Graham <[EMAIL PROTECTED]> [2005-08-31 20:40]:
> On 31 Aug 2005, at 6:22 pm, Roger B. wrote:
> >(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.
> 
> And damn those unthinking bloggers who embed their paragraphs
> as (X) HTML, because headline-only aggregators are useless for
> reading them.

Straw man. These bloggers are embedding the content of a single
entry in each single entry, not the content of a collection of
entries.

> >(2) If the lists are embedded in a new extension of some sort,
> >developers have to buy in to get even minimal functionality.
> 
> Who is advocating this?

I don’t know about advocating, but it has been mentioned.

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

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.

Regards,
-- 
Aristotle Pagaltzis // 

Re: The benefits of "Lists are Entries" rather than "Lists are Feeds"

[Graham]

On 31 Aug 2005, at 6:22 pm, Roger B. wrote:


(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.


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



(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*.


Who is advocating this?


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


Fair point.


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.


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


Graham

Re: The benefits of "Lists are Entries" rather than "Lists are Feeds"

[Roger B.]

> What is wrong with my
> suggestion that lists-are-entries is much more useful than the alternative?

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

Re: The benefits of "Lists are Entries" rather than "Lists are Feeds"

[James M Snell]

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.


Bob Wyman wrote:


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 PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Bob Wyman
Sent: Tuesday, August 30, 2005 5:10 PM
To: 'Mark Nottingham'
Cc: atom-syntax@imc.org
Subject: RE: "Top 10" and other lists should be entries, not feeds.

Mark Nottingham wrote:
 


Are you saying that when/if Netflix switches over to Atom, they
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





 

Re: The benefits of "Lists are Entries" rather than "Lists are Feeds"

[Mark Nottingham]

What would you like the working group to do?


On 31/08/2005, at 8:36 AM, Bob Wyman wrote:



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 PROTECTED] [mailto:owner-atom- 
[EMAIL PROTECTED]

On Behalf Of Bob Wyman
Sent: Tuesday, August 30, 2005 5:10 PM
To: 'Mark Nottingham'
Cc: atom-syntax@imc.org
Subject: RE: "Top 10" and other lists should be entries, not feeds.

Mark Nottingham wrote:


Are you saying that when/if Netflix switches over to Atom, they
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









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

The benefits of "Lists are Entries" rather than "Lists are Feeds"

[Bob Wyman]

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 PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Bob Wyman
Sent: Tuesday, August 30, 2005 5:10 PM
To: 'Mark Nottingham'
Cc: atom-syntax@imc.org
Subject: RE: "Top 10" and other lists should be entries, not feeds.

Mark Nottingham wrote:
>Are you saying that when/if Netflix switches over to Atom, they
> 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

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

[Danny Ayers]

On 8/31/05, Danny Ayers <[EMAIL PROTECTED]> wrote:

Correction:

> 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 

=>

> I doubt there's much difference in terms of effort needed for a publisher to 
> support
> either the per-entry or in-entry approaches. Capabilities of the
> 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

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

[Danny Ayers]

On 8/30/05, Bob Wyman <[EMAIL PROTECTED]> wrote:

> 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.

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 2 replacing the current
entry with an element with that value.

Or by interpretation of something like:


...
http://www.w3.org/1999/xhtml"; ...>
   
   Number One
   Number Two
...
   

...


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

Another alternative would be:


...
whatever
...




...


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

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

[Dan Brickley]

Peter Saint-Andre wrote:


Walter Underwood wrote:

--On August 30, 2005 1:49:57 AM -0400 Bob Wyman <[EMAIL PROTECTED]> 
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.




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.



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


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