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