Re: Posted PaceEntryOrder (was Entry order)
On 5/2/05 12:14 PM, Graham [EMAIL PROTECTED] wrote:
{{{ This specification assigns no significance to the order of
atom:entry elements within the feed. Processors MAY present entries in
a different order to which they are appear in an Atom Feed Document.
}}}
First sentence no, but the second sentence says all that we need to say
and no more.
+1 .. while the spec assigns no significance, a publisher might want to have
more important stories at the front of the feed, albeit knowing full well
that some users will sort things whichever way they want, and some
applications will insist on applying a default sort of their choice.
e.
Re: Entry order
Having started agreeing with the initial post, and having read more of the thread I am now divided about what the best position is. In some sense the order is of the entries should not matter. All the important data to order the entries is in the entries themselves given by the modified date, the creation date, ... So if we map a whole feed into an rdf graph nothing is lost. We can use the data in the graph to sort our entries as we wish. On the other hand an application reading a feed would expect the latest entries to be at the head of the feed. This is very important at the protocol level, because without this guarantee, a client that would like to present the latest version of an entry would be forced to read the whole feed document and all feed documents linked to it, in order to be able to correctly assess that the entry it has really is the latest one. I think imposing a fixed ordering is not very helpful. Services may pop up that order entries in different ways depending on the interests of the receiver. But perhaps there should be a way to specify what the order of the entries is, or at least give a way to specify that the entries are ordered inverse chronlogically by the modified date when they are. This may be a protocol issue, or it may just be a matter of adding a special info to the feed to specify its ordering. Henry Story http://bblfish.net/ On 4 Feb 2005, at 20:27, Walter Underwood wrote: --On February 3, 2005 11:21:50 PM -0500 Bob Wyman [EMAIL PROTECTED] wrote: David Powell wrote: It looks like this might have got lost accidently when the atom:head element was introduced. Previously Atom 0.3 said [1]: Ordering of the element children of atom:feed element MUST NOT be considered significant. +1. The order of entries in an Atom feed should NOT be significant. This is, I think, a very, very important point to make. -1 Is this a joke? This is like saying that the order of the entries in my mailbox is not significant. Note that ordering a mailbox by date is not the same thing as its native order. Feed order is the only way we have to show the publication order of items in a feed. I just looked at all my subscriptions, and there is only one where the order might not be relevant, a security test for RSS readers. That is clearly not within Atom's charter, so it doesn't count. wunder -- Walter Underwood Principal Architect, Verity
Re: Posted PaceEntryOrder (was Entry order)
(I.e., I could come up with the UseLexicalOrdering extension, and require processors to understand it to use the feed, assuming our extensibility model supports that, which I very much hope it will). Ok, well I am assuming that we wont have MustUnderstand extensions, therefore all extensions must be just informative. My preference would be something like This specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. Atom Processors MAY present entries in any order, unless a specific ordering is required by an extension. Given a model of only informative metadata extensions this wouldn't be valid, unless the spec said that the order was significant, then it would be acceptable to communcate a preferred display order using extensions. The question is basically, if I have a database does it need to preserve the sequence number of the entry within a document? Display order is a different matter, but for the option of lexical order, then the answer would need to be yes, but I don't think it would be worth it. -- Dave
Re: Posted PaceEntryOrder (was Entry order)
On 5 Feb 2005, at 11:20, David Powell wrote: This specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. Atom Processors MAY present entries in any order, unless a specific ordering is required by an extension. Given a model of only informative metadata extensions this wouldn't be valid, unless the spec said that the order was significant, then it would be acceptable to communcate a preferred display order using extensions. The question is basically, if I have a database does it need to preserve the sequence number of the entry within a document? You put this in terms of databases and I put the question in terms of graphs (which if you have an rdf database to store your triples comes to the same thing). And my feeling is here that we should not have to keep the sequence numbers of the order of the entries in the document. Perhaps this is what Roy Fielding is getting at when he speaks of there being confusion on this list between the data model and the interaction model. It is important for clients when they ask for a sequence of entries to know what the order those entries are coming in. This can save them a lot of processing time. But it should not be part of the syntax to specify a preferred order of the entries. Display order is a different matter, but for the option of lexical order, then the answer would need to be yes, but I don't think it would be worth it. Display order on the client will also completely depend on what the client is trying to do. If the client is just interested in archiving all the entries, then any new feed be it an old one or a new one will be of interest: it will just be added to the database. If the client is interested in displaying the changes in a gui, this again may be completely up to the user. Some users may want only to see entries that they have read that have changed, as this may show a change of position of interest to them. Henry Story -- Dave
Re: Posted PaceEntryOrder (was Entry order)
On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham [EMAIL PROTECTED] wrote: My preference would be something like This specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. Atom Processors MAY present entries in any order, unless a specific ordering is required by an extension. (I.e., I could come up with the UseLexicalOrdering extension, and require processors to understand it to use the feed, assuming our extensibility model supports that, which I very much hope it will). -1 Atom is a Must Ignore format. I would prefer: The order of atom:entry elements is typically in reverse chronological order, though feeds MAY be constructed with entries in any order, and this specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. There is no reason to even mention how the CLIENT presents the order of the entries in this spec. -joe -- Joe Gregoriohttp://bitworking.org
Re: Posted PaceEntryOrder (was Entry order)
On Feb 5, 2005, at 6:26 AM, Joe Gregorio wrote: On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham [EMAIL PROTECTED] wrote: This specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. Atom Processors MAY present entries in any order, unless a specific ordering is required by an extension. The order of atom:entry elements is typically in reverse chronological order, though feeds MAY be constructed with entries in any order, and this specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. I'm +1 on both Mark and Joe's version, slightly stronger on Joe's because I don't think we need drag extensions in. -Tim
Re: Entry order
On Feb 5, 2005, at 5:36 AM, Danny Ayers wrote: On Thu, 3 Feb 2005 23:21:50 -0500, Bob Wyman [EMAIL PROTECTED] wrote: Ordering of the element children of atom:feed element MUST NOT be considered significant. +1. +1 - I don't care whether we say MUST NOT, or the other wording floating around about this specification assigns no semantics, but I am 100% against assigning any meaning to the order in which things appear in the feed. Every aggregator I've used allows you to sort them on any old column, and I totally can't think of a reasonable use-case in which preserving the feed order matters. -Tim
Re: Posted PaceEntryOrder (was Entry order)
On Saturday, February 5, 2005, at 09:42 AM, Tim Bray wrote: On Feb 5, 2005, at 6:26 AM, Joe Gregorio wrote: On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham [EMAIL PROTECTED] wrote: This specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. Atom Processors MAY present entries in any order, unless a specific ordering is required by an extension. The order of atom:entry elements is typically in reverse chronological order, though feeds MAY be constructed with entries in any order, and this specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. I'm +1 on both Mark and Joe's version, slightly stronger on Joe's because I don't think we need drag extensions in. -Tim I like Joe's very much--it reads with perfect clarity and I think it says all that needs to be said on the subject.
Re: Entry order
* Tim Bray [EMAIL PROTECTED] [2005-02-05 08:40-0800] On Feb 5, 2005, at 5:36 AM, Danny Ayers wrote: On Thu, 3 Feb 2005 23:21:50 -0500, Bob Wyman [EMAIL PROTECTED] wrote: Ordering of the element children of atom:feed element MUST NOT be considered significant. +1. +1 - I don't care whether we say MUST NOT, or the other wording floating around about this specification assigns no semantics, but I am 100% against assigning any meaning to the order in which things appear in the feed. +1 Although I could've lived with order being declared meaningful. The worst case is when it isn't clear whether ordering info must be preserved. Aside: sometimes in RSS1 item order relates to characteristics of the things described by the documents in the feed, rather than the docs directly (eg. job adverts, upcoming movies, ...). Dan Dan
Re: Posted PaceEntryOrder (was Entry order)
Tim Bray wrote: I'm +1 on both Mark and Joe's version, slightly stronger on Joe's because I don't think we need drag extensions in. This specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. Atom Processors MAY present entries in any order, including document order. Extensions don't get to make demands on generic Atom processors. Lots feeds will consist of entris with the same date, and lots of aggregators will just show things in the order the SAX parser sent it. Robert Sayre
Re: Posted PaceEntryOrder (was Entry order)
On Feb 5, 2005, at 4:38 AM, Henry Story wrote: You put this in terms of databases and I put the question in terms of graphs (which if you have an rdf database to store your triples comes to the same thing). And my feeling is here that we should not have to keep the sequence numbers of the order of the entries in the document. Very well said, with emphasis on have to; they shouldn't be prohibited from doing so if they want to (and I don't think you're saying otherwise). Display order on the client will also completely depend on what the client is trying to do. If the client is just interested in archiving all the entries, then any new feed be it an old one or a new one will be of interest: it will just be added to the database. +1 -- Mark Nottingham http://www.mnot.net/
Re: Posted PaceEntryOrder (was Entry order)
On 5 Feb 2005, at 18:48, Mark Nottingham wrote: On Feb 5, 2005, at 4:38 AM, Henry Story wrote: You put this in terms of databases and I put the question in terms of graphs (which if you have an rdf database to store your triples comes to the same thing). And my feeling is here that we should not have to keep the sequence numbers of the order of the entries in the document. Very well said, with emphasis on have to; they shouldn't be prohibited from doing so if they want to (and I don't think you're saying otherwise). yes, but perhaps if these were to be kept in the database they should not be saved as a direct property of the entry, but as a relation that the entry has to an event of document fetching. I am thinking here about the parallel with search engine results. The results you get from a search engine will be ordered in some way. This is inevitable. But one should be careful not to think that generally the results have any intrinsic meaning. Certainly not intrinsic in the sense that these would usefully be thought of as being properties of the web pages themselves. They are rather a factual statement about an order given by the search engine when you made a request at a certain time. Continuing along this line of thought, if you made a request to your favorite search engine to return its results in last changed order (and perhaps narrowed your request down to a specific site) then the order of the results could help you come to conclusions much faster. If could save you for example having to search through all the results if you were only looking for entries that had changed in the last day. Once you reached results that had changed before that, you would be sure that all other results were no longer relevant. I think this is probably what Roy fielding meant recently when he spoke about the difference between the model and the interaction model. In any case this should be something that one specifies at the protocol level. Henry Story Display order on the client will also completely depend on what the client is trying to do. If the client is just interested in archiving all the entries, then any new feed be it an old one or a new one will be of interest: it will just be added to the database. +1 Cool sometimes I also get +1 :-) -- Mark Nottingham http://www.mnot.net/
Re: Entry order
Graham wrote: On 5 Feb 2005, at 4:40 pm, Tim Bray wrote: I totally can't think of a reasonable use-case in which preserving the feed order matters. - The Macintouch feed is ordered in the same way as the home page, and makes no sense viewed chronologically - The BBC News feeds have the most important stories first and are much more readable and useful with the order preserved. etc etc You're shockingly small-minded sometimes Tim. Rudeness objection. cheers Bill
RE: Entry order
Danny Ayers wrote: The killer problem of using doc order is that the feed data *will* be aggregated and republished. Precisely! As the blogosphere grows and as the number of feeds grow, I feel it is inevitable that we are simply going to have to give up the current feed-oriented focus and concentrate more on the entries. Ie: It's about the Entries, Stupid!. We're seeing the same pattern in blogs that we saw with web sites. In the old days, you maintained a list of known web sites and scanned them on a regular basis. This was augmented by surfing (i.e. manual RDF...). However, today, there is simply too much information and too many sites for us all to rely on favorites lists and bookmarks. Thus, Google has become the tool for navigating between sites. What we look for today is not sites but rather pages. While today, the blogosphere is largely focused on the discussion of blogs and feeds, I feel that in the future, we'll see a growing focus on entries... Web site designers have, in many cases, already begun to learn the new design disciplines that focus on a page in isolation instead of the site-oriented disciplines that were popular in the 90's and relied on carefully planned navigation paths through a site. Today's web designer must recognize that deep pages are accessed directly -- not by navigating a path from the home page. Similarly, while today's feed developers think they can rely on presenting an entry within the context of other entries -- which relies on their entire feed being experienced or read, in the future, feed developers will come to realize that it is NOT their feeds that are read by people, rather it is the entries that get read. Thus, any relationship between entries must be contained within the entry -- it can't rely on position within feed or other contextual clues that require entry-external data. As Danny says: Far better to declare the information in the data (like the date) and let the client (or intermediary) sort according to the user's requirements. To allow document order to be significant compromises the utility of aggregation and search mechanisms. This should not be tolerated. bob wyman
RE: Entry order
Graham wrote: You're shockingly small-minded sometimes Tim. Do we really need to have this stuff in this forum? The Macintouch and BBC News feeds that you provide as examples simply demonstrate that there is a need for some mechanism to specify order relationships between entries. The mere fact that in older versions of syndication formats, document order was the only available mechanism for hinting at these relationships should not be a compelling reason to avoid defining more useful and robust order-specification mechanisms. Order relationships between entries should be specified *within* entries, not implied or derived from the context within which those entries are found. It's about the Entries, Stupid! bob wyman
RE: Entry order
--On February 3, 2005 11:21:50 PM -0500 Bob Wyman [EMAIL PROTECTED] wrote: David Powell wrote: It looks like this might have got lost accidently when the atom:head element was introduced. Previously Atom 0.3 said [1]: Ordering of the element children of atom:feed element MUST NOT be considered significant. +1. The order of entries in an Atom feed should NOT be significant. This is, I think, a very, very important point to make. -1 Is this a joke? This is like saying that the order of the entries in my mailbox is not significant. Note that ordering a mailbox by date is not the same thing as its native order. Feed order is the only way we have to show the publication order of items in a feed. I just looked at all my subscriptions, and there is only one where the order might not be relevant, a security test for RSS readers. That is clearly not within Atom's charter, so it doesn't count. wunder -- Walter Underwood Principal Architect, Verity
Re: Entry order
Tim Bray wrote: On Feb 4, 2005, at 11:27 AM, Walter Underwood wrote: Is this a joke? This is like saying that the order of the entries in my mailbox is not significant. Note that ordering a mailbox by date is not the same thing as its native order. Except for, Atom entries have a *compulsory* updated date. So I have no idea what semantics you'd attach to the natural order... -Tim Nit: they want have an ordering anymore if we allow updated dates with missing timezone information (i.e., dates with a 24h uncertainty). Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Entry order
--On February 4, 2005 11:44:31 AM -0800 Tim Bray [EMAIL PROTECTED] wrote: On Feb 4, 2005, at 11:27 AM, Walter Underwood wrote: Is this a joke? This is like saying that the order of the entries in my mailbox is not significant. Note that ordering a mailbox by date is not the same thing as its native order. Except for, Atom entries have a *compulsory* updated date. So I have no idea what semantics you'd attach to the natural order... -Tim Order the publisher wants to present them in. Conventionally, most recently published first. Entries may be updated without being reordered. If clients are told to ignore the order, and given only an updated timestamp, there is no way to show most recent headlines, which is the primary purpose of the whole family of RSS formats. Right now, you can shuffle the entries and Atom says it is the same feed. Either we need a published date stamp or we need to honor the order. wunder -- Walter Underwood Principal Architect, Verity
Re: Entry order
If clients are told to ignore the order, and given only an updated timestamp, there is no way to show most recent headlines... At a single moment within a feedstream, sure... but the next time an entry is added to that feed, I'll have no problem letting the user know that this is new stuff. Either we need a published date stamp or we need to honor the order. Maybe I've missed something amidst the chao-- enthusiastic array of Paces lately, but don't we *have* a published date? -- Roger Benningfield JournURL
Re: Entry order
--On February 4, 2005 4:28:53 PM -0600 Roger B. [EMAIL PROTECTED] wrote: If clients are told to ignore the order, and given only an updated timestamp, there is no way to show most recent headlines... At a single moment within a feedstream, sure... but the next time an entry is added to that feed, I'll have no problem letting the user know that this is new stuff. But if three are added, you can't order those three. wunder -- Walter Underwood Principal Architect, Verity
Re: Posted PaceEntryOrder (was Entry order)
On 3 Feb 2005, at 12:18 am, David Powell wrote:
{{{ This specification assigns no significance to the order of
atom:entry elements within the feed. Processors MAY present entries in
a different order to which they are appear in an Atom Feed Document.
}}}
First sentence no, but the second sentence says all that we need to say
and no more.
Graham
smime.p7s
Description: S/MIME cryptographic signature
Re: Posted PaceEntryOrder (was Entry order)
My preference would be something like This specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. Atom Processors MAY present entries in any order, unless a specific ordering is required by an extension. (I.e., I could come up with the UseLexicalOrdering extension, and require processors to understand it to use the feed, assuming our extensibility model supports that, which I very much hope it will). Seem reasonable? On Feb 2, 2005, at 4:18 PM, David Powell wrote: This specification assigns no significance to the order of atom:entry elements within the feed. Processors MAY present entries in a different order to which they are appear in an Atom Feed Document. -- Mark Nottingham http://www.mnot.net/
RE: Entry order
David Powell wrote: It looks like this might have got lost accidently when the atom:head element was introduced. Previously Atom 0.3 said [1]: Ordering of the element children of atom:feed element MUST NOT be considered significant. +1. The order of entries in an Atom feed should NOT be significant. This is, I think, a very, very important point to make. bob wyman
