Roger,
I would model the behavior after the way most email clients (the ones
I've seen anyway) handle the SMTP In-Reply-To header. For example, in
thunderbird, if I receive a note that is a response to another that has
either not yet been received or has been deleted, that note shows up as
a new thread. If the parent shows up later, the child thread is
automatically moved under the parent. To me, this is ok (desirable in fact).
In other words, I'm not so sure your fourth scenario really is a
problem. That is, personally, I'd prefer that B was not ignored, even
if it didn't make much sense without A.
Also, a key advantage of thr:in-reply-to is the ability to specify the
source of the parent. If the source attribute is specified, clients
that have not yet received the parent can go out and grab it. In fact,
your scenario would make a very strong argument as to why publishers
should use the source attribute.
- James
Roger B. wrote:
> James & Company: Is there any chance of seeing something added to the
> spec that could identify a feed or entry as a subordinate comment,
> rather than simply a reply?
>
> Here are the situations I'm facing during test implementation... Entry
> A is a blog posting, Entry B is a comment posted in response to Entry
> A, and Entry C is a third-party blog posting that claims to be a reply
> to Entry A.
>
> (1) I consume Entry A, and then Entry B. I note Entry B's in-reply-to
> id/ref, see that it matches Entry A, and thread the two together. All
> is well.
>
> (2) I consume Entry A, and then Entry C. I note Entry C's in-reply-to
> id/ref, see that it matches Entry A, and thread the two together. All
> is well.
>
> (3) I consume Entry C, and then Entry A. Since Entry A did not yet
> exist when I processed Entry C, I create new threads for both Entry C
> and Entry A. All is (basically) well.
>
> Here's where we get into trouble...
>
> (4) I consume Entry B, and then Entry A. Since Entry A did not yet
> exist when I processed Entry B, I create new threads for both of them.
> Unfortunately, Entry B was never meant to stand alone in any real
> sense, unlike Entry C.
>
> If Entry B had a way to clearly convey that it needs Entry A to make
> any sense, I could just ignore it until Entry A shows up. Absent such
> a mechanism, I can't ignore anything, because for all I know, Entry B
> is just like Entry C.
>
> I guess what I'm looking for is an @isrealparent attribute on
> in-reply-to. (Bad name, I know.) Just something that allows the
> replying entry to assert a closer relationship to the other resource.
>
> --
> Roger Benningfield
>
>
