Spec wording bug?
In draft-ietf-atompub-format-11 under 4.2.7 The atom:link Element, compare and contrast: [[ 4.2.7.4 The hreflang Attribute The hreflang attribute's content describes the language of the resource pointed to by the href attribute. ... 4.2.7.6 The length Attribute The length attribute indicates an advisory length of the linked content in octets; it is a hint about the content length of the representation returned when the IRI in the href attribute is mapped to a URI and dereferenced. ]] I believe the language of the resource for hreflang makes no sense - it will be the *representations* that are associated with languages, and the implies a single language - there may be more than one. Cheers, Danny. -- http://dannyayers.com
Re: Feed History -04
The approach I took in -04 was to say that the pseudo-ordering introduced by the mechanism was ONLY meaningful for the purposes of reconstituting the feed; it's still up to the feed itself to determine what the ordering of entries means (or doesn't). That avoids a lot of problems, although it does require some careful wording. Also -- I'd think that the last link is already covered by self, no? If not, there's some pretty serious confusion about what 'self' means. On 13/10/2005, at 8:01 PM, Antone Roundy wrote: On Oct 13, 2005, at 7:58 PM, Eric Scheid wrote: On 14/10/05 9:18 AM, James M Snell [EMAIL PROTECTED] wrote: Excellent. If this works out, there is an opportunity to merge the paging behavior of Feed History, OpenSearch and APP collections into a single set of paging link relations (next/previous/first/last). 'first' or 'start'? Do we need to define what 'first' means though? I recall a dissenting opinion on the wiki that the 'first' entry could be at either end of the list, which could surprise some. Yeah, that's a good question. Maybe calling them top and bottom would work better. Considering that the convention is to put the newest entry at the top of a feed document, top might be more intuitively understandable as being the new end. You might also rename next and previous (or is it previous and next?) to down and up. There's SOME chance of that getting confused with hierarchical levels, but I could live with that. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
Re: Feed History -04
* Eric Scheid [EMAIL PROTECTED] [2005-10-14 17:35]: Why would anyone want to know the 'last' link? One use case is that one could take note of the 'last' URI, and then later find out what the 'last' URI now is ... and if they are different then obviously more has been added and it's time to go fetch. If you really want this, don’t forget to to legislate this expectation. Otherwise some people may devise clever (or “clever”) stuff which breaks this expectation. Your example of breaking atom:[EMAIL PROTECTED]'self']/@href = atom:[EMAIL PROTECTED]'last']/@href is a perfect demonstration of how someone may do something legal that may break (naïve?) expectations. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed History -04
Lindsley Brett-ABL001 wrote: I have a suggestion that may work. The issue of defining what is prev and next with respect to a time ordered sequence seems to be a problem. How about defining the link relationships in terms of time - such as newer and older or something like that. That way, the collection returned should be either newer (more recent updated time) or older (later updated time) with respect to the current collection doc. Wouldn't it be better to share the same link relations between feeds sorted by date/time or some other priority (e.g. OpenSearch results)? -- Thomas Broyer
Re: Spec wording bug?
At 1:43 PM +0200 10/14/05, Danny Ayers wrote: In draft-ietf-atompub-format-11 under 4.2.7 The atom:link Element, compare and contrast: [[ 4.2.7.4 The hreflang Attribute The hreflang attribute's content describes the language of the resource pointed to by the href attribute. ... 4.2.7.6 The length Attribute The length attribute indicates an advisory length of the linked content in octets; it is a hint about the content length of the representation returned when the IRI in the href attribute is mapped to a URI and dereferenced. ]] I believe the language of the resource for hreflang makes no sense - it will be the *representations* that are associated with languages, I think that's being way too picky. It makes sense that content (the generic term) might have a language associated with it. and the implies a single language - there may be more than one. That's true. And it matches the XML 1.0 spec exactly. --Paul Hoffman, Director --Internet Mail Consortium
Re: Feed History -04
On 14/10/2005, at 9:22 AM, Lindsley Brett-ABL001 wrote: I have a suggestion that may work. The issue of defining what is prev and next with respect to a time ordered sequence seems to be a problem. How about defining the link relationships in terms of time - such as newer and older or something like that. That way, the collection returned should be either newer (more recent updated time) or older (later updated time) with respect to the current collection doc. A feed isn't necessarily a time-ordered sequence. Even a feed reconstructed using fh:prev (or a similar mechanism) could have its constituent parts generated on the fly, e.g., in response to a search query. The ordering of the entries may not matter, but the ordering of the documents does. Starting with the active feed document, you need to know whether you should be following a series of prev links or next links in order to traverse the archives back through time. While your feed history spec used prev for that purpose, previous implementations of atom:link appear to have used next. I agree that it's important to honour the document order; that's what FH tries to do. I'm a little surprised to hear you say that people thought that this was previously 'next'; I'd never heard that (but will be happy to put a note in). I was going to suggest that initially but I don't think it's strictly true. The spec says that self identifies a resource *equivalent* to the containing element. Considering that an archived document and the active feed document will quite likely have no entries in common I think it's a bit of a stretch to claim them equivalent. Derived would be a better relationship IMHO. Hmm. Yeah, I see what you're saying. Actually, I think this is an opportunity -- we we define a new link relation to the subscription document, and specify that it can only occur in archive documents, it obviates the need for a separate fh:archive flag, which in turn means that you don't have to declare two namespaces to use fh in RSS archive documents -- which was one of the things making me reluctant to switch over to atom:link. How about: atom:link rel=subscription href=.../ ? -- Mark Nottingham http://www.mnot.net/
Re: Spec wording bug?
On Oct 14, 2005, at 5:43 AM, Danny Ayers wrote: I believe the language of the resource for hreflang makes no sense - it will be the *representations* that are associated with languages, and the implies a single language - there may be more than one. If content negotiation might be used to select from among different languages (ie. if multiple representations are available from the same URI), then perhaps the hreflang attribute should be omitted. Were we to have allowed multiple languages to be specified in the same hreflang attribute to cover such cases, the wording would be incorrect, but since we didn't, I think it's correct as it is.
Re: Feed History -04
Mark Nottingham wrote: How about: atom:link rel=subscription href=.../ ? I always thought this was the role of @rel=self to give the URI you should subscribe to, though re-reading the -11 it deals with a resource equivalent to the containing element. 1. Isn't a resource equivalent to the containing element the same as an alternate version of the resource described by the containing element? 2. Is the answer to 1. is no then what does a resource equivalent … mean? Is it really different than the URI you should subscribe to (at least if @type=application/atom+xml)? -- Thomas Broyer
Re: Feed History -04
That's what I thought too, but the words in the spec don't bear it out; a resource equivalent to the containing element is a little hard to interpret (there is no equivalence function for Web resources, by definition), but it's a lot closer to something you dereference to get the same thing as what's in the containing element than to something you dereference to get a potentially completely different thing. Arguably, there is sometimes a use case for the current definition of self, so it's probably best to just define a new link relation. On 14/10/2005, at 10:28 AM, Thomas Broyer wrote: Mark Nottingham wrote: How about: atom:link rel=subscription href=.../ ? I always thought this was the role of @rel=self to give the URI you should subscribe to, though re-reading the -11 it deals with a resource equivalent to the containing element. 1. Isn't a resource equivalent to the containing element the same as an alternate version of the resource described by the containing element? 2. Is the answer to 1. is no then what does a resource equivalent … mean? Is it really different than the URI you should subscribe to (at least if @type=application/atom+xml)? -- Thomas Broyer -- Mark Nottingham http://www.mnot.net/
Re: Feed History -04
On Oct 14, 2005, at 11:13 AM, Mark Nottingham wrote: On 14/10/2005, at 9:22 AM, Lindsley Brett-ABL001 wrote: I have a suggestion that may work. The issue of defining what is prev and next with respect to a time ordered sequence seems to be a problem. How about defining the link relationships in terms of time - such as newer and older or something like that. That way, the collection returned should be either newer (more recent updated time) or older (later updated time) with respect to the current collection doc. A feed isn't necessarily a time-ordered sequence. Even a feed reconstructed using fh:prev (or a similar mechanism) could have its constituent parts generated on the fly, e.g., in response to a search query. The OpenSearch case mentioned by Thomas is what convinced me that terms related to temporal ordering aren't appropriate (what a pity, since newer and older are the perfect terms for time ordered sequences of feed documents!) Previous and next suffer from the fact that they could easily be interpreted differently in different use cases. For example, for OpenSearch results pages, clearly prev points to the search results that come up on top and next to the lower results. But in a conventional syndication feed, next could easily be taken to mean either the next batch of entries as you track back towards the beginning of time from where you started (which is usually going to be the growing end of the feed), or a batch of entries containing the entries that were published next after the ones in this batch. I'd have to look at the document to remind myself of which next means, because either makes just as much sense to me. Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? Antone
Re: Feed History -04
On Oct 14, 2005, at 11:28 AM, Thomas Broyer wrote: Mark Nottingham wrote: How about: atom:link rel=subscription href=.../ ? I always thought this was the role of @rel=self to give the URI you should subscribe to, though re-reading the -11 it deals with a resource equivalent to the containing element. That's what some of us wanted it to be and thought it was intended to be. The language that made it into the spec certainly falls short of expressing what was in PaceFeedLink, which is the proposal that added @rel=self [1]. 1. Isn't a resource equivalent to the containing element the same as an alternate version of the resource described by the containing element? That's how I would read that language knowing nothing of the history of that part of the spec. I think some people intended equivalent to mean it may not be a different copy of the same bits, but whatever it is, it contains the same bits (or at least the same code points, if it happens to be transcoded). 2. Is the answer to 1. is no then what does a resource equivalent … mean? Is it really different than the URI you should subscribe to (at least if @type=application/atom+xml)? I think what some people want that to mean is here's a place you could get the feed, but I'm not making any assertions regarding whether it's preferable to get it from there or somewhere else. [1] http://www.imc.org/atom-syntax/mail-archive/msg15062.html
Re: Feed History -04
Mark Nottingham wrote: I agree that it's important to honour the document order; that's what FH tries to do. I'm a little surprised to hear you say that people thought that this was previously 'next'; I'd never heard that (but will be happy to put a note in). Mark Pilgrim's article on XML.com discussing the Atom Link Model: http://www.xml.com/pub/a/2004/06/16/dive.html I can't say I've seen it widely used, but there is at least one occurrence in the wild (Mark's archives). Hmm. Yeah, I see what you're saying. Actually, I think this is an opportunity -- we we define a new link relation to the subscription document, and specify that it can only occur in archive documents, it obviates the need for a separate fh:archive flag, which in turn means that you don't have to declare two namespaces to use fh in RSS archive documents -- which was one of the things making me reluctant to switch over to atom:link. How about: atom:link rel=subscription href=.../ Yeah, I think that's a great idea. I'm not sure about the name though. Would it not be better as a verb (say subscribe) since the link is effectively providing you with a url with which you can subscribe to the feed. This seems to me more in line with the verb-based link relations being used in the Atom publishing protocol. Admittedly in this case the link could just as easily be interpreted as a passive pointer to a document rather than an operation as such. I'm not really arguing strongly either way. Just something to think about. Regards James
Re: Feed History -04
At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
Re: Feed History -04
Am 14.10.2005 um 20:00 schrieb James Holderness: Mark Nottingham wrote: Hmm. Yeah, I see what you're saying. Actually, I think this is an opportunity -- we we define a new link relation to the subscription document, and specify that it can only occur in archive documents, it obviates the need for a separate fh:archive flag, which in turn means that you don't have to declare two namespaces to use fh in RSS archive documents -- which was one of the things making me reluctant to switch over to atom:link. How about: atom:link rel=subscription href=.../ Yeah, I think that's a great idea. I'm not sure about the name though. Would it not be better as a verb (say subscribe) since the link is effectively providing you with a url with which you can subscribe to the feed. This seems to me more in line with the verb-based link relations being used in the Atom publishing protocol. Admittedly in this case the link could just as easily be interpreted as a passive pointer to a document rather than an operation as such. I'm not really arguing strongly either way. Just something to think about. The idea is excellent. As for the naming sugar of the relation head, anchor or origin could work also. //Stefan
Re: Spec wording bug?
On 10/14/05, Robert Sayre [EMAIL PROTECTED] wrote: I don't understand the second issue being raised here. Could someone try again? Robert - sorry, I obviously wasn't very clear. I only wished to bring a single issue to the list's attention, the discrepancy between the wording of the spec on hreflang, and what I believe to be its intended meaning in particular in terms of one of the cited references (RFC 3986). 4.2.7.4 The hreflang Attribute The hreflang attribute's content describes the language of the resource pointed to by the href attribute. A resource in the sense of RFC 3986, as far as I can tell, may have multiple representations associated with any number of languages. As far as I'm aware, the only connection between the language(s) and the resource is through the representation(s). This view is reflected in the the other piece of the Atom spec I quoted: 4.2.7.6 The length Attribute The length attribute indicates an advisory length of the linked content in octets; it is a hint about the content length of the representation returned when the IRI in the href attribute is mapped to a URI and dereferenced. ]] Antone - I could be wrong, but I don't think this is a content negotiation issue, simply that the wording munges the resource with its representation(s). I believe this inconsistent with the WebArch conceptual model assumed by the rest of the Atom spec, and actually inconsistent with that other definition inside the spec. Paul - as I understand it the content isn't identical with the resource. This distinction may appear picky, but given that the other definition quoted manages consistency with the referenced specs, it appears to be possible without much extra effort. I must confess I have no idea of the IETF line on where accuracy ends and pickiness begins, or what might be appropriate action under the process - on that I will happily defer to you. I'm afraid I don't know what you are referring here: DA: and the implies a single language - there may be more than one. PH: That's true. And it matches the XML 1.0 spec exactly. Cheers, Danny. -- http://dannyayers.com
RE: Feed History -04
+1 The meaning of these terms depends so much upon the feed it is being used within. That and your own mental model. If you visualize a feed like this: --- | | | | | | | -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Nottingham Sent: Friday, October 14, 2005 11:28 AM To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: Feed History -04 At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
RE: Feed History -04
I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. +1 Maybe this goes without saying, but I think the spec needs to either: a) define these terms clearly and how they should be used and interpreted (in which case it doesn't matter what words we use), or b) provide a mechanism for the feed to define their meaning relative to the feed (perhaps James' FeedRank extension is relevant here?) - i.e. this feed sorts items chronologically in ascending order. With that information, next and previous become more meaningful. Without either (a) or (b) then the meaning of whatever terms we choose will depend too much on the developer's mental model for feeds. For example, if you visualize a feed like this (e.g. a web page's chronologically sorted list): --- top | |- entry | |- entry | |- entry | --- bottom Then the terms up and down are quite meaningful, and next and prev a little ambiguous (am I top-down kinda guy, or a bottom-up?). Of course you then have to be clear to what top and bottom means. Then if you visualize feeds like this (like a linear timeline for example): ||||| entry | entry entry Then up and down are the terms that become less meaningful. Yadda yadda yadda. My feeling is that erring on the side of more broadly applicable, and semantically well know terms like next and previous will be more useful to extensions wishing to extend the metaphor or model for their own purposes (the FeedRank extension comes to mind specifically). I can even see value for a feed to specify more information about its result set: link rel=next href=foo?31-40 / link rel=previous href=foo?1-10 / result-set size10/limit start21/start end30/end total55/total sort/feed/entry/published/sort orderascending/order /result-set -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Nottingham Sent: Friday, October 14, 2005 11:28 AM To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: Feed History -04 At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
Re: Feed History -04
On 10/14/05, Antone Roundy [EMAIL PROTECTED] wrote: On Oct 14, 2005, at 11:13 AM, Mark Nottingham wrote: On 14/10/2005, at 9:22 AM, Lindsley Brett-ABL001 wrote: I have a suggestion that may work. The issue of defining what is prev and next with respect to a time ordered sequence seems to be a problem. How about defining the link relationships in terms of time - such as newer and older or something like that. That way, the collection returned should be either newer (more recent updated time) or older (later updated time) with respect to the current collection doc. A feed isn't necessarily a time-ordered sequence. Even a feed reconstructed using fh:prev (or a similar mechanism) could have its constituent parts generated on the fly, e.g., in response to a search query. The OpenSearch case mentioned by Thomas is what convinced me that terms related to temporal ordering aren't appropriate (what a pity, since newer and older are the perfect terms for time ordered sequences of feed documents!) Previous and next suffer from the fact that they could easily be interpreted differently in different use cases. For example, for OpenSearch results pages, clearly prev points to the search results that come up on top and next to the lower results. But in a conventional syndication feed, next could easily be taken to mean either the next batch of entries as you track back towards the beginning of time from where you started (which is usually going to be the growing end of the feed), or a batch of entries containing the entries that were published next after the ones in this batch. I'd have to look at the document to remind myself of which next means, because either makes just as much sense to me. True, but I don't think that means that the terms have to be abandoned, but that these examples need to be supported by spec text. That is, define 'next' as pointing to the next document in a series of documents, the whole series of documents containing a series of Atom Entries whose order is specific to the service providing it. -joe -- Joe Gregoriohttp://bitworking.org
Re: Atom Comments Extension
On Thu, 13 Oct 2005, A. Pagaltzis wrote: Hi James, * James M Snell [EMAIL PROTECTED] [2005-09-08 06:45]: If anyone has any further comments on the draft, please let me know. I am alarmed that this draft does *not even once* explicitly mention the fact that idrefs are expected to be derived from Atom Entry IDs. No particular interpretation of @idrefÿÿs content is prescribed at all. I believe that's because they're not necessarily expected to be derived from Atom Entry IDs. The idref is dependant on the type of content being referenced. For an application/atom+xml content type, the reference would be a Atom Entry ID. Other source documents than Atom may be used as thread references - otherwise the threading system would be limited to only allowing Atom people to respond to Atom people. I think this is a terrible mistake. If consumers cannot have a uniform expectation of the meaning of the @idref value, there is no way for an Atom producer to know how to express a particular notion. I am uncomfortably reminded of RSS. If we do want consumers to have a uniform expectation of the meaning of such a value, then people who decide to stick something else in there will fail to interoperate with the majority of consumers. In other words, this is an obvious case for a SHOULD-level requirement. So, I believe the draft as it stands is seriously lacking because it misses one crucial sentence in the section 3 paragraph that deals with inReplyToNonDereferenceable. As to *what* the SHOULD-level requirement should be, I think there will be little argument that the ID of an Atom Entry is it. If any additional wording is necessary, then it should be explicit that it only relates to the media type of 'application/atom+xml'. It is, in my opinion, redundant to say this because ID reference for a application/atom+xml document is the Atom Entry ID. Other media types would use their own forms of identifiers. [snip] -- Gerph http://gerph.org/ ... I can see it, but it's only real when they hide me from the truth.
Re: Feed History -04
The way I look at this is in terms of a single linked list of feeds. The ordering of the entries within those feeds is irrelevant. The individual linked feeds MAY be incremental (e.g. blog entries,etc) or may be complete (e.g. lists,etc). Simply because a feeds are linked, no assumption should be made as to whether or not the entries in those feeds share any form of ordered relationship. link rel=first / is the first feed in the linked list link rel=next / is the next feed in the linked list link rel=previous / is the previous feed in the linked list link rel=last / is the last feed in the linked list. Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. For feed history, it would work something like: feed ... link rel=self href=...feed1 / link rel=next href=...next / link rel=last href=...feed3 / ... /feed feed ... link rel=self href=...feed2 / link rel=previous href=...feed1 / link rel=next href=...feed3 / link rel=first href=...feed1 / link rel=last href=...feed3 / ... /feed feed ... link rel=self=href=...feed3 / link rel=previous href=...feed2 / link rel=first href=...feed1 / ... /feed - James Mark Nottingham wrote: At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
Re: Feed History -04
This looks good. Is the 'first' the feed document that changes, whereas 'next' and 'last' point to the archives? (in a feed history context?) Henry On Fri, 14 Oct 2005, James M Snell wrote: The way I look at this is in terms of a single linked list of feeds. The ordering of the entries within those feeds is irrelevant. The individual linked feeds MAY be incremental (e.g. blog entries,etc) or may be complete (e.g. lists,etc). Simply because a feeds are linked, no assumption should be made as to whether or not the entries in those feeds share any form of ordered relationship. +1 link rel=first / is the first feed in the linked list link rel=next / is the next feed in the linked list link rel=previous / is the previous feed in the linked list link rel=last / is the last feed in the linked list. Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. For feed history, it would work something like: feed ... link rel=self href=...feed1 / link rel=next href=...next / link rel=last href=...feed3 / ... /feed feed ... link rel=self href=...feed2 / link rel=previous href=...feed1 / link rel=next href=...feed3 / link rel=first href=...feed1 / link rel=last href=...feed3 / ... /feed feed ... link rel=self=href=...feed3 / link rel=previous href=...feed2 / link rel=first href=...feed1 / ... /feed - James Mark Nottingham wrote: At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
Re: Feed History -04
On 10/14/05, James M Snell [EMAIL PROTECTED] wrote: The way I look at this is in terms of a single linked list of feeds. James is 100% right. Think of any feed as a google search result, ordered in terms of relevance. On your average blog, the newest post is always the most relevant :). I would support mnot's draft moving onto the standards track if it followed the linking scheme outlined by James. The RSS way of doing it could be kept alongside, if that's politically necessary. If Mark opts not to support atom:link, my support changes to silence, and I will go right ahead and implement the three link relations I need in my Atom implementations: next, prev, and profile. Robert Sayre
Re: Feed History -04
* James M Snell [EMAIL PROTECTED] [2005-10-15 00:25]: Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. head/tail? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed History -04
What in the world is wrong with first and last? ;-) I just don't get it. A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [2005-10-15 00:25]: Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. head/tail? Regards,
Re: Feed History -04
Right. A few questions that pop up: 1) Is it a closed or open set? If it's open (and I think 99% of feeds are), what does last mean? My answer is that it's probably an open set, so last doesn't mean much that's useful (unless it's conflated with the subscription feed; see below). 2) What's the relationship between these feed documents and the feed document that people subscribe to? I think the subscription feed needs to be pinned to one end of the set (which is what FH does now). Otherwise, it becomes difficult to figure out whether you have the complete set or not by polling. On 14/10/2005, at 3:16 PM, James M Snell wrote: The way I look at this is in terms of a single linked list of feeds. The ordering of the entries within those feeds is irrelevant. The individual linked feeds MAY be incremental (e.g. blog entries,etc) or may be complete (e.g. lists,etc). Simply because a feeds are linked, no assumption should be made as to whether or not the entries in those feeds share any form of ordered relationship. link rel=first / is the first feed in the linked list link rel=next / is the next feed in the linked list link rel=previous / is the previous feed in the linked list link rel=last / is the last feed in the linked list. Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. For feed history, it would work something like: feed ... link rel=self href=...feed1 / link rel=next href=...next / link rel=last href=...feed3 / ... /feed feed ... link rel=self href=...feed2 / link rel=previous href=...feed1 / link rel=next href=...feed3 / link rel=first href=...feed1 / link rel=last href=...feed3 / ... /feed feed ... link rel=self=href=...feed3 / link rel=previous href=...feed2 / link rel=first href=...feed1 / ... /feed - James Mark Nottingham wrote: At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems _ ___ BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
Re: Feed History -04
This leads to: Subscription feed: - can contain link/@rel=prev, OR - can contain fh:incremental = false Archive feed: - can contain link/@rel=prev and/or link/@rel=next - can contain link/@rel=subscribe (effectively gives you last) - link/@rel=subscribe has a semantic of if you want to subscribe to this feed, use the linked document, not this one. The reconstruction algorithm is pretty much the same as in -04. The only dangling point is first. I'm not especially against it, but what's the use case? On 14/10/2005, at 4:53 PM, Mark Nottingham wrote: Right. A few questions that pop up: 1) Is it a closed or open set? If it's open (and I think 99% of feeds are), what does last mean? My answer is that it's probably an open set, so last doesn't mean much that's useful (unless it's conflated with the subscription feed; see below). 2) What's the relationship between these feed documents and the feed document that people subscribe to? I think the subscription feed needs to be pinned to one end of the set (which is what FH does now). Otherwise, it becomes difficult to figure out whether you have the complete set or not by polling. On 14/10/2005, at 3:16 PM, James M Snell wrote: The way I look at this is in terms of a single linked list of feeds. The ordering of the entries within those feeds is irrelevant. The individual linked feeds MAY be incremental (e.g. blog entries,etc) or may be complete (e.g. lists,etc). Simply because a feeds are linked, no assumption should be made as to whether or not the entries in those feeds share any form of ordered relationship. link rel=first / is the first feed in the linked list link rel=next / is the next feed in the linked list link rel=previous / is the previous feed in the linked list link rel=last / is the last feed in the linked list. Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. For feed history, it would work something like: feed ... link rel=self href=...feed1 / link rel=next href=...next / link rel=last href=...feed3 / ... /feed feed ... link rel=self href=...feed2 / link rel=previous href=...feed1 / link rel=next href=...feed3 / link rel=first href=...feed1 / link rel=last href=...feed3 / ... /feed feed ... link rel=self=href=...feed3 / link rel=previous href=...feed2 / link rel=first href=...feed1 / ... /feed - James Mark Nottingham wrote: At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
Re: Feed History -04
Subscription feed: - can contain link/@rel=prev, OR - can contain fh:incremental = false I never did understand this. Why is fh:incremental needed here? From a feed history point of view you either have a history (a prev link is present) or you don't. That's all an Atom processor needs in order to reconstruct the feed. I get that a feed producer may want to provide a non-incremental feed (top 10, todo lists, playlists, etc), but I don't see what that has to do with feed history. Wouldn't that be better suited in a separate extension along with whatever other meta-information might be appropriate for non-incremental lists? Archive feed: - can contain link/@rel=prev and/or link/@rel=next - can contain link/@rel=subscribe (effectively gives you last) - link/@rel=subscribe has a semantic of if you want to subscribe to this feed, use the linked document, not this one. The reconstruction algorithm is pretty much the same as in -04. The only dangling point is first. I'm not especially against it, but what's the use case? I'm not especially for it, but it's theoretically possible that someone subscribing to a feed for the first time may want to download the full archives. Depending on their processing model, this may be more convenient starting with the oldest archive and working forwards in time Regards James
Re: Feed History -04
On 14/10/2005, at 8:01 PM, James Holderness wrote: I never did understand this. Why is fh:incremental needed here? From a feed history point of view you either have a history (a prev link is present) or you don't. That's all an Atom processor needs in order to reconstruct the feed. I get that a feed producer may want to provide a non-incremental feed (top 10, todo lists, playlists, etc), but I don't see what that has to do with feed history. Wouldn't that be better suited in a separate extension along with whatever other meta-information might be appropriate for non-incremental lists? It's more relevant than it seems at first glance. Currently, most (if not practically all) feed aggregators will keep a history by default, without information otherwise. Introducing a standard extension to enable that necessitates that there be a way to say don't do that. The only dangling point is first. I'm not especially against it, but what's the use case? I'm not especially for it, but it's theoretically possible that someone subscribing to a feed for the first time may want to download the full archives. Depending on their processing model, this may be more convenient starting with the oldest archive and working forwards in time Yeah, that's pretty much where I'm at; supplying effectively gives *two* ways to reconstruct the state of a feed, meaning that both would need to be supported (and optimised) by implementations, which isn't so great unless there's a compelling need for it. -- Mark Nottingham http://www.mnot.net/
Re: Feed History -04
Mark Nottingham wrote: Right. A few questions that pop up: 1) Is it a closed or open set? If it's open (and I think 99% of feeds are), what does last mean? My answer is that it's probably an open set, so last doesn't mean much that's useful (unless it's conflated with the subscription feed; see below). My answer would be: if last is used, it's a closed set; if last is not used, it's an open set. 2) What's the relationship between these feed documents and the feed document that people subscribe to? I think the subscription feed needs to be pinned to one end of the set (which is what FH does now). Otherwise, it becomes difficult to figure out whether you have the complete set or not by polling. I think this will be dependent on the context in which the link rels are used. The subscription link rel you've suggested is a good solution to this problem. Within any of the feeds in the set, the subscription link rel would point to the feed that should be subscribed to -- regardless of whether the subscription feed appears at the start or end of the set. On 14/10/2005, at 3:16 PM, James M Snell wrote: The way I look at this is in terms of a single linked list of feeds. The ordering of the entries within those feeds is irrelevant. The individual linked feeds MAY be incremental (e.g. blog entries,etc) or may be complete (e.g. lists,etc). Simply because a feeds are linked, no assumption should be made as to whether or not the entries in those feeds share any form of ordered relationship. link rel=first / is the first feed in the linked list link rel=next / is the next feed in the linked list link rel=previous / is the previous feed in the linked list link rel=last / is the last feed in the linked list. Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. For feed history, it would work something like: feed ... link rel=self href=...feed1 / link rel=next href=...next / link rel=last href=...feed3 / ... /feed feed ... link rel=self href=...feed2 / link rel=previous href=...feed1 / link rel=next href=...feed3 / link rel=first href=...feed1 / link rel=last href=...feed3 / ... /feed feed ... link rel=self=href=...feed3 / link rel=previous href=...feed2 / link rel=first href=...feed1 / ... /feed - James Mark Nottingham wrote: At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems _ ___ BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
Re: Feed History -04
On 15/10/05 8:28 AM, Henry Story [EMAIL PROTECTED] wrote: Is the 'first' the feed document that changes, whereas 'next' and 'last' point to the archives? (in a feed history context?) My thinking is that of the two ends, 'first' and 'last', it would normally be the 'first' end that is anchored, while the 'last' end would shift as more is added. e.
Re: Feed History -04
On 14/10/2005, at 8:32 PM, James M Snell wrote: 1) Is it a closed or open set? If it's open (and I think 99% of feeds are), what does last mean? My answer would be: if last is used, it's a closed set; if last is not used, it's an open set. Can you walk me through a use case where this would be desirable? E.g. what would the subscription URI be, would any of the entries be updated, and how if so? In what scenario would having a closed set feed be useful? Separately, you say: The first may not be relevant in the Feed history case but does come into play when thinking about paged search results, sequences of linked, non-incremental feeds, etc. How? Can you give us a bit more flesh for the use case? Again, I'm not saying it's bad, but I don't see how it's useful in a feed (as opposed to a Web page). 2) What's the relationship between these feed documents and the feed document that people subscribe to? I think the subscription feed needs to be pinned to one end of the set (which is what FH does now). Otherwise, it becomes difficult to figure out whether you have the complete set or not by polling. I think this will be dependent on the context in which the link rels are used. The subscription link rel you've suggested is a good solution to this problem. Within any of the feeds in the set, the subscription link rel would point to the feed that should be subscribed to -- regardless of whether the subscription feed appears at the start or end of the set. What would the algorithm be for assuring that you have the complete state of the feed, without necessitating traversal of the entire feed every time? Cheers, -- Mark Nottingham http://www.mnot.net/
