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
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?
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? 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?
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 itâs 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 thatâs what appropriate for a particular case, encouraged. So I think itâs 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 donât 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 > 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? > > 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 -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 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 -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 . 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 . 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?
* Joe Gregorio <[EMAIL PROTECTED]> [2005-04-03 21:15]: > 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: That is true, but how is the result of an operation that depends on the feed itself an alternate representation in any meaningful sense? Regards, -- Aristotle âIf you can't laugh at yourself, you don't take life seriously enough.â
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 . 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 , 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 . 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 element. This absence caused Bloglines to behave oddly. Robert Sayre
Re: Why is alternate link a MUST?
On Mon, 04 Apr 2005 00:30:36 +0200, Robert Sayre <[EMAIL PROTECTED]> wrote: I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss and removed the element. This absence caused Bloglines to behave oddly. In what sense? Please be aware that the absence of is not something I think you'd usually see on the public web, anyway. -- Arve
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 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?
Arve Bersvendsen wrote: On Mon, 04 Apr 2005 00:30:36 +0200, Robert Sayre <[EMAIL PROTECTED]> wrote: I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss and removed the element. This absence caused Bloglines to behave oddly. In what sense? Sorry, I was a little unclear. Bloglines made "Ongoing" a hyperlink, but it linked to the page I was already looking at without the navigation frame. Please be aware that the absence of is not something I think you'd usually see on the public web, anyway. I see Graham has written about "the point", which is that existing UIs often assume the availability of a link from the feed. This is a SHOULD, with stern warnings, minimum. Robert Sayre
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?
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. cheers Bill
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 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 , 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?
On Apr 3, 2005, at 3:55 PM, Paul Hoffman wrote: 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. I think is a SHOULD, to address auto-subscriptions, one of the current #1 RSS pain points, perceived by users as a failure to interoperate. -Tim
Re: Why is alternate link a MUST?
Just so everyone's clear: what we're arguing about is on , not on . -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 , 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?
/ Robert Sayre <[EMAIL PROTECTED]> was heard to say: | 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] :) SHOULD works for me. Be seeing you, norm -- Norman Walsh <[EMAIL PROTECTED]> | In a universe of electrons and selfish http://nwalsh.com/| genes, blind physical forces and | genetic replication, some people are | going to get hurt, other people are | going to get lucky, and you won't find | any rhyme or reason in it, nor any | justice.--Richard Dawkins pgpITUkxL4nY6.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?
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']. For atom:id I can see how being able to clearly and unambiguously identify a feed would help us avoid requesting feeds from different URIs only to get the same information (that falls under "avoiding retransmission", right?). I can think of only one SHOULD reason for [EMAIL PROTECTED]'self'], which is the auto-subscribe interoperability problem with browsers. * hmmm.. [EMAIL PROTECTED]'alternate'] = MAY [EMAIL PROTECTED]'self'] = SHOULD id = SHOULD e. ps. I think it would be prudent to put the reason why something is a SHOULD in the spec itself. pps. I'm inclined to go the same way with atom:entry/atom:link's
Re: Why is alternate link a MUST?
On Sun, Apr 03, 2005 at 04:13:55PM -0700, Tim Bray wrote: > I think 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 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 don't understand. How are these alike? cheers Bill
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: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. e.
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?
I do think also that there are plenty of use cases suggesting that alternate might not be always available. However in that context where there's no feasible alternate, it would be extremely useful to know you can count on atom:id. If not, what else can you rely on to track your "content" as it flows from system to system without an alternate. I have not been following atom-syntax for a while, but are there any other elements that could be used if no alternate was not found? I think this is the reason why Sam has never seen anybody complain about link because, it doubles as id as well, but since we have a clear separation in atom, either or both might be good to be specified. Just my two cents. Elias Torres 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. > > cheers > Bill > >
Re: Why is alternate link a MUST?
On Apr 3, 2005 11:59 PM, Robert Sayre <[EMAIL PROTECTED]> wrote: > > 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? +1 Of course, if [EMAIL PROTECTED] is not the identifier and it falls to atom:id then we may end up having to add more verbage to the spec. For example, today some feeds are full-content, others are abbreviated. If I produce both kinds of feeds, do I use the same atom:id for both? What if one feed is delivered via email and the other via HTTP, should they both use the same atom:id? -joe -- Joe Gregoriohttp://bitworking.org
Re: Why is alternate link a MUST?
At 11:59 PM -0400 4/3/05, Robert Sayre wrote: 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? Good, we're making progress. You're aiming at the "to limit behavior which has potential for causing harm" part of 2119. I'm fine with making one of them a MUST for that reason. atom:id seems like the one that would most help tracking down problems, yes? At 4:13 PM -0700 4/3/05, Tim Bray wrote: I think is a SHOULD, to address auto-subscriptions, one of the current #1 RSS pain points, perceived by users as a failure to interoperate. -Tim Sounds good to me. At 2:25 PM +1000 4/4/05, Eric Scheid wrote: ps. I think it would be prudent to put the reason why something is a SHOULD in the spec itself. +1. There is ample evidence in the IETF that, when you don't do that, people will guess wrong about a year after the spec comes out. --Paul Hoffman, Director --Internet Mail Consortium
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 4 Apr 2005, at 4:59 am, Robert Sayre wrote: 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? Well, things don't just appear, do they: If it arrived over HTTP: You should know, you requested it. From a server with whois information and port 25 and a front page and a million other things. If it arrived over email: The from address. If you found it on a local disk: Somebody put it there. There's no guarantee that alternate points anywhere useful. If you want to write up a proposal suggesting a required, verified troubleshooting contact, please do, but don't use it to justify something unrelated. Graham
Re: Why is alternate link a MUST?
On Sunday, April 3, 2005, at 05:16 PM, Robert Sayre wrote: 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 , 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? Perhaps a combination of: * Because the RSS spec says its required * Because it doesn't cause any serious problems like a computer or application crash, just an unexpected page to be shown when the link is clicked * Because nobody who we assume pointed it out to them complained loudly since it didn't cause any serious problems * Because they had more important things to do Both the amount of work required to enable an app to handle linkless feeds and the negative impact of not having the link are trivial as far as I can see, except for Bill's point about wanting an identifier for the feed. On Monday, April 4, 2005, at 06:25 AM, Bill de hÓra wrote: Anyway I've made my position clear at this point. Please make id or self mandatory. I'd be opposed to [EMAIL PROTECTED]"self"] or [EMAIL PROTECTED]"alternate"] being mandatory since uses cases have been put forth for not having a reasonable value for either, but not opposed to either or both being SHOULDs. I also wouldn't be opposed to a feed being required to have either a [EMAIL PROTECTED]"self"] or an id.
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?
How about a [EMAIL PROTECTED]"homepage"] for feeds that actually have a home page to point to. By the same reasoning, [EMAIL PROTECTED]"alternate"] would exist if the feed actually had an alternate representation. Both of these would be MAY. This would be consistent with how the spec currently treats the prev, next, etc. with the verbage "atom:feed elements MAY contain additional atom:link elements beyond those described above" Sec 4.1.1. If all of these links are MAY, then the only effect of the client is the ability to have more features if they are included. I can't think of an example where the client would fail to function if one if them would be excluded (no reason for a MUST). Antone Roundy wrote: On Sunday, April 3, 2005, at 05:16 PM, Robert Sayre wrote: 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 , 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? Perhaps a combination of: * Because the RSS spec says its required * Because it doesn't cause any serious problems like a computer or application crash, just an unexpected page to be shown when the link is clicked * Because nobody who we assume pointed it out to them complained loudly since it didn't cause any serious problems * Because they had more important things to do Both the amount of work required to enable an app to handle linkless feeds and the negative impact of not having the link are trivial as far as I can see, except for Bill's point about wanting an identifier for the feed. On Monday, April 4, 2005, at 06:25 AM, Bill de hÓra wrote: Anyway I've made my position clear at this point. Please make id or self mandatory. I'd be opposed to [EMAIL PROTECTED]"self"] or [EMAIL PROTECTED]"alternate"] being mandatory since uses cases have been put forth for not having a reasonable value for either, but not opposed to either or both being SHOULDs. I also wouldn't be opposed to a feed being required to have either a [EMAIL PROTECTED]"self"] or an id.
Re: Why is alternate link a MUST?
Paul Hoffman wrote: At 11:59 PM -0400 4/3/05, Robert Sayre wrote: 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? Good, we're making progress. Not really. 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. You're aiming at the "to limit behavior which has potential for causing harm" part of 2119. I'm fine with making one of them a MUST for that reason. atom:id seems like the one that would most help tracking down problems, yes? Nope. That could very well be a non-heirarchical scheme like urn:uuid. This is not necessarily about full-on buggy software. Making atom:id mandatory does seem low-cost; if the producer can't do it once, they'll never do it for the entries. There are lots of situations where the software is behaving correctly but the content is confusing to the end-user. Feed-level links help to resolve that confusion. Without the link, non-bugs become a problem. Robert Sayre
Re: Why is alternate link a MUST?
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. Feeds are the only kind of resource on the internet that I'm aware of that routinely have alternate representations. Thinking about it from that direction, why one WOULD want a feed to have an alternate representation becomes a more important question than would one WOULDN'T. Here are the reasons I can think of: * Feeds emerged in the context of an internet where virtually everybody had a web browser, but virtually no one had a feed reader. Having only a feed severely limited one's reach. * Feeds emerged in the context of an internet where publishers were already publishing HTML representations of the data they started putting into feeds. * Feeds began as a method of announcing the existence of new data on web pages, not as a method of delivering full content. * There are established and accepted methods of building revenue streams from web pages--ie, we know where to put ads in web pages. Until people figure out how to monetize their feeds, many will want to use them to drive people to their web pages. 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. These conditions still apply to many feeds, but not all. I don't see any reason to try to force feeds to continue to be the unusual internet resource that always has an alternate representation. Antone
Re: Why is alternate link a MUST?
This is very convincing to me. Henry On 4 Apr 2005, at 18:22, 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. Feeds are the only kind of resource on the internet that I'm aware of that routinely have alternate representations. Thinking about it from that direction, why one WOULD want a feed to have an alternate representation becomes a more important question than would one WOULDN'T. Here are the reasons I can think of: * Feeds emerged in the context of an internet where virtually everybody had a web browser, but virtually no one had a feed reader. Having only a feed severely limited one's reach. * Feeds emerged in the context of an internet where publishers were already publishing HTML representations of the data they started putting into feeds. * Feeds began as a method of announcing the existence of new data on web pages, not as a method of delivering full content. * There are established and accepted methods of building revenue streams from web pages--ie, we know where to put ads in web pages. Until people figure out how to monetize their feeds, many will want to use them to drive people to their web pages. 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. These conditions still apply to many feeds, but not all. I don't see any reason to try to force feeds to continue to be the unusual internet resource that always has an alternate representation. Antone
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