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
