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
