* James Holderness <[EMAIL PROTECTED]> [2005-12-11 12:30]: > Those documents are technically related. But when you think > about the practical implications, how the client needs to deal > with it, how it affects the end user, I don't think it's a good > idea.
Well, the idea for this, if I remember right, was actually mine; and was based mainly on the thought you’re calling “technically.” The idea was to give threading-unaware clients a chance to do something useful. Based on your argument I would agree that it would be best if the related link pointed to the permalink of the entry being replied to, rather than the feed. In fact that is a very good idea in any case. But in that case you run into the problem that there is no clear way to associate the atom:[EMAIL PROTECTED]'related'] to a particular permalink with its thr:in-reply-to pointer, ie. the information is imprecise and threading-aware clients have to guess. A complication here is that we found in previous discussion that nesting makes things more complex; ideally, therefore, any approach would only add direct child elements to the atom:entry element. Given this constraint, do you have a better idea how do address the following concerns? • Threading-unaware clients should get at least some information that allows the user to notice that there’s more to the entry, even if the user agent remains blissfully unaware of the thread as such. • The available information precise enough that threading-aware can correlate all the related bits without guessing. The existing draft avoids problems with #2 by simply duplicating URIs, so it’s always obvious which related links and which threading elements belong together. If the URIs diverge, you need some other mechanism of crossreferencing from one to the other. > Do you know of any client implementations that do that sort of > thing? Honestly, I haven’t seen any yet that do anything interesting at all with extra links (be they related, via, or something else)… (Which rather irks me.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
