Re: Why is alternate link a MUST?
On Sun, Apr 03, 2005 at 04:13:55PM -0700, Tim Bray wrote: I think link rel=self is a SHOULD, to address auto-subscriptions, one of the current #1 RSS pain points, perceived by users as a failure to interoperate. -Tim +1 James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: Why is alternate link a MUST?
Eric Scheid wrote: On 4/4/05 1:32 PM, Paul Hoffman [EMAIL PROTECTED] wrote: Not to pick on Eric; others have said things along the lines of: no offence taken. This isn't a negotiating game. We have to have technical reasons for our assigning requirements levels. I can't think of any MUST reasons for [EMAIL PROTECTED]'self'] or [EMAIL PROTECTED]'alternate']. Then let me try and help you with that. I can think of long nights tracking down data because I didn't have way to hand systems an identifier. In the Atom 06 format there are 3 things potentially acting as identifiers for the source of an Atom feed. The one that going by the commonsense name least likely to be considered a meaningful identifier is mandatory. Sorry to offend anyone in this WG, but that's absurd. Never mind that we're creating an arbitrary distinction between feed ids and entry ids. I have very strong opinions on this: too many identifiers cause problems when it comes to system and data management -worst scenario in terms of cost are too many unreliable identifiers. For a pure client/server newsreader case I can see how this might not bite so much. For anyone passing Atom along a processing chain or heaven forbid, something like a SEDA system, not having assured easy to find identifiers is a cost. Being able to rely on the presence of an (ideally, single) identifier is a management win and an interop win. It is one of the reasons Web based systems are easy to run. Not having such a thing for Atom feeds ensures people will have to invent it especially for non-HTTP scenarios. The upfront cost of mandating either self or id is so small versus the benefit of being able to shout out something's name when something goes awry I can't believe we're even having this discussion. Anyway I've made my position clear at this point. Please make id or self mandatory. [Please don't argue on the basis that URL links aren't identifiers or names and shouldn't be treated as such; it's de jure Web architecture that they are.] cheers Bill
Re: Why is alternate link a MUST?
On 4/4/05 10:04 PM, Bill de hÓra [EMAIL PROTECTED] wrote: -1: the reasons against @self MUST are similar to the reasons against @alternate MUST. I don't understand. How are these alike? one reason against @rel='self' is that the feed may not be retrievable at all (being delivered some other way) one reason against @rel='alternate' is that there may not be any web retrievable resource. e.
Re: Why is alternate link a MUST?
On 4 Apr 2005, at 4:32 am, Paul Hoffman wrote: This isn't a negotiating game. We have to have technical reasons for our assigning requirements levels. Right: 1. Feed level ids. By all reasonable web conventions, requesting a feed from a particular URI can be expected to only ever return one particular feed resource. Whereas, the request will also return an essentially random combination of entry resources. Entry ids are a MUST because of the latter, which doesn't apply to feeds. A separate feature of entry or feed ids is comparison and duplicate-removal across URIs. Since many users/implementers may choose not to do this due to concerns over security and potentially unexpected-behaviour, it can be described as truly optional functionality, which makes it MAY. 2. Link rel=self Subscribing to feeds is a fundamental feature, and since the whole purpose of self is to make it simple and reliable, this element is not optional, and it's reasonable to say it must be present. But I can think of a few edge cases where the service generating the XML may not know its eventual URI, and of course there may be circumstances where there isn't one. This is the only reason I can think of to omit it. Since SHOULD allows implementers to wimp out for any reason they choose, I think the appropriate wording is MUST where one exists and is known. 3. Link rel=alternate Sorry Sam, but this is truly optional as per MAY. Being able to click back to the home page is nice, but how is it an absolute requirement? Graham
Re: Why is alternate link a MUST?
On Sunday, April 3, 2005, at 11:05 AM, Brett Lindsley wrote: Consider a feed returned as a result of a search operation (e.g. a time range). To create an alternate representation of this resource, the link must also specify the same conditions that resulted in the search results. That is, the alternate link needs to somehow embed the search conditions of the search that created the feed so the server can provide an alternate representation. One way to fix this would be to indicate in the protocol spec that the same http headers must be provided to the alternate link as those used to request the feed. If we want the link to point to something that's strictly an alternative representation of the same data, then that makes sense, but it seems to me that the link is pointing to another view into the same data stream, which could be different in more ways than just the data format. For example, following the alternate link may get you a homepage containing entries that were added after you downloaded the feed. In that case, the homepage is certainly not an alternative representation of the same data. Just as the feed or homepage contents may be different depending on when you access them, I think our definition of alternate is loose enough to allow differences based on HTTP headers.
Re: Why is alternate link a MUST?
Antone Roundy wrote: On Monday, April 4, 2005, at 09:43 AM, Robert Sayre wrote: I can't believe people want to put these out on the open Internet without an alternate. It seems to me that the reasons for having alternate links in feeds are almost entirely based on the context in which feeds originally emerged. This isn't a good time for conjecture. I don't think any of the arguments in favor have considered the support burden such feeds will create. OTOH, the absolute worst thing to do right now would be to sit around and argue this for a week. I'm very opposed to getting inventive and making this a MAY. I'm not changing my mind, but the group will probably just define it over my objection. Happens all the time :) Robert Sayre
Re: Why is alternate link a MUST?
On Mon, Apr 04, 2005 at 11:43:38AM -0400, Robert Sayre wrote: We get to design our protocol, and we know the type of software that will be consuming a large part of the traffic. All of that software expects a feed-level link. There are use cases where that's awkward, but I can't believe people want to put these out on the open Internet without an alternate. Depends what you mean by the open Internet: what about password-protected web products? Also, there's an implication here that we don't care about making life hard for denizens of the closed Internet, giving them the choice between abusing Atom and choosing something entirely different. I have yet to hear a reason to make alternate a MUST that is compelling. That existing software (which by definition can't be an IETF Atom client) expects a link to ... some kind of HTML ... doesn't cut it for me, not least because the current atom-syntax spec doesn't require a link to some kind of HTML at all anyway. At the end of the day, I don't think it's possible to make the question is X an alternate version of Y anything other than a subjective call. As such, I don't see the value of making it a MUST - forcing to export their opinions isn't /always/ the purpose of a blog format :-) James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: Why is alternate link a MUST?
On 4 Apr 2005, at 6:02 pm, Robert Sayre wrote: This isn't a good time for conjecture. I don't think any of the arguments in favor have considered the support burden such feeds will create. Basically none. I have no clue why you're raising this objection given all the other functionality we're adding or replacing. Links now being optional is right at the bottom of the list of changes people will have to make. Graham
Re: Why is alternate link a MUST?
Eric Scheid wrote: On 4/4/05 10:25 PM, Bill de hÓra [EMAIL PROTECTED] wrote: Anyway I've made my position clear at this point. Please make id or self mandatory. atom:id then, since atom:[EMAIL PROTECTED]'self'] could change at any point in time, and mutability is not a good attribute of an identifier. Yes, your other post convinced me that atom:[EMAIL PROTECTED]'self'] needs to be optional. cheers Bill
Re: Why is alternate link a MUST?
Of course I'm also for making an alternate link for a feed a MAY rather than a MUST. Regards, Martin. At 07:57 05/04/03, David Nesting wrote: Why isn't this requirement a may instead of a must? I can see having a link with rel=alternate if indeed a alternate version does exist. It does not make sense to put in some something misleading if an alternate does not exist. I recently sought out and joined this list precisely because I wanted to see if this issue had been addressed. I don't think it's reasonable to assume there will always be an alternate version of a feed. If this remains a MUST, I have no choice but to honor this by using a dummy value for an alternate page, since I may not have an alternate. Without any background, it seems to me that the goal here is to require a link *back* to an HTML page that is presumed to have provided an alternate link to this Atom resource. This of course assumes that an HTML or non-Atom version actually exists, and that resource is independent of the Atom resource. (Consider that I may have an HTML version, but it could be derived from the Atom version using XSLT. It's not accurate to consider this an alternate when it's an XML style sheet involved.) I couldn't find any reference to this issue in the mailing list, aside from this (thankfully recent) thread. If it's been addressed before, could someone point me to the thread in the list archives? David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Why is alternate link a MUST?
n Sun, 03 Apr 2005 03:14:33 +0200, Martin Duerst [EMAIL PROTECTED] wrote: Of course I'm also for making an alternate link for a feed a MAY rather than a MUST. +1 I don't see any advantage at all in forcing an alternative representation to exist, and I have yet to see a real argument[1] why such an alternative representation must exist . ___ [1] simplifies validation, and causes problems for some newsreaders are not arguments. -- Arve Bersvendsen - http://virtuelvis.com/
Re: Why is alternate link a MUST?
On Sat, Apr 02, 2005 at 09:22:49PM -0500, Sam Ruby wrote: I've run a feedvalidator for years. Every version of RSS has required this link. I've *never* heard anybody complain about this in the context of any version of RSS. It puzzles the bejeebers out of me why this issue is only brought up in the context of Atom. Speaking personally, I would never have complained about it in the context of RSS because RSS is such a fragmented mess. It comes up in the context of Atom because Atom is trying to be unambiguous and helpful. If MUST is vastly preferable for user agent implementors, then IMHO there should at least be an explanation of what to do when you can't generate an alternate repr (for instance: you may not have enough resource to build an alternate version when you know that alternate version won't be used). Given that the spec currently deliberately backs off on implementation usage (and rightly so), but marks round tripping as a SHOULD (but puts these in different sections with no cross-linking), I feel that a tiny bit (not sarcastic - literally a tiny bit) more guidance for feed producers would be helpful. James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: Why is alternate link a MUST?
* Sam Ruby [EMAIL PROTECTED] [2005-04-03 04:30]: Every version of RSS has required this link. I've *never* heard anybody complain about this in the context of any version of RSS. It puzzles the bejeebers out of me why this issue is only brought up in the context of Atom. My guess is that its because Atom actually tries to define a content model that allows more than just title, link, description. Multiple links and payloads with different semantics each are supported and, if thats what appropriate for a particular case, encouraged. So I think its no wonder that people are seeing Atom as a transport for things they might have either not done with RSS, or inclued fudged links for. Examples that suggest a need for MAY certainly exist: I have one. I run a scraped feed[1] for the Slackware news, where the content from a single web page is scraped divided into multiple separate entries. [1] http://plasmasturm.org/feeds/ These dont appear individually on pages of their own, so it would be most logical to omit the alternate representation link entirely. An alternate representation MUST be given, however, so I use the same link as an for each entry as I use for the feed itself. Cruft. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: Why is alternate link a MUST?
There's been a lot of interesting follow-on as to why this issue has been revisited in Atom. One additional issue I was looking at was forming a feed created by a serach operation. Consider a feed returned as a result of a search operation (e.g. a time range). To create an alternate representation of this resource, the link must also specify the same conditions that resulted in the search results. That is, the alternate link needs to somehow embed the search conditions of the search that created the feed so the server can provide an alternate representation. One way to fix this would be to indicate in the protocol spec that the same http headers must be provided to the alternate link as those used to request the feed. One practical issue is when a home page or something is used as the link when there is no meaningful alternate representation. In this case, a user may see a alternate representation link and click on it. Getting a home page when the link should be an alternate representation of the feed may be considered to be a product failure. The typical thing to do from a product design point of view is to always ignore the alternate link. From a practical point of view, there is no way for the client (or a validator) to determine if the representation returned in the alternate link is actually an alternate representation of the feed. Brett Lindsley, Motorola Labs - Original Message - From: Sam Ruby [EMAIL PROTECTED] Date: Saturday, April 2, 2005 7:22 pm Subject: Re: Why is alternate link a MUST? David Nesting wrote: Why isn't this requirement a may instead of a must? I can see having a link with rel=alternate if indeed a alternate version does exist. It does not make sense to put in some something misleading if an alternatedoes not exist. I recently sought out and joined this list precisely because I wanted to see if this issue had been addressed. I don't think it's reasonable to assume there will always be an alternate version of a feed. If this remains a MUST, I have no choice but to honor this by using a dummy value for an alternate page, since I may not have an alternate. Without any background, it seems to me that the goal here is to require a link *back* to an HTML page that is presumed to have provided an alternate link to this Atom resource. This of course assumes that an HTML or non-Atom version actually exists, and that resource is independent of the Atom resource. (Consider that I may have an HTML version, but it could be derived from the Atom version using XSLT. It's not accurate to consider this an alternate when it's an XML style sheet involved.) I couldn't find any reference to this issue in the mailing list, aside from this (thankfully recent) thread. If it's been addressed before, could someone point me to the thread in the list archives? I can point you to the threads (yes, this has come up mutiple times). Do you, today, produce an RSS feed? If so, what version of RSS? Is it valid? I've run a feedvalidator for years. Every version of RSS has required this link. I've *never* heard anybody complain about this in the context of any version of RSS. It puzzles the bejeebers out of me why this issue is only brought up in the context of Atom. - Sam Ruby
Re: Why is alternate link a MUST?
On Sun, Apr 03, 2005 at 02:45:59PM +0100, James Aylett wrote: Speaking personally, I would never have complained about it in the context of RSS because RSS is such a fragmented mess. It comes up in the context of Atom because Atom is trying to be unambiguous and helpful. This is my view as well. If MUST is vastly preferable for user agent implementors, then IMHO there should at least be an explanation of what to do when you can't generate an alternate repr I was able to locate a previous thread where this issue was discussed, but the thread appeared to peter out before this question was asked/answered. Consider for a minute these two scenarios where one might want to use Atom: 1. Where the Atom resource is the only HTTP resource representing that list of syndicated content. I MAY have an HTML version that is derived from the Atom one using XML style sheets, but I might not. That's my call. 2. Where the Atom resource itself isn't even delivered by HTTP. I may place it in a message delivered via SMTP, or in my own application protocol. Maybe I'm multicasting it to an application in my organization. I may be referencing content that *is* accessible on the web, but my actual syndication list isn't. At a minimum we need to specify what implementers must do when no alternate version exists. Even if that means specifying about:blank as the alternate URL, it should at least be documented. That way, implementations that choose to do so can at least make an educated decision about whether the value of that alternate link is meaningful or just a dummy value. If we can't or don't want to document this in the specification, maybe all we need is some unofficial, non-binding agreement now that implementations can CHOOSE to follow if they want. Maybe someone can whip up a persistent URI that can either stand for (or even deliver a message saying) no alternate exists? I suggested about:blank earlier, but maybe something delivered via HTTP (a la http://www.example.com/) might be appropriate? Maybe x-atom:no-alternate-uri? Implementations that abide solely by the specification and aren't aware or choose not to follow this convention only run the risk of allowing users to follow broken or useless links, which is exactly the situation we have today anyway. I've used RSS in some unofficial capacity in some internal applications. Maybe the regurgitated specifications I had my hands on were just incomplete or inaccurate, but none of these had any alternate link requirement. Many of my own feeds would have had alternate links with dummy values if I had been more aware of this requirement. So just because nobody complained about the artificial constraint in RSS doesn't mean the constraint is legitimate. I've found that every RSS reader or RSS consumer application handled these feeds without a problem. I should point out that the reason I am interested in Atom is to take this to the next level in my organization and actually back an IETF standard syndication format for these purposes. The RSS implementations have just been proofs of concept at this point. Thanks for your time. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Why is alternate link a MUST?
OK, I observe a lot of people speaking up for link-less feeds, presenting some plausible use cases. I observe only Sam speaking up for retaining the compulsory link. I observe at least one person speaking up saying if it's compulsory I'll generate a fake one, which seems significant to me. I'm starting to smell possible consensus; are there more people here who agree with Sam? If so, speak up. Also, if dropping link is going to break something (haven't heard that yet), someone should please point that out. Apologies in advance if you already have spoken on this and I missed it. -Tim
Re: Why is alternate link a MUST?
On Apr 3, 2005 1:51 PM, Tim Bray [EMAIL PROTECTED] wrote: OK, I observe a lot of people speaking up for link-less feeds, presenting some plausible use cases. I observe only Sam speaking up for retaining the compulsory link. I observe at least one person speaking up saying if it's compulsory I'll generate a fake one, which seems significant to me. I'm starting to smell possible consensus; are there more people here who agree with Sam? If so, speak up. I agree with Sam, +1 to the required link. The argument that you can't have an HTML representation are weak, since *I* can generate one for your feed, whether you like it or not, ala: http://www.rss2html.com/ I can also generate an XSLT sheet that transforms Atom into HTML then use the W3C XLST service to transform an Atom feed into HTML: http://www.w3.org/2001/05/xslt Now the generated HTML may not be optimal but I hope this shows that barrier to generating an HTML 'alternate' is not onerous, and that the link should remain a MUST. Thanks, -joe -- Joe Gregoriohttp://bitworking.org
Re: Why is alternate link a MUST?
On Sun, 03 Apr 2005 21:06:26 +0200, Joe Gregorio [EMAIL PROTECTED] wrote: Now the generated HTML may not be optimal but I hope this shows that barrier to generating an HTML 'alternate' is not onerous, and that the link should remain a MUST. This does not have to do with the _ease_ of generating an HTML alternate, it has to do with the usefulness of generating one. Atom may well work as (and/or be extended to be) a generic data interchange format for certain types of applications where the alternate web version is clearly not useful. Think mail. -- Arve Bersvendsen
Re: Why is alternate link a MUST?
On 3 Apr 2005, at 8:06 pm, Joe Gregorio wrote: I agree with Sam, +1 to the required link. The argument that you can't have an HTML representation are weak, since *I* can generate one for your feed, whether you like it or not, ala: http://www.rss2html.com/ I can also generate an XSLT sheet that transforms Atom into HTML then use the W3C XLST service to transform an Atom feed into HTML: http://www.w3.org/2001/05/xslt Now the generated HTML may not be optimal but I hope this shows that barrier to generating an HTML 'alternate' is not onerous, and that the link should remain a MUST. So do you have an argument here as to why it should be required? All I'm seeing is that it's easy to workaround when the publisher omits it. Graham Parks
Re: Why is alternate link a MUST?
On Sun, Apr 03, 2005 at 03:06:26PM -0400, Joe Gregorio wrote: I agree with Sam, +1 to the required link. The argument that you can't have an HTML representation are weak, since *I* can generate one for your feed, whether you like it or not. Now the generated HTML may not be optimal but I hope this shows that barrier to generating an HTML 'alternate' is not onerous, and that the link should remain a MUST. I think this highlights why I oppose MUST: what on earth is the utility of this alternate to the end user? The /only/ thing it seems to do is to provide a way of moving the view of the feed from the Atom client (which may be able to take advantage of the intrinsic structure, plus extension metadata) to an HTML client (probably a web browser), which probably can't do quite as much with it, and certainly can't do more in the case where the HTML is auto-generated from the Atom. Which, to the person sitting at the computer, doesn't strike me as much use. And since the spec doesn't touch user agent handling of the rel='alternate' (rightly), even if that were a desirable thing to do, it won't work with all feeds, since I am in my rights (for instance) to atom:link rel='alternate' type='image/png' .../, an artistic interpretation of the feed as if it were a swallow. The spec doesn't tell us precisely enough what alternate is for it to make sense as a MUST, in my view. Further, I don't think that it is practical to try to get a precise enough wording for MUST to become useful; even if it was, it would probably require placing restrictions on how the Atom clients use the link, which we don't do at the moment and in IMHO we should not even consider. I think the argument that it is trivial to produce an HTML representation of the data in the Atom feed actually reinforces my point here - if the user agent actually NEEDS an HTML version of the data, and a link to one isn't supplied, it can generate one itself. It'll have to do that even with the current wording, since I can quite happily satisfy the MUST requirement with a non-HTML version. (Something which I believe can't be done legally with RSS, or at least not all the different breeds. Not that that matters.) James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: Why is alternate link a MUST?
On Sun, Apr 03, 2005 at 03:06:26PM -0400, Joe Gregorio wrote: I agree with Sam, +1 to the required link. The argument that you can't have an HTML representation are weak, since *I* can generate one for your feed, whether you like it or not, ala: http://www.rss2html.com/ OK, I have Atom documents stored in the following places: 1. An attachment (or the content body) of an e-mail message 2. In an Oracle database behind a firewall 3. In an LDAP attribute, also behind a firewall 4. On a key chain hard drive 5. Typed out on a sheet of paper What URL can I use to refer to each of those? The key chain drive usually shows up as drive E:, if that helps. For simplicity, let's assume the sheet of paper can be stored on/in a flatbed scanner. I can also generate an XSLT sheet that transforms Atom into HTML then use the W3C XLST service to transform an Atom feed into HTML: http://www.w3.org/2001/05/xslt Let's say I care about providing an HTML representation for my data. XML lets me embed an XML stylesheet into the XML data itself. So now I have a completely self-contained Atom resource that user agents can transform into HTML without needing a link to any external resource. Even if this could be represented with a URI, why would I want to specify an alternate version when the first version has everything I could want? All I hear are ways *some* Atom documents can be given alternate versions. I still haven't heard WHY that should be required, other than because RSS does it. Why does RSS require it? Maybe we can start there. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Why is alternate link a MUST?
Martin Duerst wrote: Of course I'm also for making an alternate link for a feed a MAY rather than a MUST. I'm in favor of keeping it a MUST, but I could live with it becoming a SHOULD. As Sam says, all versions of RSS have made it a requirement. Feeds without a link will probably break some clients, so you better know what you're doing. OTOH, there have been some persuasive arguments for making it optional. If we change it, SHOULD seems like the right way to go: the distinction between 'SHOULD' and 'MUST' in RFC2119 doesn't apply to stupid implementors.[0] :) Robert Sayre [0] http://lists.w3.org/Archives/Public/ietf-http-wg/2005JanMar/0088.html
Re: Why is alternate link a MUST?
On Apr 3, 2005, at 12:45 PM, Graham wrote: So do you have an argument here as to why it should be required? All I'm seeing is that it's easy to workaround when the publisher omits it. Agreed. Joe, that wasn't very convincing. I repeat, we've seen several very believable use-cases for why someone might want this, and no good arguments (that I can remember) that it would break anything. Sam has pointed out that no previous version of RSS has done this, which is a reasonable argument; except for we have use-cases, and nobody's shown that the cost is non-zero. -Tim
Re: Why is alternate link a MUST?
Tim Bray wrote: Agreed. Joe, that wasn't very convincing. I repeat, we've seen several very believable use-cases for why someone might want this, and no good arguments (that I can remember) that it would break anything. Sam has pointed out that no previous version of RSS has done this, which is a reasonable argument; except for we have use-cases, and nobody's shown that the cost is non-zero. -Tim I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss and removed the link element. This absence caused Bloglines to behave oddly. Robert Sayre
Re: Why is alternate link a MUST?
On 3 Apr 2005, at 11:30 pm, Robert Sayre wrote: arguments (that I can remember) that it would break anything. Sam has pointed out that no previous version of RSS has done this, which is a reasonable argument; except for we have use-cases, and nobody's shown that the cost is non-zero. -Tim I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss and removed the link element. This absence caused Bloglines to behave oddly. I copied Tim's feed and renamed the description elements to summary and the items to entry. This caused Bloglines to behave oddly*. (* actually it didn't, but that's not the point) Graham
Re: Why is alternate link a MUST?
We are creating a new protocol. We don't expect any current reader to behave well with it before it is done. Quoting from RFC 2119, which is what we are using to define MUST and SHOULD: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Why is the alternate link actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)? It seems like a perfect candidate for MAY, like most of the rest of the format. --Paul Hoffman, Director --Internet Mail Consortium
Re: Why is alternate link a MUST?
On Apr 3, 2005, at 3:30 PM, Robert Sayre wrote: Sam has pointed out that no previous version of RSS has done this, which is a reasonable argument; except for we have use-cases, and nobody's shown that the cost is non-zero. -Tim I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss and removed the link element. This absence caused Bloglines to behave oddly. Well, yeah, but when they do the half-hour's coding it's going to cost them to start supporting Real IETF Atom 1.00 (tm), they can do an extra 3 minutes and if there's no link, they don't make the subscription clickable. Works fine in NetNewsWire btw. -Tim
Re: Why is alternate link a MUST?
On Apr 3, 2005 7:04 PM, Bill de hÓra [EMAIL PROTECTED] wrote: Tim Bray wrote: On Apr 3, 2005, at 12:45 PM, Graham wrote: So do you have an argument here as to why it should be required? All I'm seeing is that it's easy to workaround when the publisher omits it. Agreed. Joe, that wasn't very convincing. I repeat, we've seen several very believable use-cases for why someone might want this, and no good arguments (that I can remember) that it would break anything. Sam has pointed out that no previous version of RSS has done this, which is a reasonable argument; except for we have use-cases, and nobody's shown that the cost is non-zero. -Tim The top level feed stuff doesn't make a lot of sense to me. That @alternate is mandatory while @self and atom:id are not isn't very convincing either: atom:[EMAIL PROTECTED]'alternate'] : MUST atom:[EMAIL PROTECTED]'self'] : SHOULD atom:id : MAY You can't have a useful discussion about @alternate without talking about @self or atom:id. Thus: I'm -1 to downgrading @alternate unless @self is lifted to MUST or atom:id is lifted to MUST. If either are lifted to must I'm 0 on downgrading @alternate. At that stage @alternate doesn't matter a whole lot. For me David Nesting's example of an Atom document as an email attachment was the most convincing that @alternate doesn't need to be a MUST. I agree here with Bill and personally prefer to see atom:id lifted to a MUST. -joe -- Joe Gregoriohttp://bitworking.org
Re: Why is alternate link a MUST?
Just so everyone's clear: what we're arguing about is link rel=alternate on atom:feed, not on atom:entry. -Tim
Re: Why is alternate link a MUST?
Tim Bray wrote: Well, yeah, but when they do the half-hour's coding it's going to cost them to start supporting Real IETF Atom 1.00 (tm), they can do an extra 3 minutes and if there's no link, they don't make the subscription clickable. I doubt they've never encountered a feed without a link. Why do you think they didn't fix it? For example, they will accurately parse a feed that sends a unix timestamp instead of an RFC822 date. Robert Sayre
Re: Why is alternate link a MUST?
/ Arve Bersvendsen [EMAIL PROTECTED] was heard to say: | n Sun, 03 Apr 2005 03:14:33 +0200, Martin Duerst | [EMAIL PROTECTED] wrote: | | Of course I'm also for making an alternate link for a feed a | MAY rather than a MUST. | | +1 | | I don't see any advantage at all in forcing an alternative | representation to exist, and I have yet to see a real argument[1] why | such an alternative representation must exist . I have to vote +1 on this too. Twice now I've wanted to generate feeds (once for Subversion change logs and once for the 404s produced by my web server) where I thought the manditory alternate link was inpractical or impossible. For the Subversion case, I actually generated HTML pages so that I could point to them, but that's only because it felt geeky enough to be entertaining. For the 404 case, I use the 404 link as the alternate representation and that's just...pointless. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | Human felicity is produced not so much http://nwalsh.com/| by great pieces of good fortune that | seldom happen, as by little advantages | that occur every day.--Benjamin Franklin pgpuFd5t79Ts4.pgp Description: PGP signature
Re: Why is alternate link a MUST?
On 4/4/05 9:04 AM, Bill de hÓra [EMAIL PROTECTED] wrote: Thus: I'm -1 to downgrading @alternate unless @self is lifted to MUST or atom:id is lifted to MUST. If either are lifted to must I'm 0 on downgrading @alternate. At that stage @alternate doesn't matter a whole lot. -1: the reasons against @self MUST are similar to the reasons against @alternate MUST. I'll be happy with: self: MAY alternate: MAY id: SHOULD or possibly even: self: SHOULD alternate: SHOULD id: MUST e.
Re: Why is alternate link a MUST?
Not to pick on Eric; others have said things along the lines of: At 12:59 PM +1000 4/4/05, Eric Scheid wrote: I'll be happy with: self: MAY alternate: MAY id: SHOULD or possibly even: self: SHOULD alternate: SHOULD id: MUST This isn't a negotiating game. We have to have technical reasons for our assigning requirements levels. To repeat the relevant section from RFC 2119 (which is only two pages long, really): 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. What is the technical reasons for the SHOULDs and MUSTs? Where is the interoperability issues within the protocol (not with readers that don't know what the protocol looks like)? What are the potentials for causing harm? I'm not saying there are none; I'm saying let's choose our levels based on what we are supposed to be choosing from. --Paul Hoffman, Director --Internet Mail Consortium
Re: Why is alternate link a MUST?
Paul Hoffman wrote: What is the technical reasons for the SHOULDs and MUSTs? Where is the interoperability issues within the protocol (not with readers that don't know what the protocol looks like)? What are the potentials for causing harm? I'm not saying there are none; I'm saying let's choose our levels based on what we are supposed to be choosing from. If none of them are MUST, there is no social recourse when tracking down problems or seeking social understanding. Where did this feed come from? Who makes alternates? What's this all about? Robert Sayre
Re: Why is alternate link a MUST?
Why isn't this requirement a may instead of a must? I can see having a link with rel=alternate if indeed a alternate version does exist. It does not make sense to put in some something misleading if an alternate does not exist. I recently sought out and joined this list precisely because I wanted to see if this issue had been addressed. I don't think it's reasonable to assume there will always be an alternate version of a feed. If this remains a MUST, I have no choice but to honor this by using a dummy value for an alternate page, since I may not have an alternate. Without any background, it seems to me that the goal here is to require a link *back* to an HTML page that is presumed to have provided an alternate link to this Atom resource. This of course assumes that an HTML or non-Atom version actually exists, and that resource is independent of the Atom resource. (Consider that I may have an HTML version, but it could be derived from the Atom version using XSLT. It's not accurate to consider this an alternate when it's an XML style sheet involved.) I couldn't find any reference to this issue in the mailing list, aside from this (thankfully recent) thread. If it's been addressed before, could someone point me to the thread in the list archives? David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Why is alternate link a MUST?
+1 I think it makes a lot less sense for a feed than it does for an entry. Henry On 23 Mar 2005, at 14:19, Brett Lindsley wrote: I know this discussion has occured before, but I would like to revisit the question of why an atom:feed MUST contain at least one atom:link element with a relation of alternate (-06 4.1.1). The defintition of the alternate representation is it identifes an alternate version of the resource (Sec 4.2.9.2). However, is it realistic to believe that *every* feed has an alternate version? This becomes even more confusing if one considers the possibility of branching out using service.feed to filtered, searched or aggregated views. One would expect the link to have an alternate representation of the filtered, searched or aggregated feed as well. I have seen some examples where a home page was used for all of the alternate representations. Is a home page really an alternate representation? Putting a home page in feeds that are filtered or aggregated versions is also misleading because the home page would most likely not be an alternate representation of the filtered/aggregated feed. I can also think of situations where a server hosts feeds that do not have an alternate representation nor have a home page. In this case, why have a required link that serves no useful purpose. Why isn't this requirement a may instead of a must? I can see having a link with rel=alternate if indeed a alternate version does exist. It does not make sense to put in some something misleading if an alternate does not exist. Brett Lindsley, Motorola Labs
