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: 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: 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: 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: 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/
