On 05/29/2008 2:27 PM, James Holderness wrote: > > Brian Smith wrote: >> Peter Saint-Andre wrote: >> > On 05/28/2008 4:02 PM, James Holderness wrote: >> > > 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. > > Except a "discuss" link doesn't require a specific kind of processing - > at least none that has been disclosed so far. If it did, I wouldn't have > a problem with it. > >> 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. > > And an http link could be a link to a porn site or a link to a news > site, but without a "porn" link relationship there would no way to > distinguish between the two. We really need a whole lot more of these: > "news", "shopping", "sport", videos". We should define link > relationships for every possible category of web site.
Is the address space of link relations something that we want to deliberately restrict? Why not let a thousand flowers bloom? > Obviously that is ridiculous. Nothing is obvious. I bet some folks think that a link relation of "shopping" would be far from ridiculous (link to the iTunes page where you can buy the song or whatever). But I think that the proof of whether something makes sense is experimentation out in the marketplace of ideas and in userspace. > Yes, we can't tell the difference, but why > should we care? Why does a client *need* to be able to distinguish > between links to discussions and links to anything else? Did I ever say a client MUST distinguish a "related" link from a "discuss" link? No, I said that this might be useful. Whether that hunch proves out depends on implementation and deployment experience. > Human readers > obviously care where something is linking, but that's why we have the > title attribute. You mean the title attribute of the <link/> element? I wonder how well that would scale with regard to localization... >> "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. > > That implies that you *do* care how "discuss" links are exposed to > users. You bet I do. Do you think I go through these head-banging standardization efforts for the sheer fun of it? ;-) > Please let me know *specifically* what you had in mind. I'm not > asking for REQUIRED behaviour - just your idea of what a perfect client > *should* do. I'll make that clearer in the next version of the I-D. > Also, please explain why a client *shouldn't* perform the > same processing on other link types, such as "related" or "alternate". As I've said, "related" is void for vagueness and IMHO meaningless. But if people in the real world are ascribing meaning to it (not captured in the description from RFC 4287) then that's great. However, if that's so then I wish someone would define it properly. And a chatroom or email list or newsgroup where you can discuss an entry does not fit under the "alternate" umbrella in any scenario I can think of. >> Peter, are clients supporting rel='discuss' already? > > Please do tell us if that is the case. It would make this dicussion so > much easier if you could provide real examples of clients that are doing > something useful with these links. No they aren't because I'm trying to do the right thing by defining how it's supposed to work through standardization. > As a feed publisher, if I wanted to link to an IRC channel, news forum > or mailing list where people were actively discussing a post, I would > want the readers of my feed to *see* that link and be able to click on > it and join the discussion. Right now I can get that functionality in a > number of feed readers using a "related" link. If I were to change my > link to use "discuss", it would suddenly become invisible. My feed would > become significantly less functional. So why is there any link type except related? Every time someone defines a new link relation (oh, say "edit" or "next") then by your theory we are losing functionality. > So why are you trying to convince people that this is a good idea? I'm > assuming you're not deliberately trying to make their feeds less > functional. So what is the great gain they'll get from using a "discuss" > link that makes this loss of functionality worthwhile? I don't see any loss of functionality, instead I see more granularity in what is presented to the user. > Where are the > clients that are supporting (or planning to support) "dicuss" links in > some incredible way that makes this all worthwhile? I have not socialized any of these concepts among Atom client authors. Perhaps it would have been more productive to start there than on this list, but since this is the list for Atom syntax I figured it was a good place to start. If that assumption is false, feel free to point me to a more appropriate venue for discussing this topic. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
