Re: New Link Relations -- Ready to go?
James M Snell wrote: I'm perfectly happy with leaving previous and next free of any semantics right now and letting the market sort things out. If more specific link relations prove to be necessary, then so be it, define the more specific link relations. If the market can get by with generic links + some kind of extra flag (e.g. incremental=true, etc) then great. if your case (b) dies off... that's great too. The point is, let's not over specify this thing right now; leave it open enough for the market to figure out how to use it. What are the use cases right now? - Mark's proposed feed state reconstruction - OpenSearch result feeds chunking This is just paging. What is it also allowing? - publish any non-incremental (i.e. non time-based, like OpenSearch results) feeds chunked in small documents (Top 50 in 5 pages of 10 entries) What is it not covering? - linking between snapshots of non-incremental feeds (last week's Top 50, OpenSearch result of previous query) - linking between different sites (i.e. webrings) This has not yet proven to be really needed (e.g. the Top 50 web site I saw didn't provide archives of previous rankings). When there'll be such a need, then we'll define a new link relation (I already proposed archives/history to link to a table of contents feed allowing navigation to e.g. snapshots of non-incremental feeds; another link relation for the webring use case if it proves to be needed one day). -- Thomas Broyer
Re: New Link Relations -- Ready to go?
James Holderness wrote: Thomas Broyer wrote: As I already explained, paging is orthogonal to the incremental nature of a feed. An incremental feed will be chunked as explained in Mark's current Feed History draft (just use an atom:[EMAIL PROTECTED]previous] instead of the fh:prev extension element) and a non-incremental feed as described in the OpenSearch result 1.1 draft. I beg to differ. I think the incremental state of a feed is very relevant to paging. If the aggregator does not know that a feed is non-incremental it will not be able to process the feed document in a meaningful manner. Yes, but that's orthogonal to paging. And when I say non-incremental I mean something like a Top 10 list where the entries in the feed document are a complete replacement for any entries that the aggregator may have previously received from that feed. I have the same definition. What's the difference between a search feed and a non-incremental feed? Aren't search feeds one facet of non-incremental feeds? Not necessarily, no. A search feed could quite easily be implemented as an incremental feed. This is the most sensible approach since it would allow the feed to be viewed in all existing aggregators without requiring a special knowledge of non-incremental feeds. The initial feed document consists of all known results at the time the search is initiated. As new results are discovered over time, the feed can be updated by adding new entries to the top of the feed in much the same way that new entries would be added to the top of a blogging feed. In fact, if you do a search with something like feedster, this is exactly the sort of feed you will get back. You're describing the PubSub behaviour, which is not IMO a search engine but an aggregator with filtering capabilities. PubSub filters are quite similar to the category feeds you see sometimes: I don't want the whole blog entries, just the ones belonging to that category, or tagged with that word. With PubSub, you say I don't want the whole web entries, just the one matching that filter. You're not describing a search feed (or maybe more a search *result* feed, like OpenSearch result feeds) but a filtered aggregate feed (as published by PubSub). However, an incremental feed could take advantage of differentiating between paging and archive linking: if linking to archives uses an atom:[EMAIL PROTECTED]archives] (or call it history if you prefer) to point at an incremental feed where each entry describes an archived set of entries (see [1] for a more detailed example); such a feed has the advantage of paging that it allows direct access to a specific point of time inside the feed pages. Each archived set of entries could for example cover one or two week, so a user could navigate through the feed state or feed history not only by going from pages to pages but also by accessing archived chunks via an index or table of contents. This is all very interesting, but not possible without more link extensions which don't exist yet. Wait a bit and I'll propose them for registration. When they'll exist, what would become your argument? With what we have so far we can do incremental feed archives; we can do at least some form of searching; we can do non-incremental feeds (of the Top 10 variety) with history. I think that's a good start. But we also want paged non-incremental feeds (OpenSearch result feeds), while non-incremental feeds with history have not yet proven to be needed. You're trying to describe incremental feed paging and navigation through non-incremental feed snapshots with the same link relation. When people will want non-incremental feed paging (and this is already a need), we'll have two link relations related to paging (for incremental and non-incremental feeds) and one that can also be used to navigate into non-incremental feeds history. Here's a chunked incremental feed (each chunk has 10 entries): 111 21 31 41 51 61 71 81 |||||||||| ^^ `' This is a chunk. present time - past previous/next link from chunk to chunk. Entries are added into or before the #1 chunked above. Here's a chunked non-incremental feed (e.g. OpenSearch result feed; each chunk has 10 entries): 111 21 31 41 51 61 71 81 |||||||||| ^^ `' This is a chunk. ++ - relevance -- -- previous/next link from chunk to chunk. Here are non-chunked non-incremental feeds (e.g. Top 10 feeds with history): 1 || - Oct. 24 Top 10 1 || - Oct. 17 Top 10 1 || - Oct. 10 Top 10 previous/next would link from snapshot to snapshot ?! And finally, here are chunked non-incremental feeds (e.g. Top 50 feeds with history, each chunk has 10 entries): ++ -- ranking --- -- 111 21 31 41 51 61 71 81
Re: New Link Relations -- Ready to go?
On 24/10/05 5:31 PM, Thomas Broyer [EMAIL PROTECTED] wrote: This has not yet proven to be really needed (e.g. the Top 50 web site I saw didn't provide archives of previous rankings). When there'll be such a need, then we'll define a new link relation (I already proposed archives/history to link to a table of contents feed allowing navigation to e.g. snapshots of non-incremental feeds; another link relation for the webring use case if it proves to be needed one day). +1
Re: New Link Relations -- Last Call
Am 23.10.2005 um 23:34 schrieb Mark Nottingham: On 23/10/2005, at 1:04 PM, Peter Robinson wrote: I prefer 'subscribe' because it better describes the meaning and intention behind the link, but I can live with 'current' if that is the consensus. Well, Tim seemed to have a pretty strong -1 on 'subscribe', whereas you say you can live with 'current'. So, at this point it looks like 'current', unless other people come forward. I flirted with recent briefly; anybody strongly like that one? Maybe it is clear to everyone but me...however i do not see the damage done by using rel=self instead of inventing a new relation. Could someone bother to explain that? I know the definition in the format spec says it points to an equivalent resource, but it also says that This is the preferred URI for retrieving Atom Feed Documents representing this Atom feed. I probably do miss something important here, but a) equivalent resource says either nothing or lets you enter a mine field while roy t. machine guns you b) representing this Atom feed requires some king of dualistic thinking: the whole Atom feed is composed of several Atom feed documents which are linked with prev and (maybe) next relations. self points to the URI for the overall feed and has the same value in all chained feed documents (or feed chunks as i would call them) Can I convince anyone to enter the land where an Atom feed is composed of one or more Atom feed documents? Cheers, Stefan
Re: New Link Relations -- Last Call
I agree self would do well. But it is true that it's current definition is a little vague. I don't suppose one can refine it in a way consistent with its current definition? In any case this all looks good to me. As soon as we agree on the names, I will implement these links in BlogEd, so that the web server can keep a complete history of published changes. What would I need to add to my feed to make it clear that I my feed is incremental (I think that's what my feed would be)? Henry On 24 Oct 2005, at 10:37, Stefan Eissing wrote: Am 23.10.2005 um 23:34 schrieb Mark Nottingham: On 23/10/2005, at 1:04 PM, Peter Robinson wrote: I prefer 'subscribe' because it better describes the meaning and intention behind the link, but I can live with 'current' if that is the consensus. Well, Tim seemed to have a pretty strong -1 on 'subscribe', whereas you say you can live with 'current'. So, at this point it looks like 'current', unless other people come forward. I flirted with recent briefly; anybody strongly like that one? Maybe it is clear to everyone but me...however i do not see the damage done by using rel=self instead of inventing a new relation. Could someone bother to explain that? I know the definition in the format spec says it points to an equivalent resource, but it also says that This is the preferred URI for retrieving Atom Feed Documents representing this Atom feed. I probably do miss something important here, but a) equivalent resource says either nothing or lets you enter a mine field while roy t. machine guns you b) representing this Atom feed requires some king of dualistic thinking: the whole Atom feed is composed of several Atom feed documents which are linked with prev and (maybe) next relations. self points to the URI for the overall feed and has the same value in all chained feed documents (or feed chunks as i would call them) Can I convince anyone to enter the land where an Atom feed is composed of one or more Atom feed documents? Cheers, Stefan
Re: New Link Relations -- Last Call
* Henry Story [EMAIL PROTECTED] [2005-10-24 12:00]: What would I need to add to my feed to make it clear that I my feed is incremental (I think that's what my feed would be)? By my understanding, incremental is the default semantic for a feed, so to make it clear that that’s what yours is you would add nothing. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Sponsored Links and other link extensions
Eric Scheid wrote: The challenge with using alternate to point to files of different types is that why would someone do (a) when they can already do (b) without the help of a new extension (a) link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; x:alternate type=application/ogg href=http://example2.com/file.ogg; / /link (b) link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; / link rel=enclosure type=application/ogg href=http://example2.com/file.ogg; / With (a), we know the .mp3 and the .ogg are simply different formats of the same thing. With (b) we don't know either way. I like (a) in concept because, as you say, it enables you to tell when two links are the same so if you're auto-downloading you don't need them both. However, I do think James is right in thinking that many people will just use (b) because it's already there. I don't see the harm in allowing (a) though. If a feed producer uses (a) and an end-user has auto-downloading enabled for that feed, they both benefit from less wasted bandwidth. The only downside would be that aggregators that aren't aware of this extension would fail to see the alternate enclosures. Is that so bad though? It's a trade-off the feed producer has to make - I'm not sure we should be making that decision for them. Something else that just occured to me: is there any likelyhood of this kind of extension breaking existing aggregators? I know that technically there's nothing wrong with it, but I can see aggregators that have home-grown XML parsers possibly getting confused by this. I'm not suggesting the proposal should be abandoned because of a few poor implementations of the Atom spec, but I think it would be worth finding out how much of a problem it is (if anything). Maybe run a test feed through a few of the most popular aggregators and see how many explode. The ones I've tested so far: neither FeedReader nor FeedDemon support enclosures. I'm not sure if that's good news or bad news. Regards James
Re: Profile links
On 10/22/05, James M Snell [EMAIL PROTECTED] wrote: Hmm.. the more I think about this and the more we discuss it, the less I think I like link[rel=profile]. While the URI of the profile reference should be dereferenceable, most of the time the profile value is going to be used as an identifier. entry x:profilehttp://example.com/profiles/weblog/x:profile x:profilehttp://example.com/profiles/podcast/x:profile /entry I would prefer a [EMAIL PROTECTED]'profile' as it provides a nice symmetry with (X)HTML, in particular the microformat use of such link elements to point at XMDP documents[1]. -joe [1] http://www.gmpg.org/xmdp/ -- Joe Gregoriohttp://bitworking.org
Re: New Link Relations -- Ready to go?
Thomas Broyer wrote: I beg to differ. I think the incremental state of a feed is very relevant to paging. If the aggregator does not know that a feed is non-incremental it will not be able to process the feed document in a meaningful manner. Yes, but that's orthogonal to paging. I think I see where the misunderstanding has arisen here. We don't agree on what constitutes paging in a non-incremental feed. You think it means splitting a single feed into multiple pages whereas I interpret the pages as being a history of past feeds. With your interpretation the incremental state is irrelevant - with mine it's very relevant. You're not describing a search feed (or maybe more a search *result* feed, like OpenSearch result feeds) but a filtered aggregate feed (as published by PubSub). Actually I was thinking of something somewhere in the middle. Like when you do a search in Google Groups it offers to notify you of new results via email. I would have thought that would be a standard feature for any search service that provided results in a syndication format. I mean what's the point of having something you can subscribe to if it doesn't change? This is all very interesting, but not possible without more link extensions which don't exist yet. Wait a bit and I'll propose them for registration. When they'll exist, what would become your argument? I think what you're suggesting is overly complicated and not strictly necessary. However, there's nothing stopping you proposing such an extension. My opinion is just my opinion. If you can get support for it, great. The only thing that matters at the moment is whether you're happy with Mark's current proposal for next/prev. If you are then we can move on. If you aren't, you should probably be taking up your case with him. With what we have so far we can do incremental feed archives; we can do at least some form of searching; we can do non-incremental feeds (of the Top 10 variety) with history. I think that's a good start. But we also want paged non-incremental feeds (OpenSearch result feeds), while non-incremental feeds with history have not yet proven to be needed. I still don't see why OpenSearch result feeds can't be implemented as incremental feeds. Either they're being used as a one-off search and you can't subscribe to them (in which case there is no difference between incremental and non-incremental), or they're being updated with new results over time (like a filtered aggregate feed) in which case I would think they have to be incremental. As for non-incremental feeds with history, I can't point to a specific site that is using something like that, but I know it has been requested before. It's possible it was just a hypothetical it might be useful if... type of request though. I'm proposing previous/next linking from chunk to chunk inside the same snapshot and adding a new link relation (or set of link relations) for linking from snapshot to snapshot. Do you now see what I'm talking about? I understand what you're talking about, but I just don't see the need. I would have expected a non-incremental feed to be a single Atom document. My reason for wanting paging is so that a user doesn't need to fetch data that he already has - this can never be a problem with a non-incremental feed because it doesn't grow. That leaves the next/prev links free for use as a history of past snapshots. Once again, this is just my opinion. I don't expect you to agree with me. I'm sure the market will make its own choices about how best to use these extensions. If it turns out my opinion is in the minority, you may well find me changing my mind in the future - it wouldn't be the first time. Regards James
Re: New Link Relations -- Ready to go?
On Oct 24, 2005, at 8:13 AM, James Holderness wrote: With what we have so far we can do incremental feed archives; we can do at least some form of searching; we can do non-incremental feeds (of the Top 10 variety) with history. I think that's a good start. But we also want paged non-incremental feeds (OpenSearch result feeds), while non-incremental feeds with history have not yet proven to be needed. I still don't see why OpenSearch result feeds can't be implemented as incremental feeds. Perhaps they can, but that wouldn't always be desirable. Consider this scenario: Somebody writes a program that searches Google, scrapes the HTML results, and publishes them as an Atom feed. My purpose in subscribing to the feed is not to be alerted when a new webpage is added to page 20 of Google's results, it's to be alerted whenever a new webpage makes it onto page 1. So I don't want new pages added to the live end of the feed--I just want whatever is currently in the top 10 results, and my feed reader will tell me when one of them is one it hasn't seen before. Either they're being used as a one-off search and you can't subscribe to them (in which case there is no difference between incremental and non-incremental), or they're being updated with new results over time (like a filtered aggregate feed) in which case I would think they have to be incremental. Given the above scenario, why wouldn't you be able to subscribe to them? I'm proposing previous/next linking from chunk to chunk inside the same snapshot and adding a new link relation (or set of link relations) for linking from snapshot to snapshot. Do you now see what I'm talking about? I understand what you're talking about, but I just don't see the need. I would have expected a non-incremental feed to be a single Atom document. In the case of something like a top 10 feed, I'd imagine it would be. But a search results feed like what's described above may not be. My reason for wanting paging is so that a user doesn't need to fetch data that he already has - this can never be a problem with a non-incremental feed because it doesn't grow. I'm not sure I understand--it's not as if a non-incremental feed were simply a static document. They're resources whose contents are replaced wholesale (with the things that were in the old set possibly still being in the new set) rather than having their old contents augmented when new things are added.
Re: Profile links
On Oct 23, 2005, at 6:45 PM, James Holderness wrote: James M Snell wrote: 1. Can a profile element appear in an atom:feed/atom:source? If so, what does it mean? I think it should with the caveat that the profile attribute should only impact the feed and should not reflect on the individual entries within that feed. I can't see any particular use for atom:source myself, but I would definately want profile support at the feed level. As an aggregator I want to be able to display a custom view for a particular feed based on what it contains (e.g. slideshow view if it's a flickr feed - all images). It would be difficult to do something like that with only entry level profiles. I don't think it's possible to allow something at the feed level, but disallow it in atom:source (the Atom format spec could have done that, but I don't think an extension can add such restrictions). What does it mean in atom:source? That the feed that the entry came from conformed to the profile. What will consuming applications do with profile elements in atom:source? That's entirely up to the application developer. Maybe nothing--maybe they'll ignore profiles that don't apply to the entire feed. Or maybe they'll come up with something useful.
Re: Sponsored Links and other link extensions
On Oct 24, 2005, at 5:18 AM, James Holderness wrote: Eric Scheid wrote: The challenge with using alternate to point to files of different types is that why would someone do (a) when they can already do (b) without the help of a new extension (a) link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 x:alternate type=application/ogg href=http://example2.com/ file.ogg / /link (b) link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; / link rel=enclosure type=application/ogg href=http://example2.com/file.ogg; / With (a), we know the .mp3 and the .ogg are simply different formats of the same thing. With (b) we don't know either way. I like (a) in concept because, as you say, it enables you to tell when two links are the same so if you're auto-downloading you don't need them both. However, I do think James is right in thinking that many people will just use (b) because it's already there. I don't see the harm in allowing (a) though. If a feed producer uses (a) and an end-user has auto-downloading enabled for that feed, they both benefit from less wasted bandwidth. The only downside would be that aggregators that aren't aware of this extension would fail to see the alternate enclosures. Is that so bad though? It's a trade-off the feed producer has to make - I'm not sure we should be making that decision for them. Here's the middle path: (c) link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 x:link-set=a / link rel=enclosure type=application/ogg href=http:// example2.com/file.ogg x:link-set=a / This won't save you from bandwidth waste by aggregators that don't support the extension, but it also won't prevent users of those aggregators from getting the data in a format they can use. That said, this is not my preferred method. I'd rather protect bandwidth and the user's hard drive space--all the more important because enclosures are often quite large. Here's a final option--is it legal? Is it better or worse than (a) in any ways? (d) link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 link rel=alternate type=application/ogg href=http:// example2.com/file.ogg / /link Better: Doesn't require processing of a new namespace or element-- just a new way of using the data that one gets out of an existing element. I prefer d, a, c and then b.
Re: Profile links
Joe Gregorio wrote: On 10/22/05, James M Snell [EMAIL PROTECTED] wrote: Hmm.. the more I think about this and the more we discuss it, the less I think I like link[rel=profile]. While the URI of the profile reference should be dereferenceable, most of the time the profile value is going to be used as an identifier. entry x:profilehttp://example.com/profiles/weblog/x:profile x:profilehttp://example.com/profiles/podcast/x:profile /entry I would prefer a [EMAIL PROTECTED]'profile' as it provides a nice symmetry with (X)HTML, in particular the microformat use of such link elements to point at XMDP documents[1]. -joe [1] http://www.gmpg.org/xmdp/ I thought that head[profile='list-o-uris] was the right approach for XHTML profiles? - James
Re: Profile links
On 10/24/05, James M Snell [EMAIL PROTECTED] wrote: Joe Gregorio wrote: I would prefer a [EMAIL PROTECTED]'profile' as it provides a nice symmetry with (X)HTML, in particular the microformat use of such link elements to point at XMDP documents[1]. -joe [1] http://www.gmpg.org/xmdp/ I thought that head[profile='list-o-uris] was the right approach for XHTML profiles? Ok, that will teach me to whip out a quick response :) You are correct that it is head[profile='list-o-uris] and not a link element as my poorly worded message would imply. What I was trying to stress was the pointing at XMDP documents, not so much the link element. -joe -- Joe Gregoriohttp://bitworking.org
Re: New Link Relations -- Ready to go?
Perhaps they can, but that wouldn't always be desirable. Consider this scenario: Somebody writes a program that searches Google, scrapes the HTML results, and publishes them as an Atom feed. My purpose in subscribing to the feed is not to be alerted when a new webpage is added to page 20 of Google's results, it's to be alerted whenever a new webpage makes it onto page 1. So I don't want new pages added to the live end of the feed--I just want whatever is currently in the top 10 results, and my feed reader will tell me when one of them is one it hasn't seen before. Ok. That's a valid point, but I still wouldn't be particularly interested in trying to accomodate that scenario. First you have someone producing a feed that is almost impossible to use as designed. Second you have someone using said feed contrary to how it was designed (although understandably so). A more sensible approach would be a single feed document containing the top N results (where N is manageable in size). You could subscribe to that as a non-incremental feed and you would know at any point in time which were the top 10 results. There is no real need for paging other than as a form of snapshot history (i.e. what were the top 10 results last week). Given the above scenario, why wouldn't you be able to subscribe to them? I can understand why you might want to subscribe to such a feed (or at least the first page of one). I can't understand why someone would want to create it though. And I wouldn't be particularly concerned if it wasn't possible for them to do such a thing. My reason for wanting paging is so that a user doesn't need to fetch data that he already has - this can never be a problem with a non-incremental feed because it doesn't grow. I'm not sure I understand--it's not as if a non-incremental feed were simply a static document. They're resources whose contents are replaced wholesale (with the things that were in the old set possibly still being in the new set) rather than having their old contents augmented when new things are added. Exactly. The *entire document* is replaced. If you want to download an update you have to redownload the whole thing. There's no point in having a paging system since you can't stop after page 1. If you have to retrieve every single page every single time then they might as well all be in one page. Once again, I have to ask the same question I asked Thomas: do you have a problem with Mark's next/prev proposal as it stands, or are you just arguing with me because you think I'm wrong? If the latter, feel free to just ignore me. We can agree to disagree. Unless we're discussing a particular proposal I don't see the point. Regards James
Re: Sponsored Links and other link extensions
Antone Roundy wrote: Here's a final option--is it legal? Is it better or worse than (a) in any ways? (d) link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 link rel=alternate type=application/ogg href=http:// example2.com/file.ogg / /link I'm not completely sure yet, but I'm quite partial to this approach. My only suggestion would be using rel=enclosure on the inner links rather than alternate. There will be some Atom processors [1] that won't be able to tell the difference between an inner link and an outer link. If they're both marked as enclosures it won't really matter (you lose the benefits, but no worse than normal). However, interpreting the inner link as an alternate to the atom entry could be bad. If you combine this with the requirement that an inner link with the same type and hreflang as the outer link must be bit-for-bit identical, we could cover the other use-case of multiple download sources. So far, no new elements or attributes necessary. Not sure about the legality. Regards James [1] http://philringnalda.com/blog/2005/06/ms_embraces_rss.php
Re: New Link Relations -- Ready to go?
On Oct 24, 2005, at 11:16 AM, James Holderness wrote: A more sensible approach would be a single feed document containing the top N results (where N is manageable in size). You could subscribe to that as a non-incremental feed and you would know at any point in time which were the top 10 results. There is no real need for paging other than as a form of snapshot history (i.e. what were the top 10 results last week). That is certainly a good approach--allowing the number of results to be determined dynamically by something in the URL, for example. However, it could be useful to limit the chunk size and allow paging for people who want more. For example, you might allow a maximum of 50 results per chunk, and then support ETags. That way, if somebody wants to monitor the top 250, they can send 5 requests, and if most of the time there are no changes, they'll get a lot of 304s, but if occasionally something changes in the last chunk of 50 for example, they're only downloading 50 results each time something changes. There are of course other approaches, like support for just sending the diffs. But that would probably more difficult for most people to implement, and may be less likely to be supported by a wide variety of clients. Another reason for wanting to limit the number of results per query (and support paging for those who want more) is to avoid bandwidth waste if someone accidentally ads an extra digit to the desired number of results; or tries to waste your system resources by requesting huge result sets (but dropping the connection before using up their own bandwidth actually receiving the whole result set); or has a client that doesn't support paging or diffs or ETags or anything, and wants a huge result set (and you don't want to accommodate them since it would use so much bandwidth), etc. Once again, I have to ask the same question I asked Thomas: do you have a problem with Mark's next/prev proposal as it stands, or are you just arguing with me because you think I'm wrong? If the latter, feel free to just ignore me. We can agree to disagree. Unless we're discussing a particular proposal I don't see the point. I have a problem with not having link relations specific to paging through a feed's current state. I'm fine with having general chain navigation link relations, but hope that we'll get something specific to paging and that people will use it instead of the general link relations. I've spoken my peace on that and have given up swimming against the tide, but am still willing to discuss specific related issues.
Re: Sponsored Links and other link extensions
The concept of reusing atom namespaced elements as extensions inside other atom namespaced elements has come up before and has generally been frowned upon. James Holderness wrote: Antone Roundy wrote: Here's a final option--is it legal? Is it better or worse than (a) in any ways? (d) link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 link rel=alternate type=application/ogg href=http:// example2.com/file.ogg / /link I'm not completely sure yet, but I'm quite partial to this approach. My only suggestion would be using rel=enclosure on the inner links rather than alternate. There will be some Atom processors [1] that won't be able to tell the difference between an inner link and an outer link. If they're both marked as enclosures it won't really matter (you lose the benefits, but no worse than normal). However, interpreting the inner link as an alternate to the atom entry could be bad. If you combine this with the requirement that an inner link with the same type and hreflang as the outer link must be bit-for-bit identical, we could cover the other use-case of multiple download sources. So far, no new elements or attributes necessary. Not sure about the legality. Regards James [1] http://philringnalda.com/blog/2005/06/ms_embraces_rss.php
Re: Profile links
At 12:45 PM 2005-10-24, Joe Gregorio wrote: On 10/24/05, James M Snell [EMAIL PROTECTED] wrote: Joe Gregorio wrote: I would prefer a [EMAIL PROTECTED]'profile' as it provides a nice symmetry with (X)HTML, in particular the microformat use of such link elements to point at XMDP documents[1]. -joe [1] http://www.gmpg.org/xmdp/ I thought that head[profile='list-o-uris] was the right approach for XHTML profiles? Ok, that will teach me to whip out a quick response :) You are correct that it is head[profile='list-o-uris] and not a link element as my poorly worded message would imply. What I was trying to stress was the pointing at XMDP documents, not so much the link element. Or GRDDL [2]. [2] http://www.w3.org/2003/g/data-view If you use del.icio.us, let me suggest the use of the tag atomprofile to bookmark links to profile descriptions. You then have a makeshift registry at [3]. [3] http://del.icio.us/tag/atomprofile Paul
Re: Sponsored Links and other link extensions
* James M Snell [EMAIL PROTECTED] [2005-10-22 17:20]: (a) link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; x:alternate type=application/ogg href=http://example2.com/file.ogg; / /link (b) link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; / link rel=enclosure type=application/ogg href=http://example2.com/file.ogg; / * Antone Roundy [EMAIL PROTECTED] [2005-10-24 18:10]: (c) link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 x:link-set=a / link rel=enclosure type=application/ogg href=http:// example2.com/file.ogg x:link-set=a / (d) link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 link rel=alternate type=application/ogg href=http:// example2.com/file.ogg / /link I have a completely different proposition. (e) link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; encl:mirrors=http://www2.example.com/file.mp3 http://www3.example.com/file.mp3; xml:id=x-file / link rel=alternative-enclosure type=application/ogg href=http://example2.com/file.ogg; encl:alternative-to=x-file / Since bit-for-bit identical files all have the exact same attributes, there is absolutely no reason to have an entire tag dedicated to each. In addition, making mirror URLs second-class citizens in this ways provides an intuitive hint at the bit-for-bit identity semantics. Specifying alternative formats with a distinct link relationship prevents bandwidth and diskspace drain from oblivious clients. And once you’ve gotten so far as to think of one enclosure as the preferentially advertised format, it’s no stretch to think of grouping alternative-format enclosures as linking the alternative format enclosures to the preferrentially advertised one. And that’s a purpose for which IDs work just fine. Thinking in terms of code I believe this model is a bit easier to process than any of the alternatives. A list of mirror URLs is obviously trivial to retrieve. And just as you can do with the nested-element models, you can read the list of enclosure groups right off the markup simply by looking for any `enclosure` links. But less nesting is easier to process. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Sponsored Links and other link extensions
On Oct 24, 2005, at 1:48 PM, A. Pagaltzis wrote: I have a completely different proposition. (e) link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; encl:mirrors=http://www2.example.com/file.mp3 http:// www3.example.com/file.mp3 xml:id=x-file / link rel=alternative-enclosure type=application/ogg href=http://example2.com/file.ogg; encl:alternative-to=x-file / Since bit-for-bit identical files all have the exact same attributes, there is absolutely no reason to have an entire tag dedicated to each. In addition, making mirror URLs second-class citizens in this ways provides an intuitive hint at the bit-for-bit identity semantics. Interesting. Filling an attribute with a list of URIs doesn't really appeal to me though. How about this: link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 xml:id=x-file altlink:mirror href=http://www2.example.com/file.mp3; / altlink:mirror href=http://www3.example.com/file.mp3; / /link Specifying alternative formats with a distinct link relationship prevents bandwidth and diskspace drain from oblivious clients. Sounds good, but you may have noticed above that I used a prefix not specific to enclosures--there's no reason to tie this all to one particular type of link (nor to make it look as if it were tied to one specific link type). So the other link might, for example, be: link rel=alternative-link type=application/ogg href=http:// example2.com/file.ogg altlink:primary=x-file / Although alternative-link doesn't tell you what kind of link this is, since you're going to have to tie it back to the primary link to decide what to do with it anyway, it really shouldn't matter. Note that I changed alternative-to to primary just because it's shorter and one word.
Re: Sponsored Links and other link extensions
* Antone Roundy [EMAIL PROTECTED] [2005-10-24 22:35]: Interesting. Filling an attribute with a list of URIs doesn't really appeal to me though. How about this: link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 xml:id=x-file altlink:mirror href=http://www2.example.com/file.mp3; / altlink:mirror href=http://www3.example.com/file.mp3; / /link It’s a lot more verbose and you have to fiddle with nesting. What do you get in return? “It looks more XMLish”? Sounds good, but you may have noticed above that I used a prefix not specific to enclosures--there's no reason to tie this all to one particular type of link (nor to make it look as if it were tied to one specific link type). So the other link might, for example, be: I don’t know if striving for generality in this fashion without a practical need is worthwhile. It smells of architecture astronautics for a reason I can’t particularly pinpoint. So maybe my instinct is wrong. Note that I changed alternative-to to primary just because it's shorter and one word. Works for me. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New Link Relations -- Last Call
Hi Mark, Mark Nottingham [EMAIL PROTECTED] wrote: On 23/10/2005, at 1:04 PM, Peter Robinson wrote: I prefer 'subscribe' because it better describes the meaning and intention behind the link, but I can live with 'current' if that is the consensus. Well, Tim seemed to have a pretty strong -1 on 'subscribe', whereas you say you can live with 'current'. I can. The argument as I understand it is that relations should be nouns rather than verbs (describing what the link points to rather than what you should do with it). I can't argue that point, but I do feel that 'current' less encapsulates the intent than 'subscribe'. Someone else suggested 'subscription'. This should be my last word on the subject: Apparently it came as a surpise to some that rel='self' as defined is not the same as 'the url you should subscribe to' in the general case. I don't want to make the same mistake yet again. First example: consider a statically archived non-incremental OpenSearch-style feed split into pages: http://www.example.com/feed/2001/page3 A reasonable interpretation (the only possible interpretation?) of rel='current' would be this: http://www.example.com/feed/current/page3 which is certainly not the url you should subscribe to. Second example: a dynamic feed where cgi variables are used to set options, perhaps for use in building an html page of links rather than normal subscription, but you can come up with other uses: http://www.example.com/feed?year=2001no_atomcontent=yes Rel='current' would point to http://www.example.com/feed?no_atomcontent=yes but it would be much better for PubSub or a desktop aggregator to go to http://www.example.com/feed if it ever got hold of such a feed. The second example is (essentially) something I already do. I don't expect urls like that to 'escape' into the wild, but I can't prevent it and I'd like to be able to give an aggregator something meaningful to do when it does happen. If we want to define a link relation meaning 'the url you should subscribe to' then that is what we should define. So, at this point it looks like 'current', unless other people come forward. I flirted with recent briefly; anybody strongly like that one? I don't think that is any better. I am also worried that this is being pushed through too quickly. I appreciate that, but it's a bit of a chicken-and-egg problem; we won't get all of the implementation experience until it's defined and widely deployed. That is true, but have you communicated with the OpenSearch people about this? I do strongly believe that *here* is the place for work like this, rather than behind closed doors at Amazon. But if I was them I'd feel pretty miffed that this WG appears to have basically stolen their idea in a desperate 'land grab', and turned it on its head so that it is (arguably) the complete opposite of their intended definition. [snips] OpenSearch uses 'next' to go from page=1 to page=2. The natural paging setup for an inremental feed that is also an OpenSearch results feed is to have rel=current (aka rel=subscribe) point to the first page of results (i.e. page=1). Is it the intention that history reconstruction uses 'next' links to go back into the past? [...] Right now, the plan forward seems to be that 'next' et al will be purposefully generic; i.e., they won't mean much until used in conjunction with another extension (in my case, fh:incremental). My plan for feed history is to recommend people walk both 'previous' and 'next' from the subscription feed, so that it doesn't matter which way the feed goes. I see! That little nugget of an idea makes me feel a lot more comfortable about prev/next. So something that understands rel=previous, next et al will be able to reconstruct a complete logical feed, and the history extension will tell it 'which way is up' and whether it's a traditional 'incremental' feed. That makes a lot of sense. Regards, Peter
Re: Sponsored Links and other link extensions
Antone Roundy wrote: Interesting. Filling an attribute with a list of URIs doesn't really appeal to me though. Me neither. Something feels wrong about that. If you want a concrete reason, it requires extra parsing whereas everything else would be automatically parsed by the XML library. link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 xml:id=x-file altlink:mirror href=http://www2.example.com/file.mp3; / altlink:mirror href=http://www3.example.com/file.mp3; / /link Isn't this essentially the same as James' original proposal? link rel=enclosure href... ... x:alternate href=... title=... / x:alternate href=... title=... / /link Regards James
Re: Sponsored Links and other link extensions
* James Holderness [EMAIL PROTECTED] [2005-10-25 00:00]: If you want a concrete reason, it requires extra parsing whereas everything else would be automatically parsed by the XML library. You have to split on whitespace; that’s much easier in my book than finding a nodeset of nested elements and iterating over it. Isn't this essentially the same as James' original proposal? Yes. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Sponsored Links and other link extensions
On Oct 24, 2005, at 2:59 PM, A. Pagaltzis wrote: * Antone Roundy [EMAIL PROTECTED] [2005-10-24 22:35]: Interesting. Filling an attribute with a list of URIs doesn't really appeal to me though. How about this: link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 xml:id=x-file altlink:mirror href=http://www2.example.com/file.mp3; / altlink:mirror href=http://www3.example.com/file.mp3; / /link It’s a lot more verbose and you have to fiddle with nesting. What do you get in return? “It looks more XMLish”? 1) Easier parsing, as James said, since your XML parsing library is going to give you the data with the URI's already split apart. 2) You can break lines between elements, but you can't inside an attribute, so it's better for display for humans. I think XMLishness leans this direction for good reason. Sounds good, but you may have noticed above that I used a prefix not specific to enclosures--there's no reason to tie this all to one particular type of link (nor to make it look as if it were tied to one specific link type). So the other link might, for example, be: I don’t know if striving for generality in this fashion without a practical need is worthwhile. It smells of architecture astronautics for a reason I can’t particularly pinpoint. So maybe my instinct is wrong. The way I see it, striving for specificity without a practical need isn't worthwhile. Unless generalizing risks leading to some sort of problem, why do it? I see no potential problems. What if someday somebody does come up with a non-enclosure use for this (which hardly seems far-fetched to me--enclosures aren't the only things that get mirrored or exist in multiple formats)? They'll have to define a new mechanism for it which is either going to be identical except for element names, or they're going to invent another way to do the same thing. Either way, the pain of supporting both is completely unnecessary unless there's potential for generality causing problems.
RE: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]
As I said before, if the WG can reach consensus, I'm happy with any old term. I hadn't seen Mark's proposal till a few days ago, and a mention in an xml.com does not, in my opinion, a spec-in-stone make. My only pushback on next is that to me, it seems counterintuititive -- same as your pushback on prev. *shrug* The SixApart people have publicly pointed to FH, so I don't think they're particularly fussed about any particular approach other (not to put words in their mouth). I wasn't able to find a TP feed that uses rel=next; do you have a link to one? I have been holding back until I found the right message to reply to. I think I found it. As it turns out Six Apart's Japanese office recently released something we call TypePad Mobile and TypeCast. Both products are geared at the same problem: making blogs accessible to mobile devices. TypeCast is about making an Atom powered blogging application, whereas TypePad Mobile's purpose is to make all published blogs completely accessible via Atom. It may be the most comprehensive Atom implementation of its kind, but that is a bold statement to make. (FYI: Tatsuhiko Miyagawa was the lead engineer behind the project.) In TypePad Mobile, Tatsuhiko implemented a rel=next and rel=prev in order to facilitate the following problem: * in browsing a blog on a phone, one can only realistically afford to read 1-3 entries at a time. The implementation addresses the need to: ** veiwing the first n posts on the front door, and then paging through entries that go back in time ** viewing category archives (1 or 2 entries at a time) ** viewing daily/weekly/monthly/yearly archives (1 or 2 entries at a time) ** eventually to view tag archives, most popular archives, etc * next and prev were also used both in the context of the application: ** show me a list of entries I can edit ** show me a list of the most recent comments ** etc. So there is a real live use case. As for me, I am rarely one to get myself involved in a namenclature debate. More often than not, IMHO, they just go in cicles. Plus once you get involved, it is hard to extricate yourself from the debate. So for *me*, I don't really care what the link relations are labeled provided that their usage is well defined, and that there is concenseus around their intended usage. I have come around to favor: next|prev|first|last|(current or subscribe) because it is similar to (if not identical with) what we have alread implemented in our APP implementatin and in Japan. But also it is sufficiently specific and sufficiently open ended to give me (the implementer) a very reasonable set of ways to apply the principal. Byrne Reese
Re: Sponsored Links and other link extensions
On 25/10/05 3:43 AM, James Holderness [EMAIL PROTECTED] wrote: My only suggestion would be using rel=enclosure on the inner links rather than alternate. There will be some Atom processors [1] that won't be able to tell the difference between an inner link and an outer link. and we're back to the duplicate bandwidth problem again :-( If you combine this with the requirement that an inner link with the same type and hreflang as the outer link must be bit-for-bit identical, we could cover the other use-case of multiple download sources. So far, no new elements or attributes necessary. what about the use case of alternate formats (etc) for the same resource? Not sure about the legality. not legal, since atom:link cannot appear there ie. while atom:link (the container) can contain foreign markup, atom:link (the embedded) is not foreign markup. e.
Re: Sponsored Links and other link extensions
On 25/10/05 8:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: You have to split on whitespace; that¹s much easier in my book than finding a nodeset of nested elements and iterating over it. I recall people screaming about micro-parsers before for a different attribute. Has anything changed? e.
Re: Sponsored Links and other link extensions
On 25/10/05 5:48 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; encl:mirrors=http://www2.example.com/file.mp3 http://www3.example.com/file.mp3; xml:id=x-file / link rel=alternative-enclosure type=application/ogg href=http://example2.com/file.ogg; encl:alternative-to=x-file / -1 ... this is starting to get ugly. e.
Re: Sponsored Links and other link extensions
Eric Scheid wrote: On 25/10/05 5:48 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; encl:mirrors=http://www2.example.com/file.mp3 http://www3.example.com/file.mp3; xml:id=x-file / link rel=alternative-enclosure type=application/ogg href=http://example2.com/file.ogg; encl:alternative-to=x-file / -1 ... this is starting to get ugly. e. +1 to Eric's -1. Let's keep it simple. link rel=... type=... href=... x:alternate type=... href=... title=... / /link - James
Re: Sponsored Links and other link extensions
* Antone Roundy [EMAIL PROTECTED] [2005-10-25 00:35]: 2) You can break lines between elements, but you can't inside an attribute, so it's better for display for humans. That’s not what the XML spec says. What if someday somebody does come up with a non-enclosure use for this (which hardly seems far-fetched to me--enclosures aren't the only things that get mirrored or exist in multiple formats)? They'll have to define a new mechanism for it which is either going to be identical except for element names, or they're going to invent another way to do the same thing. Either way, the pain of supporting both is completely unnecessary unless there's potential for generality causing problems. If it isn’t obvious from the start what it means that there’s an alternative-link for a via link or a previous or next link, then clients will have to support each of these use case separately. So on the implementor’s end, there’s no discernible difference between the pain of supporting either approach. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Sponsored Links and other link extensions
On Oct 24, 2005, at 9:59 PM, A. Pagaltzis wrote: * Antone Roundy [EMAIL PROTECTED] [2005-10-25 00:35]: 2) You can break lines between elements, but you can't inside an attribute, so it's better for display for humans. That’s not what the XML spec says. Doh! Who knows where I got that idea. I still prefer to have each piece of data in it's own place. What if someday somebody does come up with a non-enclosure use for this (which hardly seems far-fetched to me--enclosures aren't the only things that get mirrored or exist in multiple formats)? They'll have to define a new mechanism for it which is either going to be identical except for element names, or they're going to invent another way to do the same thing. Either way, the pain of supporting both is completely unnecessary unless there's potential for generality causing problems. If it isn’t obvious from the start what it means that there’s an alternative-link for a via link or a previous or next link, then clients will have to support each of these use case separately. So on the implementor’s end, there’s no discernible difference between the pain of supporting either approach. I'm not sure I understand what you're saying. Are you saying that one might do this if they want and alternate of a next link? link rel=next xml:id=foo ... / link rel=alternate-enclosure x:alternate-of=foo ... / If that's what you mean, then sure, the code for that would be the same as for: link rel=next xml:id=foo ... / link rel=alternate-link x:alternate-of=foo ... / ...but it would sure look odd. I see no advantage to naming these things in terms of enclosures.
Re: Sponsored Links and other link extensions
On 25/10/05 1:12 PM, James M Snell [EMAIL PROTECTED] wrote: +1 to Eric's -1. Let's keep it simple. link rel=... type=... href=... x:alternate type=... href=... title=... / /link I'm also liking it from another angle... With some of the other approaches dumb clients do harm to others, and while smart clients do no harm they don't get anything which dumb clients already get. With this approach dumb clients do no harm, and smart clients gain benefits not available to dumb clients. It sets up the right ecological pressures for the market to evolve in a way which is beneficial. So while let the market/implementations decide is often persuasive, we really should at the same time be asking what environment/ecology are we establishing for this evolution. e.
Re: Sponsored Links and other link extensions
On 25/10/05 8:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: If you want a concrete reason, it requires extra parsing whereas everything else would be automatically parsed by the XML library. You have to split on whitespace; that¹s much easier in my book than finding a nodeset of nested elements and iterating over it. There's another problem with this: @encl:mirrors=http://www2.example.com/file.mp3 http://www3.example.com/file.mp3; ... how do you attach @title to each URI, for example @title=Blah blah -- European Mirror. e.
