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?
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.
> Why is it
> appropriate to display the number of participants in an IRC channel if
> you're linking via a discuss link, but it's not appropriate if you're
> linking for some other reason?
My point is that there is no true *reason* underlying the "related"
relation and that the other relations are not appropriate for linking to
a multi-party discussion venue where you can actively engage in an
interactive conversation with other people as opposed to passively
consuming a comments feed, statically finding an alternative location
for the main feed, etc.
Let me put it this way. On each IETF Working Group page there is a link
to the discussion venue for the WG (traditionally an email discussion
list just like this one). You follow that link if you don't just want to
find background information ("related"?) or read I-Ds and RFCs, but
instead want to join the conversation about the technology under
development. Those links are there for a reason, namely, because an
interactive discussion provides an entirely different kind of experience
from reading an I-Ds or RFCs. To paraphrase the old Palmolive
advertisements: "you're soaking in it"! I don't see why people on this
discussion list have such a hard time understanding that a multi-party
conversation provides a different kind of experience, since you've been
soaking in conversation for years now.
> 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
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
