* James Holderness <[EMAIL PROTECTED]> [2005-12-13 03:55]: > What about something like this: > > <th:in-reply-to> > <id>tag:www.example.org:2005:entry1</id> > <link rel="feed" type="application/atom+xml" > href="http://www.example.org/feed.atom"/> > <link rel="related" type="text/html" > href="http:www.example.org/entry1.html"/> > </th:in-reply-to> > > No doubt there are issues with the syntax,
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. > but the important concept is the idea of having two clearly > defined links: one being the permalink for the entry being > replied to and the other being the atom feed in which that > entry can be found. It could be made more flexible by allowing > further "alternate" links, but I'm not sure that's necessary. 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. atom:link elements can then simply be added to the atom:entry. This keeps things nicely flat and simple. 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. Or else we’d need to pick a better name for the relation. 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. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
