A. Pagaltzis wrote:
The biggest issue being that a threading-unaware client won’t know to go looking inside thr:in-reply-to to find links. This syntax will only satisfy the “allow threading-unaware clients to do something useful” constraint if you duplicate the links at the atom:entry level.
That's what I meant when I said: "I think a "related" link that points to the permalink of the original message is a good start."
I really don't think a threading-unaware client needs to know the URI of the Atom feed that contained the message.
If the extensibility afforded by child elements is not a useful goal (and in this case, I think it isn’t; is there more information that is going to be needed than the source feed and permalink?), that could be handled cleanly by just adding an @alternate attribute to thr:in-reply-to to record the permalink.
I don't have a problem with that. I was just playing with ideas for the syntax.
I am not sure that the semantics of adding atom:[EMAIL PROTECTED]'feed'] to atom:entry are particularly clean; but we might just decide that it isn’t a great loss if threading-unaware clients miss the feed link.
I wouldn't suggest trying to add it to the entry at all. I don't think it's a useful piece of information to a threading-unaware client even if it was in a format that would be recognised.
So the changes would be: • Rename @href to @source. • Repurpose @href to contain the alternate link. • Change the recommendation to include an atom:[EMAIL PROTECTED]'related'] to point to the alternate link instead of the feed.
Sounds good to me. Regards James
