Brian Smith wrote:
> I am implementing RFC 4685, the threading extension. Section 3 says that
> the thr:in-reply-to/@ref attribute is mandatory. It further says that if
> the content producer does not know the atom:id of the linked-to-entry, then
> the producer should make one up, usually by copying the value of the @href
> attribute.
Well, it's a bit more than just "make it up" What it says it that the
permalink SHOULD be used. As it turns out, in my experience, the
permalink is quite quite often as the an id.
> [snip]
> In particular, if the content producer does not know of an appropriate atom
> ID
> to use for a thr:in-reply-to/@ref attribute, it SHOULD NOT include the
> attribute.
> Content consumers may always substitute the value of the @href attribute for
> a missing @ref if it feels like it really needs an atom:id using the same
> rules
> that are currently imposed on content producers.
As you point out, the ref attribute is mandatory. If anything, I would
provide both the ref and href attributes. There's no harm in providing
both.
>
> An example use case: I want to use my weblog to reply to an entry in other
> person's
> weblog, and I want to indicate this with thr:in-reply-to. The problem is that
> the
> other person only implements RSS 2.0 or some other wacky format, so he
> doesn't provide
> me with an Atom ID to use; in fact, I might have only the HTML permalink to
> his entry.
> (If the other person was to upgrade to some Atom-enabled weblogging software,
> then all
> his entries would have an atom:id. But, the atom:id his weblogging software
> chooses
> probably won't match the atom:id I made up for that resource.)
>
More than likely but that's not a huge problem. The other person could
make all kinds of changes to their system that break the links others
have made to their resources. It happens all the time on the web. Care
need to be taken when using in-reply-to to link to anything that is not
an Atom entry.
- James
