Subject: Re: Why is alternate link a MUST?

From: Brett Lindsley <[email-masked]>
Date: Sun, 03 Apr 2005 12:05:08 -0500

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

---

From: Antone Roundy <[email-masked]>
Date: Mon, 4 Apr 2005 09:26:53 -0600

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