Peter Saint-Andre wrote: > On 05/28/2008 4:02 PM, James Holderness wrote: > > > > Peter Saint-Andre wrote: > >> I don't know how much intelligence we expect an Atom > >> Processor to have, but if it is aware of the > >> discussion technology referred to by a link then it > >> could gather and display relevant meta-information > >> about the discussion venue (such as the number of > >> participants in an IRC channel or XMPP groupchat > >> room), fetch the last few threads or the messages in > >> the current thread from a newsgroup or webforum and > >> display a summary of that information (e.g., if > >> there is a specific thread about the Atom > >> feed or entry referred to in the link), etc.
> > If your Atom processor were capable of doing those things, > > why would it not want to do them on related links or > > alternate links? > > We've been down this path before. The "related" relation is void for > vagueness, since *everything* is related, otherwise why are > you linking? I agree. If you require a specific kind of processing then "related" is not appropriate. Especially, you cannot always use the scheme of the IRI to decide what action to perform. For example, a xmpp:// link could be a link to a discussion or a link to an Atom-over-XMPP push subscription service. AFAICT, the only way to distinguish between the two would be to use different link relations for each usage. > If someone can provide a much better definition of the "related" > relation then I'm open to retracting the idea of a "discuss" relation, > but the description (I don't think it can even be called a definition) > in RFC 4287 is uselessly circular, to wit: > > The value "related" signifies that the IRI in the value of the > href attribute identifies a resource related to the resource > described by the containing element. > > "It's related because it's related." Thanks for the tautology. "related" should be used when you need to store a link for some reason and you don't care if/how it is exposed to any users along the way. Basically, rel="related" should almost never be used. If you need the UA to display some links to the user then you should put those links in the atom:content using (X)HTML markup to guarentee (as much as possible) that they show up (since not all Uas expose "related" links). If you don't want the UA to display the link then you should use something other than rel="related" because some UA's will expose all "related" links. > > I'm strongly opposed to any link rel proposal that has no potential > > client implementation, or where the implementation would be > > the same as existing link relationships. > > I don't think it's the same at all, but I seem to be beating my head > against the wall attempting to explain why. Everyone I've talked to in > the social networking and real-time communication spaces gets the > concept of rel='discuss' immediately, but folks here just don't. > Therefore I will attempt to socialize the idea in other venues (e.g., > some of the RAI lists) and see what folks there think. Peter, are clients supporting rel='discuss' already? It doesn't make sense to standardize something that nobody is doing. I say just go ahead and implement it and don't worry about the registration right now. Or, use something like rel="http://schema.briansmith.org/link/discuss"; instead of rel="discuss"? Then you can avoid the whole issue by avoiding the registration process completely. Regards, Brian
